AI Agent Security: Identity, Auth and Least Privilege

AI agent security is the practice of giving each autonomous or agentic AI a unique identity, authenticating it, and constraining what it can do through scoped, short-lived credentials, tool allow-lists, human checkpoints, and full auditability. The goal is to let an agent act on our behalf against real systems while ensuring it can never do more than the task in front of it requires. Unlike a chatbot that only produces text, an agent takes actions: it calls tools, moves data, triggers workflows, and increasingly hands work to other agents. Every one of those actions runs against a real system with real credentials, which is exactly why identity and authorization sit at the centre of the problem.

Why AI Agents Break Traditional IAM Assumptions

Traditional identity and access management was built around two assumptions: that identities are relatively few and relatively stable, and that a human is behind each meaningful action. Agents violate both. They are non-human identities that can be spun up in seconds, they act continuously without a person watching, and they make branching decisions at runtime that no static access policy anticipated. The scale alone is disorienting. CyberArk’s 2025 Identity Security Landscape report found machine identities now outnumber human identities by more than 80 to 1, with roughly half holding sensitive or privileged access, and 79 percent of security leaders expecting machine identity counts to grow by as much as 150 percent in the following year.

The deeper break is behavioural. A human clicking through an app is bounded by the UI, by working hours, and by their own judgement. An agent is bounded by none of those. It can be manipulated through its inputs, it can chain a dozen tool calls in a second, and if it holds a broad credential it will happily use that credential in ways its designers never intended. As we argued in our guide to building an IAM program that actually works, identity is the real control plane for modern systems — and agents make that truer, not less true. The controls that used to be nice-to-have for service accounts are now load-bearing.

The AI Agent Security Risk Classes

The OWASP Agentic Security Initiative, whose Top 10 for Agentic Applications elevates the risks already driving real production incidents, gives us a useful vocabulary. In practice the failures we see cluster into five classes:

• Excessive agency — the agent can take actions, escalate its own scope at runtime, or recurse without bounds beyond what the task requires; the canonical agentic failure mode.
• Credential and token sprawl — agents accumulate API keys, service-account secrets and long-lived tokens that are broadly scoped, rarely rotated, and often orphaned when the agent is retired.
• Impersonation and confused deputy — a prompt injection tricks a high-privilege agent into using its tools on behalf of a low-privilege attacker, weaponising the classic confused-deputy pattern at machine speed.
• Memory poisoning — an attacker plants malicious content in the agent’s persistent memory or retrieved context so it influences later decisions long after the initial injection.
• Cascading multi-agent failures — one compromised or misbehaving agent passes bad instructions or forged authority down a chain of sub-agents, and a single mistake propagates across the whole system.

These are not exotic. Prompt injection turning into a confused-deputy action is simply the agentic version of the injection attacks we covered in our work on prompt injection against LLM apps — the difference is that now the injected instruction reaches a tool with write access instead of just shaping a text reply. That single change is what turns a content problem into a security incident.

Agent Identity and Least Privilege

The foundation is simple to state and hard to retrofit: every agent needs its own verifiable identity, distinct from the human who initiated the work and from every other agent. A shared service account across a fleet of agents destroys attribution — when something goes wrong you cannot tell which agent did it, and you cannot revoke one without breaking all of them. Emerging patterns give agents cryptographically verifiable workload identities, for example SPIFFE identity documents (SVIDs) issued to each agent runtime, or decentralized identifiers anchored to a human principal or legal entity.

Least privilege for agents means scoping permission by task, not just by identity. The OAuth ecosystem is adapting to this: token exchange (RFC 8693) lets an agent trade a broad base token for a narrowly scoped, audience-restricted token that expires in minutes, and the Rich Authorization Requests extension (RFC 9396) lets an agent request just-in-time authorization for a single action rather than holding standing access. The principle is the same discipline we described for privileged access management — no standing privilege, credentials that are short-lived and requested at the moment of use — applied to a population of identities that dwarfs the human one.

A Control Model for Securing AI Agents

Pulling the pieces together, a defensible agent deployment implements five controls in order. Treat this as a checklist before any agent touches production systems:

• Give each agent a unique identity. No shared service accounts; every agent authenticates as itself so every action is attributable and independently revocable.
• Issue scoped, short-lived credentials. Use token exchange and just-in-time authorization so an agent holds only the permissions for its current task, and those permissions expire in minutes.
• Enforce tool allow-lists. Bind each agent to the minimum set of tools its task requires — a planning agent has no write access, a summariser has no outbound email — so entire failure classes never become reachable.
• Require human-in-the-loop for high-impact actions. Pause for explicit confirmation before irreversible or expensive operations: payments, external email, production changes, data deletion.
• Make everything auditable. Log every action, tool call and delegation with the full lineage from the initiating human through each sub-agent, so you can trace and reconstruct any decision.

None of these controls is novel on its own; the discipline is applying all five together and refusing to ship an agent that skips any of them. The reliability patterns we described for building AI agents that survive production — bounded tool surfaces, bounded iteration, risk-aware human checkpoints — are the same controls viewed through an engineering lens rather than a security one. Reliability and security converge on the same architecture: constrain the agent, verify its actions, and never trust the model as the whole system.

Governance, Monitoring and Observability

Controls decay without governance around them. Agents need the same lifecycle rigour as any privileged identity: an owner, a documented purpose, a defined blast radius, periodic access review, and prompt decommissioning so retired agents do not leave orphaned, over-permissioned credentials behind — one of the failures catalogued in the 2025 OWASP Non-Human Identity Top 10. This is agent security taking its place inside a broader defense-in-depth program for GenAI systems rather than as a bolt-on afterthought. Ownership matters as much as tooling: someone must be accountable for each agent the way an application owner is accountable for a service, with the authority to revoke it, tighten its scope, or pull it from production when its behaviour drifts from its documented purpose.

Monitoring closes the loop. Because agents act autonomously, the audit trail is not just for forensics — it is the primary way anomalous behaviour is detected at all. Watch for scope escalation, unusual tool sequences, spikes in iteration or token spend, and delegation chains that reach resources the initiating human could not access directly. Observability that traces the full delegation lineage lets us answer the only question that matters after an incident: which agent, acting on whose authority, took which action against what. An agent you cannot answer that question about is an agent you do not actually control.