The four properties that make AI agents a new security problem

At a glance

What this is: This article argues that autonomous AI agents create a distinct security problem because they combine four properties that existing identity and cloud controls were not designed to manage.

Why it matters: IAM, PAM, and cloud security teams need to govern the agent itself, not just the credentials it holds, because runtime behaviour can diverge from static policy.

Context

Autonomous AI agents are software identities that choose actions at runtime rather than following a fixed script. That matters for identity governance because the control model changes when execution becomes decision-making, not simply automation.

The security gap is not that these systems use credentials, but that they combine credentialed access with non-deterministic behaviour and external text-driven influence. Existing IAM and PAM assumptions about predictable use, stable intent, and reviewable access no longer hold cleanly in that model.

Key questions

Q: What breaks when autonomous agents are governed like human users?

A: Session-based IAM breaks first, because autonomous agents can make and execute decisions between review points. That creates identity debt, weak forensic trails, and stale access that outlives the work it was meant to support. Teams need governance that binds identity to action and ownership continuously, not only at login.

Q: When do AI agent credentials create more risk than they reduce?

A: They create more risk when they are long-lived, over-scoped, hard to revoke, or copied into code and prompts. At that point the credential becomes a standing trust asset with unclear ownership. Security teams should reject any pattern that cannot be traced to a specific agent, environment, and revocation process.

Q: How do security teams know if agentic AI controls are failing?

A: The main signs are session drift, repeated retry loops, unauthorized tool calls, and behaviour that diverges from the documented task sequence. If the agent keeps moving through steps after intent-to-tool alignment weakens, the system is drifting beyond its control envelope. In practice, teams should measure the full execution path, not isolated prompts.

Q: What should teams do when an autonomous agent can reach production systems?

A: Teams should restrict the agent’s production reach, separate sandbox and live environments, and require checkpoint enforcement before any production-side action executes. If the agent can directly touch production, the governance model has already given it more operational power than most IAM programmes are designed to handle.

Technical breakdown

Autonomy changes the identity control surface

Autonomy means the agent decides what to do next, which tool to call, and in what order without per-step human approval. That is not the same as scheduled automation, where the execution path is predetermined. Once decisions happen at runtime, the security boundary moves from code review to behaviour governance. The key issue is that access is no longer just granted and used. It is interpreted, combined, and sequenced by the agent itself. Practical implication: treat the agent as the control point, not only the credentials it consumes.

Practical implication: Define governance around the agent's runtime choices, not just the permissions assigned at provisioning.

Non-determinism breaks static assurance for agentic AI

Traditional review assumes the same input produces the same output, so a tested system stays broadly predictable. LLM-powered agents do not behave that way. The same prompt can lead to different tool choices, different orderings, and different downstream actions across sessions. That means a control validated during testing may not describe the production risk a month later. For identity teams, the important shift is that authorisation is no longer a stable property of the workload. Practical implication: add behavioural monitoring because static approval does not guarantee stable execution.

Practical implication: Use runtime detection and behavioural baselines where deterministic assurance is no longer reliable.

External manipulability makes prompt injection an access problem

An LLM-based agent cannot reliably distinguish trusted instructions from instructions embedded in content it reads, such as an email, document, or tool response. That is why prompt injection is not just content abuse. It is a path to influencing an identity that already holds valid access. The article's core point is that the credential is not necessarily stolen. Instead, the agent is induced to misuse legitimate access on the attacker’s behalf. Practical implication: separate input trust from privilege trust, because access scope alone does not stop instruction abuse.

Practical implication: Harden tool outputs and external inputs as potential control inputs, not just data.

Threat narrative

Attacker objective: The attacker aims to make the agent misuse its legitimate production credentials to execute harmful actions without stealing the credential itself.

1. Entry begins when an autonomous agent ingests external text from an email, webpage, or tool response that contains hidden or malicious instructions.
2. Escalation occurs when the agent treats those instructions as actionable guidance and uses its real credentials to call tools or access resources outside the user's intent.
3. Impact follows when legitimate access is misused to read data, write repositories, send messages, or trigger downstream actions with production 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.
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

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 AI agents collapse the assumption that identity is a passive subject of access control. The article is right to separate autonomy from generic automation because the agent is not just using permissions, it is choosing action sequences at runtime. That changes the governance problem from access assignment to action governance. Practitioners should stop treating agentic AI as another workload class and start treating it as a distinct decision-making identity.

Static authorisation models break when the same identity can behave differently across sessions. Non-determinism means yesterday's safe execution path is not a durable assurance signal for tomorrow's run. This is why conventional IAM review logic, which assumes stable behaviour over time, cannot on its own establish trust in agentic systems. The implication is that policy must be paired with behavioural verification at the point of use.

External manipulability is a governance failure mode, not just a content-safety issue. The agent does not merely read untrusted text; it may execute instructions embedded in that text while holding valid privileges. That creates a new trust boundary between content ingestion and privilege use. Security programmes need to recognise that access can be redirected without credential theft, which is a different control problem from ordinary phishing.

Real credentials turn agentic risk into production risk, not sandbox risk. Once the agent has service accounts, API keys, OAuth tokens, or PATs, the consequences of manipulation extend to actual infrastructure, not just model behaviour. Existing IAM, PAM, and CSPM tools still matter, but they govern the credential lifecycle, not the agent's reasoning chain. The field needs agent-level governance because the risky object is the combined identity, tool, and decision loop.

Agentic identity creates an identity blast radius that must be measured at the agent layer. The new concept here is not merely more privilege, but privilege that can be recombined dynamically by an autonomous actor under external influence. That makes inventory, lineage, and behavioural detection central to the operating model. Practitioners should map which agents can reach which tools and datasets, then govern those paths as a live decision surface.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Governance programmes built for static access reviews will struggle with autonomous agents because the relevant behaviour happens inside the session, not after it. When an agent can choose tools, reorder actions, and react to external text at runtime, the control point moves from certification to execution.

Identity blast radius: the practical question is no longer only who has access, but how far a manipulated agent can move once its reasoning path is influenced. That is why agent lineage, tool reach, and behavioural detection need to be managed together, not as separate security disciplines. According to the 2026 Infrastructure Identity Survey, 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

For practitioners

• Map agent lineage and tool reach Inventory who deployed each agent, which credentials it uses, what tools it can invoke, and what data or systems those tools can reach.
• Separate input trust from privilege trust Treat emails, webpages, and tool outputs as potential instruction channels, then restrict what an agent may do when reading untrusted content.
• Baseline agent behaviour before production rollout Record the normal sequence of tool calls, access patterns, and decision paths so deviations can be detected when the same agent behaves differently later.
• Reduce standing privilege for agent credentials Scope service accounts, API keys, OAuth tokens, and PATs to the narrowest viable resources so a manipulated agent has less room to act.

Key takeaways

• Autonomous AI agents change the identity problem because they make access decisions at runtime rather than following fixed automation paths.
• The security risk is amplified by non-determinism and external manipulability, which allow legitimate access to be redirected without credential theft.
• Identity teams should govern the agent itself, baselining behaviour, limiting tool reach, and reducing standing privilege for production credentials.

Key terms

• Autonomous AI Agent: An autonomous AI agent is software that can perceive inputs, decide what to do, and act with limited or no human prompting. In identity security, it is treated as a non-human identity when it can authenticate, call tools, access data, or trigger workflows under its own runtime decisions.
• Non-determinism: Non-determinism means the same input can produce different outputs across repeated runs. In AI security review, that makes benchmarking, auditability, and remediation planning harder because the result is not stable enough to function as a reliable control signal.
• 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 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.

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.