AI agent security risks expose gaps in traditional IAM controls

At a glance

What this is: This is an analysis of AI agent security risks and the controls needed to govern autonomous systems that access data, APIs, and enterprise workflows.

Why it matters: It matters because AI agents sit inside IAM, NHI, and governance programmes at the same time, so security teams need controls that match agent behaviour, privilege, and runtime decision-making.

By the numbers:

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

👉 Read Obsidian Security's analysis of AI agent security risks and mitigations

Context

AI agent security risks arise when software systems make contextual decisions, call tools, and access enterprise data without fitting neatly into traditional application security or human IAM models. The primary gap is not just control failure, but governance mismatch: programmes built for static users and predictable workflows do not fully describe what an autonomous agent can do at runtime.

In practice, these agents often combine broad data access, API connectivity, and elevated privileges across SaaS and cloud environments. That makes them closer to machine insiders than ordinary applications, which is why identity, authorisation, monitoring, and lifecycle controls all need to move together.

The article frames 2025 as a turning point because organisations are deploying agents at scale without enough oversight. That starting position is typical of early-stage AI adoption, not an outlier, which is exactly why the control gap is becoming visible now.

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 service accounts and AI agents create different identity risk than employees?

A: Service accounts and AI agents create different risk because they are not managed through HR lifecycle events, yet they often hold broad technical permissions and can act at machine speed. That makes ownership, monitoring, and revocation harder to sustain with human-centric controls. Risk rises when their access is persistent, poorly documented, or spread across multiple platforms.

Q: What breaks when organisations rely on periodic access reviews for AI systems?

A: Periodic access reviews break when the identity scope changes between review cycles. AI-enabled workflows can create, use, and retire access faster than reviewers can validate it, so certification no longer reflects reality. That leaves stale permissions active and makes breach exposure harder to detect before it is used.

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 prompt injection matters for AI agent identity

Prompt injection is an input-manipulation technique that changes what an agent decides to do, even when the surrounding application looks normal. The issue is not just malicious text, but the fact that an agent may treat untrusted input as instructions and then act across connected systems. In an enterprise setting, that can convert a routine query into a data access or data-sharing event. The control problem is therefore partly identity-related and partly behavioural: the agent is trusted to interpret context, but context itself becomes part of the attack surface.

Practical implication: treat agent inputs as a security boundary and test whether untrusted content can influence tool calls or access decisions.

Token compromise and excessive privilege in NHI systems

AI agents usually authenticate with API keys, OAuth tokens, service accounts, or certificates, which makes them non-human identities with real operational authority. When those credentials are long-lived or over-scoped, compromise becomes a direct path to enterprise systems rather than a contained application issue. The article’s core warning is that effective authority often exceeds what policy intends, especially across SaaS connections. That means the inventory of issued credentials is not enough. Security teams need runtime truth about what the agent can actually reach and which downstream systems inherit that access.

Practical implication: reduce standing privilege and validate effective authority across every connected system, not just at provisioning time.

Runtime monitoring and policy evaluation for autonomous access

Traditional logging tells you what happened after the fact, but AI agent security needs telemetry that shows behaviour as it unfolds. The article points to behavioural baselines, SIEM integration, and real-time policy decision points because agents can shift access patterns, data volume, and response content within the same session. That creates a different detection problem from human IAM. You are not only verifying identity once. You are continuously evaluating whether the current action still fits the approved context, data sensitivity, and risk score.

Practical implication: build continuous authorization checks and behavioural analytics into agent operations rather than relying on post-event review.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into an authenticated path into enterprise data and downstream systems.

1. Entry occurs when an attacker manipulates an AI agent through prompt injection or steals the token the agent uses to authenticate to enterprise systems.
2. Escalation occurs when the compromised agent uses excessive privilege to reach data stores, SaaS applications, or APIs beyond the intended workflow scope.
3. Impact occurs when the agent exfiltrates data, reveals credentials, or performs unauthorized actions across connected systems at machine speed.

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

AI agents should be treated as machine insiders, not as ordinary applications. The article describes systems that read, decide, and act across multiple enterprise services, which places them inside identity governance rather than beside it. That matters because the risk is defined by authority, not by form factor. Practitioners should read agent security as an NHI governance problem with operational consequences for IAM, PAM, and SaaS access.

Excessive privilege is the named failure mode, but runtime authority is the deeper issue. The article notes that 90% of agents hold excessive privileges and that agents can move far more data than human users. The underlying governance problem is that static entitlement review does not describe effective behaviour once agents start chaining actions across tools. The implication is that access certification alone cannot close the gap.

Identity does not select and combine tools dynamically at runtime was designed for predetermined workflows. That assumption fails when the actor is autonomous because the agent can change action paths, choose tools, and execute without a human approval gate. The implication is that least privilege must be rethought around session-time behaviour, not just initial provisioning.

AI agent governance now depends on runtime truth, not policy intent. The article’s emphasis on behavioural analytics, SIEM ingestion, and continuous verification reflects a broader market shift toward live evidence of what agents do. Static configuration can say one thing while the agent’s actual reach says another. Practitioners should treat observed behaviour as the authoritative source of control validation.

Shadow AI turns identity sprawl into governance blind spots. Thousands of agents can be deployed weekly without oversight, which means untracked credentials and unmanaged access paths become routine rather than exceptional. That is the same pattern identity teams have spent years trying to eliminate in human and service-account estates. The difference is speed, scale, and the ease with which agents can expand their own operational footprint.

From our research:

• AI agents move 16x more data than human users performing equivalent tasks, according to AI Agents: The New Attack Surface report.
• From our research: 90% of agents hold excessive privileges in enterprise deployments, according to AI Agents: The New Attack Surface report.
• For a broader control model, see OWASP Agentic AI Top 10 and map those risks to your agent governance programme.

What this signals

Identity teams should expect AI agents to force a tighter link between entitlement governance and runtime telemetry. Once an agent can move 16x more data than a human user, a single access decision can carry a far larger operational blast radius than the same entitlement in a human workflow. That is why behavioural monitoring and policy decision points need to sit inside the operating model, not beside it. For a practical control lens, pair this with the NIST AI Risk Management Framework.

Excessive privilege becomes harder to justify when the actor can adapt mid-session. The real programme shift is not simply reducing permissions, but proving that the access path still matches the task as the task evolves. That is where the runtime authority gap emerges: what was approved at deployment time is no longer a reliable description of what the agent can do now. Teams should use OWASP Agentic AI Top 10 alongside internal access reviews.

The next maturity step is to connect agent inventory, data classification, and incident response into one control plane. When agents remain undiscovered or unmanaged, the programme has no trustworthy baseline for review, isolation, or revocation. That is especially true in SaaS-heavy estates where identity sprawl often appears first as a convenience layer and later as a governance problem.

For practitioners

• Map every agent to an identity owner Assign a business and technical owner to each deployed agent, then require a named approver for access changes, workflow expansion, and production enablement. Hidden ownership is the fastest route to unmanaged agent access.
• Replace static credentials with short-lived authentication Use certificates, hardware-backed secrets, or tightly scoped short-lived tokens for agent access. Eliminate long-lived API keys wherever possible and revoke credentials immediately when agent behaviour changes or a compromise is suspected.
• Review effective authority, not just assigned roles Compare configured permissions with the actual systems, datasets, and actions an agent can reach across SaaS and cloud services. Prioritise the agents whose effective authority is broader than their intended workflow.
• Instrument runtime behavioural baselines Log prompt inputs, authorization decisions, data access patterns, and output characteristics so you can spot sudden changes in volume, sensitivity, or sequence. Use those baselines to trigger containment before exfiltration is complete.
• Extend zero trust to agent sessions Apply continuous verification to each sensitive action, especially when data classification changes or an agent requests a new tool call. Treat the current context as part of the decision, not a one-time login event.

Key takeaways

• AI agents are non-human identities with behaviour that can exceed static IAM assumptions, so governance has to account for runtime decisions as well as assigned access.
• The article shows that excessive privilege and high data movement are already common, which means the blast radius of a compromised agent is larger than many teams assume.
• Continuous verification, behavioural monitoring, and short-lived authentication are the practical controls that matter when agent actions are not fully predictable at provisioning time.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Over-Privilege: Over-privilege is the state where an identity holds more access than the work requires. In IAM and NHI programs, it usually emerges from role drift, delayed offboarding, emergency exceptions, and copied permissions that are never removed.
• 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.

What's in the full article

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

• Step-by-step guidance for securing AI agent authentication with certificates, short-lived tokens, and automatic rotation.
• Example policy logic for dynamic authorization decisions across data sensitivity, business hours, and anomaly score.
• Concrete monitoring fields to send into SIEM and SOAR for agent telemetry, including prompts, outputs, and authorization events.
• Implementation checklist for testing prompt injection resistance, token compromise scenarios, and model manipulation paths.

👉 The full Obsidian Security post covers the attack vectors, control examples, and compliance considerations in more operational depth.

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 identity security programme, it is worth exploring.