AI agent security risks expose gaps in traditional IAM controls

At a glance

What this is: This analysis maps the main AI agent security risks and shows why prompt injection, token compromise, excessive privilege, and data exfiltration outpace traditional IAM controls.

Why it matters: IAM, IGA, PAM, and security teams need to treat AI agents as high-privilege identities because static permission models do not fit runtime decision-making or dynamic tool use.

By the numbers:

• 90% of agents hold excessive privileges, creating a gap between claimed configuration and effective authority.
• AI agents move 16x more data than human users performing equivalent tasks, which dramatically expands the blast radius of any single compromised agent.

Context

AI agent security risks arise when software systems can decide, act, and call tools at runtime rather than following a fixed workflow. In practice, that means the identity problem is no longer just authentication or access control, but how to govern a non-human actor whose privileges and actions can change inside a live session.

Obsidian Security argues that enterprises are deploying thousands of agents without sufficient oversight, which turns AI agent identity into a machine-insider governance problem. Traditional controls were built for static applications and predictable users, so the mismatch shows up first in authorisation, monitoring, and incident response.

The article’s central point is not that agents are merely another workload. It is that their runtime behaviour can exceed what was provisioned, reviewed, or even understood at deployment time, which forces IAM, PAM, and Zero Trust programmes to treat them as active identities rather than passive software.

Key questions

Q: What breaks when AI agents have broader access than their tasks require?

A: Over-privileged agents break segregation of duties, weaken auditability, and expand blast radius across transactions, data lookups, and workflow triggers. In banking, a single agent identity can act with more operational reach than any human reviewer can safely justify.

Q: Why do stolen tokens and API keys make ransomware harder to contain?

A: Tokens and API keys often authenticate as legitimate machine or service identities, which means they can bypass the suspicion attached to obvious malware. They also tend to persist across integrations and automation paths, expanding blast radius. Containment becomes harder because the attacker is using a trusted identity rather than forcing a new one.

Q: How can security teams tell whether AI agent approval controls are actually working?

A: Look for evidence that sensitive actions trigger a fresh approval event, that approvals are tied to a specific human principal, and that the agent cannot proceed when the checkpoint fails. If high-risk actions still complete on inherited trust or stale tokens, the control is not working. The test is whether runtime intervention is enforceable, not whether the workflow exists.

Q: How should organisations govern SaaS-based AI agents when they do not control the runtime environment?

A: Organisations should treat SaaS agents as shared-control systems and insist on runtime policy that covers data access, tool use, downstream actions, tenant isolation, and auditability. The practical test is whether the enterprise can enforce its own rules even when the vendor owns the execution environment. If it cannot, the agent is configurable, but not truly governed.

Technical breakdown

Prompt injection changes the trust boundary around agent actions

Prompt injection is an input manipulation technique that causes an agent to follow attacker-controlled instructions instead of the intended policy or task. Unlike classic application flaws, the danger is not only data theft but action steering, because an agent can be induced to reveal information, call a tool, or chain outputs in ways the original designer did not authorise. For identity teams, the key issue is that the trust boundary is inside the interaction loop, not just at the login layer. Practical implication: Validate and constrain inputs at the point where agents decide what to do next, not only where they authenticate.

Practical implication: Validate and constrain inputs at the point where agents decide what to do next, not only where they authenticate.

Token compromise turns agent identity into a high-value access path

AI agents often authenticate with API keys, OAuth tokens, certificates, or service accounts, which makes identity compromise a direct route into enterprise systems. The article highlights that these credentials can carry broad permissions and long lifecycles, so a stolen token is not just an authentication issue but a standing-authority problem. In NHI terms, the risk is that effective access outlives the task that justified it. Practical implication: Treat agent credentials as revocable access objects with scope, duration, and auditability, not as durable technical plumbing.

Practical implication: Treat agent credentials as revocable access objects with scope, duration, and auditability, not as durable technical plumbing.

Excessive privilege amplifies blast radius across SaaS and cloud

When an agent can read from multiple data sources, call external APIs, and write back into business systems, privilege scope becomes the main security control variable. The article’s claim that many agents are over-provisioned matters because an agent does not need to be fully compromised to become dangerous; a small mistake or manipulated prompt can expose data, trigger changes, or cascade into other systems. That makes runtime authorisation and behavioural monitoring more important than static role assignment. Practical implication: Align agent permissions to task-specific reachability and watch for changes in data volume, destination, and sequence.

Practical implication: Align agent permissions to task-specific reachability and watch for changes in data volume, destination, and sequence.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI agent into a pathway for unauthorized access, data exfiltration, and business-system abuse.

1. Entry occurs through prompt injection, stolen API keys, or compromised OAuth tokens that let the attacker interact with the agent as if they were trusted.
2. Credentialed access is then used to exploit the agent's broad permissions and trigger unauthorized data access or tool calls beyond the original task boundary.
3. Escalation happens when the agent aggregates data across systems, making exfiltration or destructive actions possible at a much larger blast radius.
4. Impact is realised through data leakage, unauthorized record changes, or downstream system compromise driven by the agent's own legitimate privileges.

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.

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

AI agent security is an identity governance problem before it is an application security problem. The article shows that the main risk comes from how agents authenticate, accumulate privilege, and act across systems, not from model behaviour alone. That shifts the centre of gravity from static application review to runtime identity control. Practitioners should treat agent identity as a governed execution subject, not a software feature.

Access review assumptions fail when the actor can change state faster than the review cycle. Traditional IAM assumes access persists long enough to be reviewed, recertified, and removed. Autonomous agents can request, use, and discard access inside a single operational window, so the governance model loses its observation point. The implication is that control has to move toward issuance-time policy and runtime verification, because retrospective review no longer captures the full exposure.

Ephemeral privilege without behavioural containment becomes identity blast radius by design. The article’s combination of excessive privilege and high-volume data movement shows why effective authority matters more than nominal role design. A small number of agent actions can reach many systems and amplify one mistake into multi-system exposure. Practitioners should measure agent authority by reachable impact, not by the labels on the role definition.

Runtime truth must replace configuration truth for AI agent governance. The article makes clear that theoretical permissions and effective permissions are not the same once an agent can adapt, synthesize data, and call tools dynamically. That breaks the assumption that a policy review at deployment captures operational reality. The field needs governance models that are anchored in observed behaviour, not in declared intent alone.

Shadow AI creates an NHI inventory problem as much as a security problem. Agents deployed without oversight are unmanaged identities with unknown scope, ownership, and lifecycle state. Without inventory and offboarding discipline, security teams cannot tell which agent holds which access path or whether that access is still justified. Practitioners should frame discovery as governance recovery, not just asset discovery.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime authority, not declared permission, is the real control plane for AI agents. Agent governance fails when reviews are based on what a configuration says instead of what the agent can actually do after prompt manipulation, token theft, or context drift. Security teams need to treat effective authority as the operational truth and build controls around it.

Identity blast radius is the right named concept for this problem. Once an agent can combine data from several sources and act across SaaS systems, one compromised identity can produce disproportionate impact. The 2026 Infrastructure Identity Survey says systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, which shows how quickly scope inflation translates into exposure.

For practitioners

• Constrain agent scopes to task-level reachability Define each agent's allowed data sources, write paths, and external destinations as narrowly as the workflow allows. Recheck scope whenever the agent changes role, prompt set, or upstream data source.
• Replace static keys with short-lived credentials Use certificates or short-lived tokens where possible, and make rotation automatic for every credential tied to an agent. Revocation should propagate immediately across the connected SaaS and cloud systems the agent can reach.
• Instrument runtime behavioural baselines Track normal query volume, call sequences, response patterns, and sensitive data access so deviations are visible before exfiltration. Baselines need to reflect what the agent actually does in production, not what the design document says it should do.
• Inventory and offboard shadow agents Maintain a live record of every deployed agent, its owner, its tokens, and its connected systems. When an agent is retired or changed, remove its credentials and confirm that downstream access paths are closed.

Key takeaways

• AI agents create identity risk because their access, tool use, and data reach can change at runtime in ways static IAM was not built to govern.
• Over-privileged agents and long-lived tokens turn one compromise into a much larger blast radius across SaaS and cloud systems.
• The practical response is tighter scope, short-lived credentials, and monitoring that measures effective authority rather than declared policy.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• 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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.

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.