Notifications
Clear all
Topic starter
04/09/2026 6:35 pm
TL;DR: Agentic AI risk is structurally different from static model risk because tool calls, database writes, and API actions are irreversible, while traditional evaluation still centres on outputs, according to Openlayer. The governance gap is now runtime enforcement, not model scoring, because organisations must control delegated actions before they execute.
NHIMG editorial — based on content published by Openlayer: Agentic AI Risk: Evaluating Autonomous Systems
By the numbers:
- Only about one-third of approximately 500 organizations surveyed by McKinsey in 2026 report maturity level three or higher across agentic AI governance controls.
- Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026.
Questions worth separating out
Q: What is the first control teams should put in place for agentic AI?
A: The first control is scope and authority bounding.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Q: How do security teams know if agentic AI controls are failing?
A: The main signs are session drift, repeated retry loops, unauthorized tool calls, and behaviour that diverges from the documented task sequence.
Practitioner guidance
- Define irreversible actions and gate them first Classify every agent action by whether it can be undone, then require human approval before any irreversible database write, financial submission, access change, or external dispatch.
- Register an explicit tool and API allowlist Document every permitted tool call, API endpoint, datastore, and retrieval source in a registered allowlist, then test the agent only inside that boundary.
- Add runtime blocking at the tool boundary Use intent-to-tool alignment checks, session-level monitoring, and blocking logic before execution rather than relying on logs after the fact.
What's in the full article
Openlayer's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step pre-deployment assessment workflow for autonomous systems, including scope bounding, reversibility mapping, attack-surface enumeration, and adversarial behavioural testing.
- The session-level control model used to block unauthorised tool calls and suspend agents when intent-to-tool alignment drops below the operating threshold.
- The 13 session metrics used to track drift across multi-step interactions and separate observation from enforcement.
- The full explanation of how multi-agent architectures change trust, auditability, and failure propagation across shared memory and sub-agent chains.
👉 Read Openlayer's analysis of agentic AI risk and runtime control gaps →
Agentic AI risk and runtime control gaps: are your controls keeping up?
Explore further
04/09/2026 6:35 pm
Irreversibility is the defining governance concept for agentic AI. Once an agent writes to a database or triggers an external action, the incident is no longer a model quality issue. That shifts the control objective from reviewing outputs to preventing unauthorised execution. Teams that still treat agentic AI as a logging problem are applying the wrong governance model. The practical conclusion is that reversible and irreversible actions must be governed differently.
A question worth separating out:
Q: What should organisations do when an agent can make irreversible changes?
A: Require pre-authorization before the agent runs, not after the action is complete. Post-event monitoring can explain what happened, but it cannot prevent damage to code, data, or systems once the action has already executed. For irreversible work, the governance control has to happen before execution, with a clear owner attached to the decision.
👉 Read our full editorial: Agentic AI risk is defined by irreversible tool actions, not outputs
