TL;DR: Autonomous AI agents operate at machine speed, pull tools and data across enterprise systems, and expose governance gaps that human-centric IAM, compliance, and audit models were never built to handle, according to Strata Identity. Access review processes assume access persists long enough to be reviewed; autonomous actors can acquire, use, and discard privileges within a single session, collapsing that assumption.
At a glance
What this is: This is Strata Identity's analysis of why AI agent governance needs runtime identity controls, with the central finding that scripts and human-centric IAM assumptions fail once agents act at machine speed.
Why it matters: It matters because IAM, PAM, IGA, and security architects need to govern agentic behaviour as a live identity problem, not as static automation or a human access review problem.
Context
Autonomous AI agents are software actors that can decide, call tools, and execute actions without a human approving each step. That creates an identity governance problem, not just an application control problem, because existing IAM models assume the subject being governed is either a person or a deterministic workload.
Strata Identity frames the issue as runtime governance: agents can acquire, use, and discard privileges within one session while traversing APIs, data sources, and enterprise systems. In that model, scripts are too static, and periodic access review is too slow to see what happened.
The article's starting position is typical of current agent deployments. Organisations are adopting agentic workflows faster than they are redesigning identity controls for them.
Key questions
Q: What breaks when autonomous agents can act faster than access reviews?
A: Traditional access reviews assume privileges persist long enough to be inspected after the fact. When an agent acquires and uses authority inside a short task window, the review cycle can miss the risky action entirely. That makes runtime issuance, not retrospective certification, the control point that matters.
Q: Why do autonomous AI systems create more identity risk than normal automation?
A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person. That makes intent less predictable and review cycles less useful. The risk increases when the system can broaden scope or trigger actions that affect data, money, or compliance.
Q: What do security teams get wrong about AI agent identity governance?
A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.
Q: How should organisations separate duties when multiple agents are involved in a workflow?
A: Do not allow one agent to both prepare and approve a sensitive action just because the workflow is machine-paced. Split creation, validation, and approval across distinct identities, and require policy checks at each stage. That prevents a single agent or agent swarm from silently completing a full business transaction end to end.
Technical breakdown
Why static scripts fail for autonomous agents
Deterministic scripts follow predefined paths, so their access pattern can be reasoned about in advance. Autonomous AI agents are different: they operate on context, probability, and runtime decision-making, which means the tool sequence and timing are not fixed before execution begins. That breaks the assumption that identity can be safely authorised once and then reviewed later. Identity orchestration has to sit in the execution path because the agent is not merely automating a task, it is choosing how to complete it. In practice, that shifts control from static policy design to live issuance, delegation, and revocation decisions.
Practical implication: Treat agents as runtime identities whose permissions must be issued and removed in the execution path, not pre-baked into scripts.
MCP turns agent access into an identity problem
Model Context Protocol makes it easier for agents to call tools and retrieve external data, but ease of connection is not the same as governed access. If the agent is not bound to identity, policy, and registration, MCP becomes a loose control surface where credentials fragment and tool reach expands faster than oversight. The risk is not the protocol itself, but the lack of policy-bound authentication and authorisation around it. Once an agent can discover and call tools dynamically, the security question becomes whether each call is accountable, scoped, and revocable in real time.
Practical implication: Wrap MCP-connected tools in identity-bound policy enforcement instead of treating protocol connectivity as sufficient control.
Why access review breaks down for agentic behaviour
Access review works when privilege persists long enough to be observed, certified, and removed if needed. Autonomous agents compress that lifecycle into a single session or task, so there may be no stable entitlement state for a reviewer to inspect after the fact. That is an assumption collapse, not just a control gap: governance built around persistent access cannot see ephemeral, action-scoped privilege use. The control point moves from recertification to runtime authorisation, because by the time a review happens, the relevant access path may already be gone. The problem is especially sharp when agents inherit privileges from humans or workloads without a distinct governance record.
Practical implication: Move high-risk agent access decisions into issuance and revocation controls rather than relying on periodic review cycles.
Threat narrative
Attacker objective: The objective is to use legitimate-looking agent access to reach data, systems, or actions that would not be acceptable under human-paced governance.
- Entry occurs when an autonomous agent is given broad access to APIs, data sources, or MCP-connected tools without identity-bound policy control.
- Credential or privilege use follows immediately as the agent inherits delegated access from a human or workload identity and starts moving through legitimate workflows.
- Escalation happens when the agent chains tools or sub-agents faster than governance can observe, widening access across systems inside a single session.
- Impact is the completion of unauthorised or poorly governed actions, with audit and compliance teams left reconstructing events after the fact.
Breaches seen in the wild
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity orchestration is now the control plane for agentic systems: The article is right to reject script-based thinking, because autonomous agents do not behave like fixed workflows. When an actor can choose tools and timing at runtime, the identity layer has to govern the session, not just the account. The practitioner implication is that agent access must be treated as live identity orchestration, not as automation hygiene.
Access review is the wrong centre of gravity for autonomous privilege: Recertification assumes the privilege still exists when someone looks at it. That assumption fails when an agent acquires, uses, and discards access within one task. The implication is that governance for autonomous actors must move upstream to issuance, delegation, and runtime revocation.
Runtime accountability is the real missing control: The article surfaces a named gap that matters more than tool sprawl, which is identity without traceable decision context. If an agent can call tools through MCP, inherit delegated access, and leave only partial logs, the organisation cannot reconstruct why a decision happened. Practitioners need to understand that auditability must be designed into the decision path, not recovered later from after-action logs.
Shadow agents create the same governance problem that shadow IT once did, but faster: The difference is that the asset is no longer a SaaS subscription but an identity-bearing runtime actor. That means discovery, registration, and offboarding have to work across human, workload, and agent identities together. The practical conclusion is that identity programmes now need a single governance fabric across all three actor types.
Human-centric compliance models collapse when the subject is a machine decision-maker: KYC, separation of duties, and approval chains all presume a human operator somewhere in the loop. Autonomous agents weaken those assumptions because the decision, the tool call, and the execution can occur without human pacing. Practitioners should read this as a signal that governance policies must be rewritten around actor behaviour, not job titles.
From our research library:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Runtime identity, not script logic, is the boundary that matters: When an agent can choose tools, combine context, and act without a human approval gate, the governance model has to shift from scheduled review to session-time control. That is why runtime controls become the decisive layer for agentic programmes, especially when access is inherited rather than explicitly re-authorised.
Identity review cadences were built for slower actors: Access review processes assume privilege persists long enough to be certified. Autonomous systems can compress access creation, use, and disposal into a single task, which leaves traditional recertification with nothing durable to measure or revoke.
Agents expose a fast-moving governance gap that many programmes are underestimating: 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey. Programmes that still anchor governance in human-paced approval and review cycles will struggle to establish accountability before the first material incident.
For practitioners
- Define agent-specific identities Issue each agent a distinct identity and avoid shared service accounts so decisions and actions can be traced to one runtime actor.
- Bind tool access to runtime policy Use scoped delegation and policy enforcement so an agent can only call the tools and data sources required for the current task.
- Instrument full decision traces Capture prompt intent, context, attributes, policy decisions, and outcomes so the SIEM can reconstruct why the agent acted.
- Replace periodic review with continuous revocation Remove reliance on access reviews for short-lived agent actions and instead revoke permissions as soon as the task completes or behaviour changes.
- Separate creation from approval for high-risk actions Ensure one agent cannot both prepare and authorise sensitive actions such as account creation, policy changes, or financial approvals.
Key takeaways
- Autonomous AI agents are not just another automation layer, because they introduce runtime identity behaviour that scripts and periodic reviews do not govern well.
- The article's central governance gap is temporal: access can be acquired and discarded faster than human-centric IAM, compliance, and audit models can observe it.
- Practitioners should move control to issuance, delegation, observability, and revocation at runtime rather than relying on after-the-fact certification.
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 SP 800-53 Rev 5 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 centres on agents inheriting and misusing delegated access at runtime. |
| Recommendation — Apply ASI03 to restrict agent privilege inheritance and enforce runtime authorisation checks. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent access depends on how identities authenticate to tools and data sources. |
| NHI-05 — Overprivileged NHI | The article warns against broad delegated access and shared credentials for agents. | |
| NHI-10 — Human Use of NHI | The article discusses humans creating, approving, and inheriting agent access paths. | |
| Recommendation — Harden agent authentication paths so each identity is explicitly bound and verifiable. Review agent entitlements for excess privilege and remove permissions not needed for the task. Separate human and agent authority so no person silently operates through an agent identity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime credential issuance and revocation are central to the article's control model. |
| Recommendation — Use IA-5 to manage agent authenticators across issuance, rotation, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements for autonomous actors. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The article stresses observability and traceability for agent actions and tool use. | |
| Recommendation — Apply PR.AA-05 to enforce least-privilege authorisations for agent identities. Monitor agent activity continuously so suspicious tool calls and privilege use surface quickly. | ||
Key terms
- Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
- Runtime Identity Orchestration: Runtime identity orchestration is the practice of making access decisions at the moment a workload acts, rather than only when it is provisioned. It uses context such as environment, task, and requested operation to decide whether a non-human identity should be allowed to proceed.
- Identity-based Policy: An identity-based policy attaches to a user, group, or role and defines what that identity is allowed to do. It travels with the identity rather than the target resource, which makes it useful for central entitlement management. The main governance risk is allowing these policies to grow broader over time.
- Assumption collapse: Assumption collapse occurs when a security model relies on a premise that no longer matches the actor's behaviour. In identity work, that usually means the model assumes a human-paced, stable access pattern, while the real actor can act faster, delegate differently, or change scope at runtime.
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 June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org