TL;DR: Unosecur finds that AI governance platforms document approval, policy, and oversight, but AI agent security platforms control runtime permissions, tool access, and session revocation. The boundary matters because compliance can exist on paper while an agent still holds live authority that governance tooling cannot contain.
At a glance
What this is: This is an analysis of the difference between AI governance platforms and AI agent security platforms, finding that approval and documentation controls do not equal runtime containment.
Why it matters: IAM and security teams need the distinction because agent governance can satisfy process requirements while leaving live agent authority, tool reach, and revocation gaps unmanaged.
👉 Read Unosecur's analysis of AI agent security versus AI governance platforms
Context
AI agent governance and runtime control are not the same problem. One set of tools answers whether an agent was approved, documented, and aligned to policy; the other answers what that agent can do right now, and whether its live authority can be contained before damage occurs.
The governance gap matters because modern AI agents are treated as identities with credentials, tool access, and downstream reach. If those permissions are only reviewed at intake, the organisation may have process compliance without operational containment.
This article is about the boundary between AI governance and AI agent security, not a vendor feature comparison. For IAM leaders, the real question is where approval records stop and enforceable runtime authority begins.
Key questions
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.
Q: Why do AI agents create compliance risk even when policies exist on paper?
A: Policies do not satisfy auditors if the organisation cannot prove enforcement. AI agents can call APIs, move between tools, and access data dynamically, so compliance depends on evidence of real-time control, not written intent. The practical test is whether you can reconstruct every sensitive action after the fact without guesswork.
Q: How do security teams know whether an AI agent platform is actually enforcing policy?
A: A platform is enforcing policy if a prohibited action is blocked at the moment the agent attempts it, not if the violation is recorded after the fact. The practical test is simple: create a disallowed action and see whether execution stops immediately. Logging alone is evidence of oversight, not enforcement.
Q: Should organisations separate AI governance workflows from AI runtime containment?
A: Yes. Governance workflows are suited to approval, documentation, and policy sign-off, while runtime containment must handle live permissions, token revocation, and session termination. Combining them loosely often leaves neither function strong enough. Mature programmes separate oversight from enforcement and make the enforcement layer measurable.
Technical breakdown
Approval records vs effective permissions
AI governance platforms typically store who approved an agent, what policy it was assigned, and whether it passed a review gate before deployment. That is a record of intended authority, not proof of current authority. Effective permissions are the live rights an agent can exercise after deployment, including tools, credentials, and reachable systems. A governance record can show that an agent was cleared months ago while runtime conditions have drifted materially. The technical distinction is between static authorisation evidence and active access state. In identity terms, the former is documentation, the latter is enforcement.
Practical implication: validate live effective permissions, not only intake approval records.
Policy documentation vs runtime enforcement
Policy documentation explains what an agent should or should not do, but it does not stop execution. Runtime enforcement happens when a system intercepts an attempted action and blocks, suspends, or constrains it based on deterministic controls. That distinction mirrors the gap between recording an access rule and enforcing it at the moment of use. For AI agents, this matters because the harmful event is often an attempted tool call, token use, or session action, not the policy breach itself. If the control only logs the violation after the fact, it has not changed the risk exposure. Enforceable control is what reduces blast radius.
Practical implication: require blocking controls at the point of agent action, not just policy logging.
Why agent identity changes the control model
An AI agent is not just a model or a workflow. When it has credentials, tool access, and the ability to act independently within a session, it behaves as a live identity with operational reach. That means the control question shifts from whether the agent was authorised in principle to whether its present authority can be bounded, observed, and revoked in time. Security platforms that focus on agent identity assess credentials, permissions, and downstream reach across environments. Governance platforms usually stay at the model, use case, or committee layer. The technical boundary is therefore identity-level enforcement versus governance-level oversight.
Practical implication: treat AI agents as identities whose runtime authority must be governable as such.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI governance and AI agent security solve different identity problems. Governance establishes whether an agent should exist, who approved it, and whether the use case meets policy. Security determines what that agent can currently reach, what it can do with those permissions, and whether live authority can be revoked before impact. Organisations that blur the two end up with process compliance and control gaps at the same time. The practitioner takeaway is that approval does not equal containment.
Runtime authority is now the decisive boundary for agent risk. The most important control question is no longer whether an agent was reviewed at intake, but whether its effective permissions can be constrained continuously after deployment. That is a materially different operating model from traditional governance workflows, which are built around records, reviews, and committee decisions. The implication is that the control plane must follow the agent into production, not stop at registration.
Identity-level exposure is the right unit of analysis for AI agents. Model-level risk scoring can tell you whether a model is suitable in principle, but it does not describe the live blast radius of a deployed agent. The named concept here is runtime authority gap: the distance between documented approval and actual accessible resources. That gap is where governance-only programmes fail, and it is the control variable practitioners need to measure.
Incident containment belongs with the layer that can act in session. A review committee can document risk, but it cannot stop a live agent from calling a tool, using a token, or continuing a session while escalation waits. The control plane that matters is the one that can revoke access and terminate activity without a manual approval loop. Practitioners should therefore map containment responsibility to runtime security, not governance oversight.
AI governance maturity should be measured against enforcement, not paperwork. A programme can have strong policy language and still leave live authority uncontained in production. That is why the real governance test is whether the organisation can answer what an agent can do now, not what it was allowed to do at deployment. The practitioner implication is to audit for enforceable runtime controls, not just approvals and dashboards.
From our research library:
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Runtime authority gap: AI programmes increasingly fail where approval records stop and live permissions begin. The operational risk is not that an agent was never reviewed, but that it keeps acting with authority no committee can see in time.
For identity teams, the programme question is shifting toward enforceable containment. Access review cadences, policy dashboards, and intake workflows do not answer what a production agent can do right now, so runtime control has to become part of identity governance design.
The article also reinforces a broader governance pattern: oversight is not enforcement. If a platform cannot block, suspend, or revoke live agent activity, it is describing risk rather than reducing it.
For practitioners
- Map approval state against live authority Inventory which agents have been approved and compare that list to their current effective permissions, reachable tools, and downstream systems. Treat any mismatch as a governance and containment gap, not a documentation issue.
- Test runtime policy enforcement Write a prohibited action into policy, then verify whether the control plane blocks the agent at the moment it attempts the action. Logging alone is not containment.
- Separate committee oversight from containment Assign review boards to approval and policy decisions, but require a runtime control layer that can revoke tokens, suspend sessions, and remove access without waiting on a meeting cycle.
- Measure blast radius by identity For each production agent, document credentials, tools, and reachable resources as the operative blast radius. Use that exposure view in access reviews instead of model-level summaries.
Key takeaways
- AI governance and AI agent security are separate control layers, and only the latter is designed to manage live permissions and session authority.
- The central governance failure is assuming that approval records equal containment, when the real risk sits in effective permissions and runtime reach.
- Practitioners should evaluate platforms by whether they can block actions, revoke access, and terminate sessions in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agents retaining or losing live authority after approval. |
| ASI02 — Tool Misuse | The runtime question is whether an agent can misuse tools after governance approval. | |
| Recommendation — Map agent approval and runtime permissions to ASI03 and verify that live authority matches intended scope. Constrain agent tool access and block prohibited actions under ASI02 at execution time. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Live agent authority depends on how credentials and sessions are authenticated and revoked. |
| Recommendation — Review agent authentication and revoke live credentials when runtime authority exceeds policy. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article contrasts governance records with enforceable AI control accountability. |
| Recommendation — Define governance ownership separately from runtime enforcement and measure both in the AI programme. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether an agent's permissions are governed at the point of use. |
| Recommendation — Continuously validate agent entitlements under PR.AA-05 against effective permissions in production. | ||
Key terms
- Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- Governance Record: The documentation showing that an identity, workflow, or agent was reviewed, approved, and assigned policy. A governance record is useful for audit and accountability, but it does not prove that live authority has been reduced or removed.
- Runtime Authority Gap: The distance between what an AI agent was approved to do and what it can still do in production. This gap matters because security failures often happen after approval, when permissions, tools, or sessions remain active beyond the intended control boundary.
What's in the full article
Unosecur's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step evaluation tests for comparing approval records with live agent permissions
- Detailed distinctions across policy documentation, model-level risk, and identity-level exposure
- Examples of runtime containment actions such as token revocation and session termination
- How the vendor positions its identity fabric and MCP gateway in the control stack
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 22, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org