The four properties that make AI agents a new security problem

At a glance

What this is: This analysis argues that AI agents create a distinct security problem because autonomy, non-determinism, external manipulability, and real credentials now coexist in one production identity.

Why it matters: IAM, NHI, and autonomous programme owners need to treat agent behaviour as a governance layer in its own right, not as a variation of existing automation or workload access.

👉 Read Clutch Security's analysis of why AI agents create a new security problem

Context

AI agent identity security is now a governance problem, not just a model-risk problem. Existing IAM and PAM assumptions rely on predictable execution, stable approval chains, and credentials that can be governed separately from decision-making. Autonomous agents break that separation because they choose actions at runtime while holding real production access.

The practical issue is that current controls are designed around what a system is allowed to reach, not how it decides to use that access. Once an agent can read untrusted text, select tools dynamically, and act with service credentials, the security boundary moves from the vault to the actor itself.

Key questions

Q: What breaks when an AI agent combines autonomy with real production credentials?

A: The main failure is that access controls no longer describe actual behaviour. An autonomous agent can choose tools, timing, and action sequence at runtime while holding real credentials, so the same entitlement can produce different outcomes from one session to the next. That breaks review, approval, and blast-radius assumptions at the same time.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: IAM and PAM were designed to govern credentials and permissions, not a runtime actor that decides how to use them. When the system can read context, select tools, and act without per-step approval, the control model must account for behaviour as well as access. The result is a governance gap, not just a tooling gap.

Q: How can security teams detect when an AI agent is behaving outside its intended scope?

A: Teams should look for behavioural drift, not just policy violations. Signals include unusual tool sequencing, unexpected destinations, sudden changes in call volume, and actions that follow untrusted input too closely. If the credentials are unchanged but the action pattern is not, the agent may be reacting to manipulated context.

Q: What is the difference between autonomous agents and traditional automation in identity security?

A: Traditional automation follows a fixed script and is predictable from its code. An autonomous agent makes runtime choices about what to do next, which tools to use, and when to act. That difference matters because identity governance can review a script, but it cannot pre-certify every decision a self-directed agent may make.

Technical breakdown

Autonomy changes the control boundary

Autonomy means the agent decides what to do next without per-step human approval. That is not the same as scheduled automation, which follows a fixed script. In security terms, the control boundary moves from the workflow to the decision-making loop. If the agent can choose tool order at runtime, then pre-authorised access lists no longer describe the actual behaviour you must govern. The important distinction is that the system is not merely executing instructions, it is selecting them as it goes. That changes how identity, privilege, and accountability have to be modelled.

Practical implication: governance must track the agent as the decision-maker, not just the jobs it runs.

Non-determinism breaks traditional review assumptions

Non-deterministic agents can produce different outputs from the same input, which means evaluation results do not fully predict production behaviour. Traditional security review assumes stable behaviour: if a system passed yesterday, it will behave similarly tomorrow. With agents, that assumption fails because the same prompt can lead to different tool calls, different sequencing, and different side effects. This makes control testing harder, because the thing being tested is not a static code path but a runtime conversation between model output, retrieved context, and available tools. Review has to shift from static expectation to observed behavioural pattern.

Practical implication: validate agents through continuous behavioural monitoring, not one-time approval.

External manipulability turns ordinary content into an attack surface

External manipulability is the property that makes prompt injection work. An LLM-based agent cannot reliably distinguish trusted instructions from instructions hidden inside emails, web pages, or tool responses. That matters because the agent may treat external text as operational guidance and then use its own credentials to carry out the injected instruction. This is why the problem is not just credential theft. The credential may never be stolen at all. Instead, the agent is persuaded to misuse what it already has. In governance terms, any untrusted text source becomes part of the attack surface.

Practical implication: classify external content as input risk and isolate it from direct action paths.

Threat narrative

Attacker objective: The attacker aims to turn the agent's own production privileges into an execution path for exfiltration, misuse, or unauthorised system changes.

1. Entry occurs when an autonomous agent reads external text, such as an email, webpage, or tool response, that contains hidden instructions. The agent accepts the text as context and begins processing it as part of its task.
2. Credential abuse follows when the agent uses real production credentials, such as an API key or service account, to carry out the injected instruction without recognising the instruction as malicious.
3. Impact emerges when the agent misuses its own privileged access to read data, call APIs, write to repositories, or deploy changes that were never part of the legitimate request.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Autonomous agents are not just another NHI class. They collapse the assumption that access can be governed separately from decision-making. IAM and PAM were built for identities that act inside pre-known workflows. When the actor selects tools, timing, and action sequence at runtime, the governance model no longer describes the behaviour being exercised. The implication is that agent identity cannot be treated as a simple credential container.

External manipulability creates a governance failure mode that classic credential controls cannot see. The dangerous act is not credential theft, but instruction injection through ordinary content channels that the agent trusts. That means the security problem sits inside the reasoning loop, not only at the secret store. Practitioners should recognise this as a control-plane mismatch between content ingestion and action execution.

Real credentials with autonomous decision authority create identity blast radius. A service account or token is no longer just an access artifact if the system holding it can reinterpret context and choose its own actions. That expands the blast radius from a single permission set to the full set of reachable tools and resources. The practitioner takeaway is that agent privilege must be reasoned about as an active execution surface.

Agent-level governance is becoming a distinct discipline, and the market is moving toward that layer. The article's four-property model is useful because it explains why existing security stacks miss agentic risk even when they already manage secrets, roles, and endpoints. The field now needs controls that understand the identity, the reasoning boundary, and the tool chain together. Security teams should expect agent governance to sit alongside, not inside, conventional IAM.

Identity review processes that assume stable behaviour will miss autonomous risk by design. Access reviews, entitlement snapshots, and periodic certification all depend on a system remaining stable long enough to observe it. Autonomous agents can change behaviour from one task to the next without changing the underlying credential. The implication is that governance must move from periodic attestations to ongoing behavioural accountability.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• For a broader governance lens, read OWASP NHI Top 10 for the risk patterns that make agent-level controls necessary.

What this signals

Agent governance is now a boundary problem, not a feature request. Once autonomous systems carry real credentials, the decisive question becomes whether the organisation can explain why an agent acted, not just whether it was allowed to act. With 80% of organisations reporting agents acting beyond intended scope, the operational signal is that control design is already lagging behaviour, not merely deployment volume.

Runtime accountability will matter more than static entitlement reviews. Periodic certification was built for access that persists long enough to be inspected. Autonomous agents can change intent and output without changing the credential, so the governance issue shifts to continuous evidence of behaviour. Teams should expect behavioural telemetry and tool-chain tracing to become core programme requirements, especially when external content is part of the workflow.

Real Credentials, Dynamic Decisions: This is the pattern that security teams need to model. When content can influence action and credentials can execute it immediately, the attack surface is no longer just identity or model risk. It is the interaction between untrusted input, runtime reasoning, and production access, which is why agent governance must be designed as a dedicated control layer.

For practitioners

• Map every agent to its full identity chain Document who deployed the agent, which credentials it uses, which tools it can call, and which resources those tools can reach. Treat the full chain as the audit unit, not the model alone.
• Separate trusted intent from untrusted content Route emails, web pages, retrieved documents, and tool responses through a control layer that prevents direct execution of embedded instructions. The goal is to stop content from becoming an action trigger.
• Apply behavioural baselines to agent activity Monitor for deviations in tool order, call frequency, data destinations, and action timing. Static policy checks will miss runtime drift, so detection has to focus on what the agent actually does.
• Limit production credentials to narrow task scope Reduce the permissions available to each agent and bind them to a specific operational purpose. Short-lived, tightly scoped access lowers the blast radius when the agent is manipulated or misdirected.

Key takeaways

• AI agents create a distinct security category because they combine runtime decision-making, untrusted input, and real access in one system.
• The evidence points to a governance gap, with most organisations saying agent control matters but fewer than half having policies in place.
• Security teams should shift from reviewing credentials alone to monitoring the behaviour, content exposure, and tool usage of each agent.

Key terms

• Autonomous AI Agent: A software identity that decides what to do next, which tools to use, and when to act without per-step human approval. In identity security, the important issue is not whether it is intelligent, but whether its runtime decisions change the meaning of privilege and accountability.
• External Manipulability: The property that causes an LLM-based agent to treat instructions inside external content as if they were operationally relevant. This matters because emails, documents, and tool responses can become covert command channels, turning ordinary content into a security input rather than just data.
• Identity Blast Radius: The total set of systems, data, and actions an identity can affect when its credentials are abused or misdirected. For autonomous agents, the blast radius expands because the actor can combine runtime reasoning with production access, making a single entitlement more consequential than it appears on paper.
• Agent Lineage: The full chain of who deployed an agent, what credentials it holds, which tools it can invoke, and what resources those tools can reach. The term is useful because governance failures often appear at the chain level, not in the model alone.

Deepen your knowledge

Autonomous AI agent identity security is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is defining controls for agents that hold real credentials, that course is a practical next step.

This post draws on content published by Clutch Security: The Four Properties That Make AI Agents a New Security Problem. Read the original.