AI agent identity abuse exposes the limits of least privilege

At a glance

What this is: This is an analysis of the OWASP Top 10 for Agentic Applications, with the key finding that identity, privilege, and observability failures explain most real agent risks.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern autonomous tool use, not just access requests, and the same identity controls must work across people, service accounts, and AI agents.

By the numbers:

• Developed by more than 100 security researchers and practitioners, the list identifies the most critical risks facing autonomous AI systems in production today.
• The two principles work together, and every risk in the Top 10 maps back to a failure in one or both.

👉 Read WorkOS's analysis of the OWASP Top 10 for agentic applications

Context

AI agent identity risk is the governance problem created when software can choose actions, invoke tools, and execute workflows without a human approving each step. In the article, WorkOS frames this shift as the move from answer generation to action execution, which is where existing IAM assumptions start to fail.

The core issue for identity teams is not the model itself, but the agent's runtime authority. Once an agent can borrow a user's session, call MCP-connected tools, or operate with a shared service account, least privilege stops being a static provisioning question and becomes a live authorization problem.

For NHI and agentic AI programmes, this is a boundary problem as much as a security problem. The same controls that govern service accounts, tokens, and workload identities now have to account for agent intent, tool chaining, and auditability across delegated actions.

Key questions

Q: How should security teams govern AI agents that can use tools across production systems?

A: Treat the agent as a distinct identity with task-scoped access, not as an extension of the human who invoked it. Every tool call should be authorized at runtime, logged with agent and user attribution, and constrained by resource scope. If the agent can chain actions across systems, governance must cover the sequence, not just the individual permissions.

Q: Why do AI agents create more risk than traditional automation jobs?

A: Traditional automation follows predefined rules and timing, while an agent can choose actions, combine tools, and decide when to act. That means the risk is not just what the system can access, but what it decides to do with that access in the moment. Identity controls must therefore govern runtime behavior, not only provisioning.

Q: What breaks when agents inherit user credentials or shared service accounts?

A: You lose meaningful separation between user intent, machine action, and accountability. A compromised or confused agent can operate with broad standing access, move across systems quickly, and leave an audit trail that looks legitimate until it is too late. This is why borrowed credentials are the wrong foundation for agentic security.

Q: How can teams reduce the blast radius of a compromised AI agent?

A: Revoke resource-scoped access, isolate the agent in a sandbox, and remove its ability to chain privileged tools or delegate further actions. The goal is to break the sequence of action, not just disable the model. If the agent has its own identity, its access should be removable without affecting the user or other workloads.

Technical breakdown

Least agency and agentic privilege boundaries

Least agency is the agentic version of least privilege. It does not just ask what an agent can access, but how much freedom it has to act on that access without checking back. That matters because an agent with broad credentials can take a valid action in an invalid sequence, such as reading sensitive data, writing it elsewhere, and sending it out. In agentic systems, privilege is not only a permission set. It is also a decision space, and the decision space must be constrained separately from access scope.

Practical implication: Define task-scoped permission boundaries before deployment, not after an agent is already operating in production.

Tool misuse, MCP servers, and authorization at invocation time

Agentic tool misuse happens when legitimate tools are combined in unsafe ways. A database query, file write, and email sender may each be acceptable on their own, but together they can create an exfiltration path if the agent is manipulated. MCP-connected tools sharpen this risk because they extend the runtime trust boundary into external services and plugins. The technical issue is not just access to tools, but whether every invocation is checked against policy, schema, and intended workflow context at the moment of use.

Practical implication: Apply policy checks to each tool call and validate arguments against schemas, especially where MCP servers can reach production data.

Identity and privilege abuse across delegated agent sessions

Identity and privilege abuse is the pattern most familiar to IAM teams, but agentic systems make it more severe. Many deployments let agents inherit the invoking user's session or a shared service account with broad access. If that identity is compromised or misused, the agent can move across systems at machine speed while still appearing authorized. Fine-grained authorization, sender-constrained tokens, and resource-scoped permissions are the technical counterweights, but the key architectural point is that the agent needs its own identity boundary rather than borrowed human privilege.

Practical implication: Stop treating agent access as an extension of the human session and issue separate identities for machine action.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a high-speed execution layer for unauthorized access, exfiltration, or operational disruption.

1. Entry occurs when a malicious or poisoned input reaches the agent's planning loop, or when an agent inherits a broad identity through a user session or shared service account.
2. Escalation happens when the agent uses legitimate tools in an unintended sequence, or when privilege and delegation expand beyond the original task scope without additional review.
3. Impact is achieved when the agent performs unauthorized actions across systems, including data access, exfiltration, infrastructure changes, or workflow manipulation at machine speed.

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

Least agency is the governance control plane for agentic AI. The article is right to treat least agency as the agentic extension of least privilege, because the core failure is not just access scope but the freedom to act on that access without review. In practice, that shifts identity governance from entitlement design to runtime decision containment. Teams that still think in static permissions are already behind the control problem. Practitioner conclusion: treat agent decision freedom as a governed asset, not an implementation detail.

Identity and privilege abuse is what happens when agents borrow trust they did not earn. WorkOS is describing a pattern IAM teams already know from service accounts and static API keys, but autonomy makes it materially harder to absorb. The same credentials can be used across multiple systems in a single session, which collapses the value of post hoc review. Practitioner conclusion: separate agent identity from human identity and from shared machine credentials.

Tool misuse becomes a policy problem only when every invocation is constrained in context, not just in capability. The article's ASI02 framing shows why coarse authorization is inadequate when the risk comes from tool sequencing, not a single forbidden action. That makes fine-grained authorization, resource scoping, and invocation-level policy part of the same control fabric. Practitioner conclusion: govern the sequence as well as the permission.

Agentic supply chain risk widens the trust boundary beyond the application itself. Once agents can load tools, prompts, or sub-agents dynamically, each dependency becomes part of the identity perimeter. That perimeter now includes authentication of tools, integrity of prompt assets, and verification of delegation paths. Practitioner conclusion: do not audit only the model layer; audit the runtime dependency graph.

Runtime trust debt: The article exposes a named failure mode where organizations grant action authority before they can observe, attribute, or constrain it properly. This is not a tooling gap alone. It is a governance assumption that autonomy will remain reviewable through existing IAM cadences, and that assumption breaks as soon as the agent can chain actions faster than human oversight can certify them. Practitioner conclusion: redesign the operating model around runtime evidence, not retrospective review.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
• That is why OWASP NHI Top 10 remains the most useful companion resource for runtime governance design.

What this signals

Runtime trust debt: agentic programmes now need to assume that access authority can move faster than human review, which changes how IAM, PAM, and NHI teams think about containment. The question is no longer whether an agent can be assigned access, but whether that access can be observed, attributed, and revoked before the action sequence completes.

With 80% of organisations reporting agent scope overruns, the operational signal is clear: existing review cadences are not keeping pace with autonomous tool use. Teams should prepare for a governance model that treats tool invocation logs, agent identity, and resource scope as first-class control evidence, not secondary telemetry.

That shift also makes the NIST AI Risk Management Framework relevant at the governance layer, while OWASP Agentic AI Top 10 remains the technical threat map for control design. Practitioners who connect those two views will be better placed to govern agents, service accounts, and human delegation together.

For practitioners

• Separate agent identities from human sessions Issue managed identities for agents instead of borrowing the user's session or reusing a broad shared service account. Bind access to the specific task, resource, and environment so a compromised agent cannot inherit more reach than the workflow requires.
• Add policy checks to every tool invocation Apply authorization and input validation at the moment the agent calls a tool, especially where a database, file writer, email sender, or MCP server is involved. This prevents a valid tool chain from becoming an exfiltration path.
• Log agent identity, user intent, and tool sequence together Capture which agent acted, which human approved it, and the full ordered chain of tool calls. Without those three elements in one audit trail, you cannot reconstruct whether a risky action was within scope or a delegated abuse case.
• Sandbox code generation and external dependencies Run agent-generated code in isolated environments and treat third-party tools, prompt templates, and MCP servers as untrusted until authenticated and verified. That reduces the chance that a poisoned dependency becomes the execution path.

Key takeaways

• Agentic security is an identity problem first, because autonomous tool use turns access into action and action into risk.
• The strongest evidence here is scope overrun, with most organisations already seeing AI agents act beyond intended boundaries.
• Practitioners should separate agent identities, enforce runtime policy at each tool call, and build audit trails that capture the full delegation chain.

Key terms

• Least Agency: The minimum amount of decision freedom an agent needs to complete a task. In agentic systems, this extends least privilege by limiting not only what the system can access, but how far it can go without reauthorization, so autonomy stays bounded by task and context.
• Agent Identity: A dedicated identity assigned to an AI agent or other non-human actor so its actions can be governed separately from a human user's session. It allows logging, authorization, and revocation to follow the machine actor rather than collapsing into borrowed credentials.
• Tool Invocation Policy: A rule set that decides whether a specific tool call is allowed in the moment it is made. For agentic systems, the policy must inspect context, resource scope, and sequence, because a safe tool can become unsafe when used in the wrong order or with the wrong inputs.
• Runtime Trust Boundary: The set of components and dependencies an agent relies on while acting, including tools, prompts, memory, and delegation channels. In agentic environments, this boundary changes dynamically, so it must be authenticated, observed, and constrained continuously rather than assumed stable.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents, service accounts, and delegated workflows, it is worth exploring.

This post draws on content published by WorkOS: The OWASP Top 10 for agentic applications: What developers building with AI agents need to know. Read the original.