AI agent security exposes the limits of traditional IAM controls

At a glance

What this is: AI agent security is about protecting agents that can access tools, data, and workflows, with the key finding that autonomy turns traditional application controls into an incomplete defence.

Why it matters: This matters because identity teams must govern agent actions, not just agent authentication, across NHI, autonomous, and human programmes that now share the same enterprise control surface.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read WitnessAI's analysis of AI agent security and runtime control

Context

AI agent security is the discipline of governing software actors that can choose actions, call tools, and move through workflows with limited or no human intervention. That changes the identity problem from simple authentication to runtime control over what an agent can do, what it can reach, and how far it can move once it is inside a system.

For IAM teams, the real issue is not whether an agent has a login. It is whether the programme can define, observe, and revoke effective privilege across APIs, datasets, enterprise applications, and downstream automation when the agent behaves like an active digital actor rather than a passive application.

Key questions

Q: How should security teams govern AI agents that can use enterprise tools?

A: Security teams should govern AI agents as active identities with named ownership, task-scoped permissions, runtime monitoring, and explicit revocation paths. The control model must cover the service account, the token, and the downstream tools together. If the agent can act on enterprise data or workflows, access review alone is not enough without behavioural telemetry and containment.

Q: Why do AI agents create more identity risk than chatbots?

A: AI agents create more identity risk because they can do more than produce text. They can call APIs, access data, and trigger workflows across systems, which turns model behaviour into operational action. That expands the blast radius from content risk to privilege misuse, data exposure, and lateral movement through delegated access.

Q: What do organisations get wrong about least privilege for AI agents?

A: They often apply least privilege to the initial login while ignoring the tools and data the agent can reach during execution. For agents, effective privilege is dynamic because context, prompts, and workflow inheritance can widen access after the original approval. Least privilege must therefore be expressed at runtime and across the full delegation chain.

Q: Should organisations use different controls for AI agents and human users?

A: Yes. Human IAM can rely heavily on authentication events and periodic access reviews, but AI agents require continuous behavioural controls because they can act without direct human timing. The right model combines identity governance, PAM-style scoping, runtime monitoring, and incident containment for machine actions, not just user sessions.

Technical breakdown

Prompt injection and agent hijacking

Prompt injection is an attack pattern where malicious input changes the agent’s behaviour by overriding intended instructions or steering the model toward unsafe tool use. In agentic systems, that is more serious than chat output manipulation because the model may have direct links to APIs, plugins, or internal workflows. Once the agent accepts the injected instruction, the attacker can push it toward data exposure, credential disclosure, or unauthorised workflow execution. The problem is not just the text prompt. It is the trust boundary between untrusted input and executable action.

Practical implication: separate untrusted inputs from action-capable agent paths and require policy checks before any tool invocation.

Tool permissions, service accounts, and excessive scope

AI agents often inherit permissions through service accounts, API keys, or delegated tokens. That makes them an NHI governance problem as much as an AI problem. If the agent is granted broad access to tools and data, prompt injection or normal model error can turn into privilege misuse. Excessive scope is especially dangerous because many agent workflows chain multiple systems together, so one over-permissioned token can reach far beyond the original task. Least privilege has to be expressed at the tool and endpoint level, not just at the application boundary.

Practical implication: review agent-linked service accounts and tokens as privileged NHIs with narrow, task-scoped permissions.

Runtime monitoring and autonomous workflow containment

Static configuration is not enough for agentic AI because the risk emerges during execution. Runtime monitoring tracks agent actions, API calls, data access, and unusual loops so the programme can detect when an agent departs from expected behaviour. This is the control that exposes whether an agent is merely assisting or actually becoming unsafe in context. Without behavioural visibility, security teams cannot distinguish legitimate task completion from credential misuse, data leakage, or cascading automation across connected systems. Detection must be tied to response, including quarantine and session termination.

Practical implication: instrument agent telemetry at runtime and connect anomalies directly to containment actions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 agent security is now an identity governance problem, not just an application security problem. Once an agent can select tools, move through workflows, and touch enterprise systems, the relevant question becomes who or what is allowed to act, under what scope, and with what revocation logic. Traditional app security focuses on code and requests; agent security must govern behaviour and delegated authority. The practitioner conclusion is that agents should be treated as active identities, not passive software features.

AI agent behaviour exposes a named governance gap: runtime privilege drift. The article shows that an agent’s effective access can expand through tool chaining, prompt manipulation, or workflow inheritance after initial approval. That is not the same as a misconfigured login. It is a control failure where the access that was safe at provisioning time is no longer safe at execution time. The practitioner conclusion is that governance has to follow the session, not stop at onboarding.

Prompt injection is the simplest path to agent hijacking because it targets the decision layer, not the perimeter. If the model can be persuaded to treat hostile instructions as legitimate context, downstream systems become reachable through the agent’s own permissions. That makes trust boundaries in agentic AI fundamentally different from classic web application boundaries. The practitioner conclusion is to assume that any untrusted content can become an action trigger.

Identity controls for AI agents must account for delegated authority across humans, NHIs, and workflows. The article is clear that agents often sit on top of service accounts, API keys, and enterprise automation. That creates a governance chain where human approval, NHI credentials, and agent behaviour all interact. The practitioner conclusion is that lifecycle, access review, and PAM processes must extend to the full delegation chain, not only to the human sponsor.

Agent security is becoming a control-plane issue for the broader identity stack. As more enterprises embed agents into operational workflows, the market will shift toward controls that can observe, constrain, and audit action rather than merely authenticate actors. That validates the move from static entitlements to runtime governance. The practitioner conclusion is that identity architecture now has to include behavioural enforcement for machine decision-makers.

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 44% have implemented policies to govern AI agents, even though 92% say that governing them is critical to enterprise security.
• For a control baseline on the adjacent identity problem, see Top 10 NHI Issues for how access scope, lifecycle, and monitoring failures compound risk.

What this signals

AI agent adoption is scaling faster than governance maturity, which means identity teams will be asked to retrofit controls after deployment rather than before it. The signal for practitioners is clear: inventory, ownership, and runtime oversight need to move into the programme now, before agents become embedded in business-critical workflows. As a reference point, 33% of organisations already report agents accessing inappropriate or sensitive data beyond their intended scope, according to the AI Agents: The New Attack Surface report.

Runtime governance will become the differentiator between an AI pilot and an identity control surface. Teams should expect pressure to prove not just that an agent is authenticated, but that its actions are bounded, logged, and reversible. That shifts the operating model toward continuous observation and away from one-time approval.

The next maturity step is not adding more prompts or policy text. It is linking agent telemetry to access governance so that permission, behaviour, and containment are managed as one system, not three disconnected processes.

For practitioners

• Classify agents as governed identities Place every production agent into the identity inventory with a named owner, declared purpose, and explicit access boundary. Treat the agent’s service account, token, and downstream tool grants as one governed identity chain, not separate assets.
• Scope tool access to task boundaries Remove broad, reusable permissions from agent-linked credentials and replace them with task-scoped access to specific APIs, datasets, and endpoints. Review every inherited permission that can be reached through chained workflows or delegated tokens.
• Monitor runtime actions, not only sign-ins Log agent tool calls, data reads, writes, and repeated automation loops, then alert on behaviour that deviates from the declared task. Tie those alerts to immediate containment so the agent can be quarantined before it propagates further actions.
• Test prompt-injection failure paths Run red-team scenarios that feed hostile instructions into any input source an agent consumes, including tickets, web content, documents, and chat. Verify the agent cannot convert untrusted text into unauthorised tool use or credential exposure.
• Extend access review to the delegation chain Recertify the human sponsor, the service account, and the connected workflow together so approval is not fragmented across teams. Use the same review to confirm whether the agent still needs each permission or whether the path should be removed entirely.

Key takeaways

• AI agent security extends identity governance from static access control to runtime control over actions, tools, and data.
• The scale of the problem is already visible, with most organisations expecting more agents while many still lack effective policy and audit coverage.
• Practical defence depends on treating agents as governed identities, scoping their permissions tightly, and monitoring behaviour continuously.

Key terms

• AI Agent: A software entity that can select actions, use tools, and execute tasks with some degree of runtime independence. In identity terms, the agent is not just a workload. It is a governed actor whose permissions, data access, and behaviour must be tracked across the full execution path.
• Prompt Injection: A technique that manipulates an AI system through crafted input so it follows attacker-supplied instructions instead of the intended task. For agents, the danger is not only bad output. The injected instruction can drive real tool calls, data access, and workflow actions if controls are weak.
• Runtime Monitoring: The continuous observation of what an AI agent is doing while it operates, including tool calls, data reads, outputs, and repeated action loops. This is the control that reveals whether the agent is staying within its approved boundary or drifting into unsafe behaviour.
• Delegation Chain: The sequence of identities and permissions through which an agent receives authority, often from a human sponsor to a service account to connected tools. The chain matters because risk is created by the combined access path, not by any single credential in isolation.

Deepen your knowledge

AI agent governance and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building an identity programme that now has to account for agent behaviour, it is worth exploring.

This post draws on content published by WitnessAI: AI Agent Security and the controls needed to protect agentic systems. Read the original.