From agentic AI to autonomous risk: IAM controls are lagging

At a glance

What this is: This is an analysis of why agentic AI security requires identity and access controls built for autonomous behaviour, not just traditional application security.

Why it matters: It matters because AI agents already cross SaaS boundaries, move data at machine speed, and can expand their effective authority beyond what IAM teams think they provisioned.

By the numbers:

• AI agents move 16x more data than human users across the same applications, according to Obsidian Security.
• Research shows 90% of agents hold excessive privileges relative to their actual workflow requirements.

👉 Read Obsidian Security's analysis of AI agent security and autonomous risk

Context

Agentic AI security is the discipline of governing AI systems that can decide, sequence, and execute actions across enterprise tools with minimal human oversight. The primary gap is not model quality, but identity governance: these systems authenticate, query data, and act across SaaS environments in ways that conventional IAM was never designed to observe cleanly.

The governance problem becomes sharper as agents gain delegated authority and dynamically widen their access scope during a task. That creates an operating model where the effective privilege is determined at runtime, not just at provisioning time, which is why the same controls used for human users and static service accounts are no longer enough.

For practitioners, this is an agentic AI issue first and a security tooling issue second. The question is whether identity, access, logging, and containment can keep up with behaviour that changes after authentication, not before it.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate least-privilege design?

A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent. The system may need broad enough access to complete a task, but that same access can overshoot if scope is not tightly controlled. The fix is task-scoped authorisation with clear boundaries, not wider standing access.

Q: What breaks when AI agents inherit the creator’s access without review?

A: Maker-identity inheritance breaks the separation between who built the agent and who should be accountable for its access. The builder’s privileges can become embedded in the artefact, then reused at runtime across systems the builder never intended. That creates hidden privilege transfer and weakens both governance and auditability.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why static RBAC fails for agentic AI security

Role-based access control works when the subject’s task scope is stable and knowable up front. Agentic systems break that assumption because they can chain actions across systems, rewrite prompts, and expand their data path as the workflow evolves. That means the permission set on paper may be far smaller than the authority the agent can exercise in practice. In this model, access is not a fixed entitlement, but a runtime outcome shaped by tool selection, context, and downstream API calls.

Practical implication: map effective authority, not just assigned roles, before allowing agents into production workflows.

How prompt injection becomes an identity problem

Prompt injection is often described as a model-layer issue, but in practice it is an authorisation bypass problem. If an attacker can manipulate the agent’s instructions, the agent may disclose data or perform actions while still operating under valid credentials. The security failure is that authenticated execution is treated as trusted execution. Once the agent’s decision path is compromised, the identity boundary no longer protects the data boundary.

Practical implication: bind agent actions to policy checks and data scopes that survive prompt manipulation.

What maker mode and token compromise reveal about NHI risk

Maker mode, where an agent runs on the creator’s credentials, and long-lived API tokens both create persistent authority that outlasts the task itself. That is classic NHI exposure, but with higher blast radius because the agent can reach multiple systems in one session and act at machine speed. If those tokens are compromised, the attacker inherits not just access, but the workflow logic attached to the agent. The real issue is that identity is being reused as an execution shortcut.

Practical implication: separate creator identity from runtime service identity and eliminate persistent tokens wherever possible.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI workflow into a scalable access path for data theft, unauthorized actions, and downstream system compromise.

1. Entry occurs when an attacker manipulates an agent through prompt injection or steals the token the agent uses to authenticate to SaaS tools.
2. Escalation follows when the compromised agent chains API calls, accesses broader datasets, or operates under maker mode privileges that exceed the immediate task.
3. Impact lands when the agent exfiltrates sensitive data, performs unauthorized actions, or propagates access across connected enterprise systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI security is now an identity governance problem, not just a model safety problem. Once an AI system can decide when to act, which tools to use, and how to chain those actions, the old separation between authentication and authorisation starts to collapse. The issue is no longer whether the model is accurate, but whether the identity behind it can be governed at runtime. Practitioners need to treat agent behaviour as an access-control event, not a software feature.

Least privilege was designed for stable intent, and that assumption fails under autonomous behaviour. Least privilege is easiest to define when a human or service account has a known task before execution begins. That assumption fails when an agent can reinterpret context, select tools dynamically, and alter its own action sequence mid-session. The implication is not merely more permission tuning, but a rethink of how privilege is even defined for runtime decision-making systems.

Identity blast radius is the right named concept for agentic AI governance. AI agents can reach multiple SaaS systems, move data across them, and amplify a single compromise into a multi-platform incident. The blast radius is driven by effective authority, not by the nominal role assigned at deployment. Practitioners should measure how far one agent credential can travel before containment, because that distance defines the real governance problem.

Orphaned agent risk will become a recurring control failure if ownership stays human-centric. When agents are created, delegated, and reused faster than governance processes can track them, accountability weakens even when credentials are still valid. That means recertification, revocation, and logging have to follow the machine identity lifecycle, not just the application lifecycle. The programme implication is clear: if no one can answer who owns an agent at runtime, the control model is already broken.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which leaves nearly half operating without a complete compliance and investigation view.
• Use the OWASP NHI Top 10 to translate these risks into control priorities for agentic applications.

What this signals

Identity blast radius will become a board-level metric for agentic AI programmes. As AI agents gain wider tool access, the question is no longer whether they are useful, but how far one compromised identity can travel before containment. Teams should measure effective authority, not just assigned privilege, because runtime behaviour now determines the real attack surface.

The next control gap will be ownership drift, where agents remain active after the humans who created or approved them have moved on. That is a lifecycle issue as much as a security issue, and it is why recertification, offboarding, and logging must attach to the machine identity itself. The programme that cannot answer who owns an agent at runtime will struggle to govern it at all.

Practitioners should expect agent governance to converge on a blend of NHI controls, Zero Trust Architecture, and behavioural monitoring. For deeper framework context, start with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

For practitioners

• Map effective authority for every deployed agent Document which systems each agent can actually reach, not just which roles it was assigned at provisioning time. Include SaaS apps, databases, file stores, and delegated APIs so the blast radius is visible before incidents occur.
• Replace persistent tokens with short-lived runtime credentials Use certificate-based authentication, workload identity federation, and automatic rotation so agent access expires with the task. Eliminate shared creator credentials and maker mode wherever a scoped service identity is possible.
• Bind agent actions to runtime policy checks Apply contextual controls for data sensitivity, request volume, and anomaly score so an authenticated agent is still evaluated before each sensitive operation. This is especially important where prompt injection could alter execution.
• Instrument behavioural monitoring for agent actions Log every tool call, data access event, and cross-system transaction into SIEM and SOAR workflows so compromise can be detected from behaviour rather than from login status alone.
• Review ownership and offboarding for orphaned agents Assign a human owner, a business purpose, and a removal trigger to each agent before production use. Offboarding should revoke credentials, delete secrets, and retire any connected workflows in the same change window.

Key takeaways

• Agentic AI changes the identity problem by giving software runtime decision authority that traditional IAM was not built to govern.
• The most dangerous gap is effective authority, where an agent can reach far more than its configured role suggests.
• Security teams need runtime policy, behavioural monitoring, and lifecycle ownership before agent deployments scale further.

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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Example architectures for certificate-based authentication and workload identity federation for agents
• Detailed policy logic for attribute-based and policy-based access control in SaaS workflows
• The full incident-response checklist for suspected agent compromise, including credential revocation and forensic preservation
• Configuration examples for SIEM and SOAR integration to detect anomalous agent behaviour

👉 The full Obsidian Security post covers the attack paths, control examples, and governance guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.