TL;DR: As AI agents move 16x more data than human users and increasingly act with delegated authority, Obsidian Security argues that traditional IAM, static RBAC, and perimeter controls cannot keep pace with dynamic access, chaining, and prompt injection risks. The core issue is assumption collapse: access review and least-privilege models were built for stable identities, not runtime decision-making systems.
At a glance
What this is: This analysis says agentic AI has outgrown traditional IAM because autonomous agents now act across SaaS with delegated authority, dynamic privileges, and machine-speed access patterns.
Why it matters: IAM, PAM, and NHI programmes need to account for identity behaviour that changes at runtime, because review, RBAC, and perimeter controls do not map cleanly to autonomous execution.
By the numbers:
- AI agents move 16x more data than human users across the same applications.
Context
Agentic AI security is the control problem that appears when software can make decisions and take actions on behalf of users across enterprise systems. The governance gap is not just more automation, but access that changes at runtime and no longer behaves like a stable human identity.
Obsidian Security frames the issue as an IAM mismatch: enterprises are deploying thousands of AI agents without oversight, and those agents authenticate to SaaS platforms, query databases, transfer files, and interact with customers. The consequence is a widening gap between configured permissions and what the agent can actually reach.
For security teams, the real question is not whether AI agents will be used, but whether identity controls, logging, and response processes can still explain, contain, and revoke access when the actor is making independent decisions inside the workflow.
Key questions
Q: What breaks when autonomous agents are governed like human users?
A: Session-based IAM breaks first, because autonomous agents can make and execute decisions between review points. That creates identity debt, weak forensic trails, and stale access that outlives the work it was meant to support. Teams need governance that binds identity to action and ownership continuously, not only at login.
Q: Why do AI agents increase risk in SaaS environments?
A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change. That turns delegated access into a broader governance problem, especially when the permissions were never reviewed for non-human use. The result is a larger blast radius from the same underlying grant.
Q: What are the signs that an agent’s effective permissions are too broad?
A: Look for agents that can move from retrieval to mutation, inherit user or service credentials without separation, or reach multiple environments with the same identity. Those patterns show that assigned access and usable access are too far apart.
Q: How should organisations decide whether AI agent access belongs in IAM or separate governance?
A: If an AI agent can choose actions, call tools, or move between systems during runtime, it should be governed as a distinct identity class with explicit policy and audit coverage. If it is just a scripted workflow, ordinary machine identity controls may be enough. The decision should follow behaviour, not the label attached to the system.
Technical breakdown
Why static RBAC fails for autonomous AI agents
Role-based access control assigns permissions in advance, but autonomous agents do not stay inside fixed job descriptions. They can chain API calls, change behaviour based on context, and expand their effective access as a task unfolds. That makes a role label a weak proxy for actual authority. In practice, the control problem shifts from defining a role to governing runtime behaviour, data scope, and approval boundaries across multiple systems. When an agent can act on behalf of a user, the blast radius comes from what it can chain, not just what it was provisioned with.
Practical implication: Treat RBAC as a baseline only and add runtime policy controls that constrain what agents can do during execution.
Machine identity, tokens, and delegated authority
Most agents authenticate with service accounts, API keys, certificates, or long-lived tokens, which means compromise or misuse can preserve full access until credentials are revoked. The article also highlights maker mode, where an agent inherits the creator’s authority rather than a tightly scoped service identity. That is a governance hazard because identity no longer represents a single stable actor with one accountability chain. Once delegated authority is too broad, the agent becomes a persistent access path rather than a bounded workload identity.
Practical implication: Separate agent identity from human creator identity and enforce short-lived, revocable credentials tied to a specific workload or task.
Prompt injection and privilege escalation through chaining
Prompt injection works because the agent treats attacker-controlled input as part of its decision context. From there, the system can be induced to leak data, call unauthorised tools, or chain actions across platforms until it reaches privileges no human user should have in one session. This is not classic application abuse alone. It is a control failure in how runtime decisions, contextual inputs, and downstream permissions are composed. Once agents can recursively chain tasks, the security boundary moves from the app front end to the trustworthiness of the entire action path.
Practical implication: Baseline and monitor agent action paths so chained requests, context abuse, and privilege jumps trigger containment.
Threat narrative
Attacker objective: The attacker aims to turn a trusted autonomous agent into a persistent, high-reach access path for data theft, unauthorised actions, and lateral abuse across connected systems.
- Entry occurs through legitimate agent deployment, where the system is given delegated access to SaaS platforms, databases, or files.
- Credential abuse follows when service accounts, API keys, or tokens are compromised or over-scoped, giving the attacker the agent's effective privileges.
- Escalation happens when prompt injection or chained actions drive the agent to access more data, more systems, or broader workflows than intended.
- Impact is widened blast radius across enterprise SaaS, with data exposure, unauthorised actions, and difficult-to-contain machine-speed abuse.
Breaches seen in the wild
- 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.
- 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.
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
Assumption collapse is the core governance story here: access review models were designed for identities whose privileges remain stable long enough to inspect. That assumption fails when an autonomous agent can gain, combine, and discard authority inside one task flow. The implication is that review cadence alone no longer describes control coverage.
Dynamic authority is now the decisive identity problem: configured permissions and effective permissions are diverging faster than classic IAM language can describe. Agents that rewrite prompts, chain API calls, and expand data access based on task context invalidate static role descriptions as a source of truth. Practitioners must govern what the agent can actually reach at runtime.
Maker mode creates orphaned accountability: when an agent runs on the creator's credentials, the human owner and the machine executor are no longer the same governance object. That splits accountability across identity classes and makes offboarding, revocation, and certification materially weaker. The field needs ownership models that follow the agent, not the original operator.
Runtime trust debt: this article describes a growing mismatch between the trust granted at deployment and the trust deserved during execution. The more an agent can independently chain actions, the more that debt compounds across SaaS, data, and approval boundaries. Practitioners should read this as a structural governance gap, not a tuning problem.
Agentic AI security is becoming a cross-domain identity discipline: it sits between IAM, PAM, NHI governance, and AI risk management. ISO 42001 and the NIST AI RMF matter because they give governance structure, but the operational controls still have to look like identity security, not model management. Security leaders need one policy view across human, NHI, and autonomous actors.
From our research library:
- 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.
- Read next: Agentic AI Security Guide
What this signals
Runtime trust debt: security teams should treat delegated AI access as a liability that grows every time an agent can make an independent decision inside a workflow. Access models built for stable identities cannot explain that behaviour, so governance has to shift toward continuous authorisation and containment.
The stronger the agent's cross-system authority, the more the programme must align IAM, PAM, and NHI controls around effective access rather than nominal entitlement. That is the practical boundary between a pilot and a governable deployment.
For practitioners
- Map agent effective authority Inventory what each agent can actually reach across SaaS, databases, files, and downstream APIs, then compare that to its documented role and workflow purpose.
- Replace broad delegated access with task-scoped identities Issue separate identities for agents, avoid creator-credential inheritance, and bind each identity to a narrow task, environment, and set of data scopes.
- Add runtime controls for chained actions Use behavioural monitoring and policy checks to flag prompt injection, unusual API chaining, privilege jumps, and off-hours access that exceeds the agent's normal pattern.
- Build revocation into the agent lifecycle Test immediate credential revocation, preserve logs and context for forensics, and define who can disable the agent when compromise or policy drift is detected.
Key takeaways
- Autonomous agents create an identity governance problem because they act with delegated authority but do not behave like stable human users or static workloads.
- The article's strongest evidence is that agents already move far more data than humans across the same applications, which widens the blast radius of a single compromise.
- The control gap is not just visibility, but the need to govern effective authority, runtime behaviour, and rapid revocation as one system.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets 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 autonomous agents abusing delegated identity and privilege across systems. |
| Recommendation — Bind agent actions to runtime policy checks that limit identity and privilege abuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article highlights service accounts, tokens, and machine identity controls used by agents. |
| NHI-05 — Overprivileged NHI | The article explicitly warns that many agents hold excessive privileges relative to their workflows. | |
| Recommendation — Use short-lived, scoped credentials and revocation controls for agent authentication. Reduce agent permissions to task-scoped access and remove broad standing privilege. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern includes token compromise and chained movement across connected SaaS systems. |
| Recommendation — Map agent compromise paths to credential access and lateral movement detections. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The piece discusses organisational oversight and accountability for autonomous AI systems. |
| Recommendation — Establish governance, accountability, and escalation ownership for agent deployments. | ||
Key terms
- Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
- Effective Authority: Effective authority is the control an identity can actually exercise after all inheritance, delegation, and cross-system relationships are applied. It can be broader than the permissions listed in a single console, which is why local reviews often understate risk. Security teams need to measure effective authority, not only assigned access.
- Maker mode: An operating pattern where an AI agent runs using the credentials of the person who created it rather than a tightly scoped runtime identity. This can overstate privilege, weaken accountability, and expand blast radius because the agent inherits human authority that may exceed the workflow’s needs.
- Runtime trust debt: Runtime trust debt is the accumulation of unresolved trust assumptions that systems continue to rely on while they are running. It appears when identities, permissions, attestations, certificates, or policy checks are not continuously revalidated, creating hidden exposure in live operations. Over time, this debt increases the chance of unauthorized access, drift, and brittle incident response.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org