The Product Security Playbook

How to Stop AI Agents From Abusing Borrowed Identities

By Chad Butler ·

Direct answer: You give every agent its own scoped identity, enforce re-authentication on every context switch, and treat delegated credentials like you’d treat a privileged service account … with time-bound access, isolation, and full audit trails.

Why this matters: Identity and Privilege Abuse is the #3 risk on the OWASP Top 10 for Agentic Applications. Most AI agents don’t have their own identity. They borrow yours. Your credentials, your API keys, your OAuth tokens. When one agent delegates to another, those privileges get passed along without anyone checking whether the next agent in line should actually have that level of access. This is the agentic evolution of Excessive Agency (LLM06:2025). It’s distinct from Tool Misuse (ASI02), where an agent misuses tools it already has legitimate access to. ASI03 is about how agents acquire, inherit, and retain access they were never supposed to have.

What you’ll get:

  • A board-ready analogy for explaining identity and privilege abuse to non-technical leaders
  • Practical controls to scope agent identities and break dangerous delegation chains
  • A detection strategy for catching privilege escalation before it causes damage

Prerequisites:

Common pitfalls:

  • Letting agents operate under a human user’s identity because “it’s easier than provisioning a service account”
  • Assuming agents in the same system trust each other by default and that’s fine
  • Ignoring that agents cache credentials between sessions and users

Step 1: How do I explain Identity and Privilege Abuse to my board?

Use the valet key analogy. It makes the invisible risk visible.

AI agents need access to systems to do their jobs. But most agents don’t have their own identity. They operate using the credentials of the person who deployed them or the user they’re acting on behalf of. When that agent delegates to another agent, the credentials go with it. No one checks whether the downstream agent should have that level of access.

Here’s the analogy I use with executives:

You gave the valet your car key. But instead of parking the car, they made copies and handed them to every driver in the lot. And nobody logged who got one. That’s what happens when AI agents pass credentials through delegation chains. Your access becomes everyone’s access.

OWASP calls one version of this the confused deputy problem. A low-privilege agent sends a request to a high-privilege agent. The high-privilege agent trusts it because it came from inside the system. It executes the request without re-verifying the original user’s intent. The high-privilege agent becomes the confused deputy, acting on instructions it shouldn’t trust.

Real-world proof: This isn’t theoretical. OWASP documents a scenario where a finance agent delegates to a database query agent, passing all its permissions. An attacker steering the query agent uses the inherited access to exfiltrate HR and legal data. The query agent was never supposed to have that access. It inherited it.

OWASP documents five categories of identity and privilege abuse:

  1. Un-scoped privilege inheritance: A high-privilege agent delegates to a worker agent and passes its full access context. The worker gets more rights than intended.
  2. Memory-based privilege retention: Agents cache credentials, keys, or retrieved data between tasks. If memory isn’t cleared between sessions or users, attackers can prompt the agent to reuse cached secrets from a prior secure session.
  3. Cross-agent trust exploitation (confused deputy): A compromised low-privilege agent sends valid-looking instructions to a high-privilege agent, which executes them without verifying the original user’s authorization.
  4. Time-of-check to time-of-use (TOCTOU): Permissions validated at the start of a workflow expire or change before execution. The agent continues with outdated authorization.
  5. Synthetic identity injection: Attackers impersonate internal agents by using unverified descriptors like “Admin Helper” to gain inherited trust and perform privileged actions.

Step-by-step guide:

  1. Use the valet key analogy in your next leadership briefing on agentic AI risk
  2. Ask your team: “Do our AI agents have their own identities, or are they borrowing ours?”
  3. Frame the risk as: “We can’t enforce least privilege if we don’t know who the agent actually is”
  4. Reference the confused deputy problem to illustrate how internal trust becomes a vulnerability

Key takeaway: You can’t enforce least privilege on an entity that doesn’t have its own identity. If your agents are borrowing human credentials, you have an attribution gap that makes accountability impossible.

Step 2: How do I scope agent identities and break dangerous delegation chains?

Give every agent its own identity. Bind permissions to purpose. Kill inherited credentials at every handoff.

The root cause of identity and privilege abuse is that agents don’t have distinct, governed identities. They inherit access from humans or other agents, and that access persists beyond its intended scope. The fix is treating every agent like a non-human identity with its own credentials, scoped to a specific purpose, and expired the moment the task ends.

OWASP frames this as closing the “attribution gap.” Without a distinct identity, you can’t audit what the agent did, scope what it should do, or revoke its access when something goes wrong.

Step-by-step guide:

  1. Provision per-agent identities. Every agent gets its own service principal or managed identity. No agent operates under a human user’s credentials. Major platforms already support this: Microsoft Entra, AWS Bedrock Agents, Salesforce Agentforce, and Google Vertex AI all provide agent identity management.
  2. Bind permissions to subject, resource, purpose, and duration. A finance agent that needs to query invoices gets read access to the invoices table for the duration of the task. Not full database access. Not permanent access. Express this as policy, not configuration.
  3. Issue short-lived, task-scoped tokens. Use per-task credentials that expire immediately after the task completes. mTLS certificates or scoped OAuth tokens with tight lifetimes. If an agent’s session ends, its access dies with it.
  4. Break delegation chains. When one agent delegates to another, the downstream agent does not inherit the upstream agent’s credentials. It authenticates independently with its own scoped token. The original intent must be re-validated at every handoff.
  5. Bind tokens to signed intent. Every OAuth token should include subject, audience, purpose, and session. Reject any token use where the bound intent doesn’t match the current request. This prevents a token issued for “query invoices” from being reused to “export customer list.”
  6. Isolate agent memory and context. Run per-session sandboxes with separated permissions and memory. Wipe state between tasks and users. This prevents the scenario where an admin’s cached SSH credentials are available to the next user who opens the same session.
  7. Require re-authentication on context switch. Any time the agent changes tasks, users, or privilege levels, force re-authentication. No coasting on prior authorization.

Example:

  • Before: A finance agent delegates to a database query agent, passing all its permissions. The query agent has access to HR, legal, and finance data. An attacker steering the query uses inherited access to exfiltrate sensitive records.
  • After: The finance agent delegates a task, but the query agent authenticates independently with a scoped token. The token grants read-only access to the invoices table for 60 seconds. It cannot access HR or legal data. The token expires after the query completes.

Key takeaway: Every delegation is a potential privilege escalation. Treat every agent-to-agent handoff as a trust boundary that requires fresh authentication and scoped authorization.

Step 3: How do I detect identity and privilege abuse before it causes damage?

Monitor delegation chains, flag inherited privileges, and alert on credential reuse across contexts.

Prevention controls will fail eventually. You also need detection that catches when agents acquire, inherit, or retain access they shouldn’t have. The challenge is that each individual action may look legitimate. An agent using an API key is normal. The danger is when that API key was inherited from a different agent, cached from a previous session, or used outside its original purpose.

OWASP specifically calls out monitoring for delegated and transitive permissions as a critical control. You need to see when an agent gains new permissions indirectly through delegation chains, not just when permissions are explicitly granted.

Step-by-step guide:

  1. Log every authentication and delegation event. Capture when agents authenticate, what credentials they use, where those credentials originated, and whether they were inherited from another agent. Immutable logs. No exceptions.
  2. Detect transitive privilege escalation. Build detection rules for when a low-privilege agent gains access to high-privilege resources through delegation. Flag cases where a worker agent suddenly has admin-level access it was never directly granted.
  3. Alert on credential reuse across contexts. Monitor for tokens or credentials being used outside their bound intent. A token issued for “query invoices” should not appear in a request to “export customer records.” A token from session A should not appear in session B.
  4. Monitor for synthetic identity patterns. Watch for new agents registering in agent-to-agent registries with high-privilege descriptors. An “Admin Helper” that appears without going through your provisioning process is a red flag.
  5. Detect TOCTOU gaps. Compare the permissions at workflow start against permissions at each execution step. Alert when an agent executes an action after the authorizing user’s permissions have changed or been revoked.
  6. Baseline normal delegation patterns. Define what healthy agent-to-agent delegation looks like. A finance agent delegating to a query agent is expected. A query agent delegating back to a finance agent with elevated permissions is not. Alert on deviations.
  7. Review on a cadence. Assign ownership for reviewing agent identity and delegation logs weekly. Treat it like a privileged access review. Because that’s what it is.

Example:

  • Instrumentation: All agent authentication, delegation, and credential usage logged with full provenance.
  • Signal: Alert fires when a low-privilege sorting agent passes instructions to a finance agent that result in a funds transfer. The delegation chain shows the original instruction came from an external email, not an authorized user.
  • Maintenance: Weekly review of flagged delegation chains. Quarterly red team exercise testing confused deputy attacks and synthetic identity injection.

Key takeaway: Identity abuse is invisible if you only monitor individual actions. You need to see the delegation chain. Who authorized what, who passed credentials to whom, and whether those credentials are being used within their intended scope.

Summary

Identity and Privilege Abuse is the risk that makes least privilege impossible for agentic systems. If your agents don’t have their own identities, you can’t scope their access, audit their actions, or revoke their privileges. They operate in an attribution gap where no one knows who actually authorized what.

Start by getting your leadership team to understand the risk. The valet key analogy works because it makes the invisible problem visible: credentials being copied and passed without tracking. Then provision distinct identities for every agent, bind permissions to purpose and duration, and break delegation chains by requiring fresh authentication at every handoff. Finally, monitor delegation patterns the way you’d monitor privileged access, with special attention to transitive privilege escalation and credential reuse across contexts.

The organizations that get ahead of this risk won’t be the ones with the most agents. They’ll be the ones that can answer a simple question: “Who authorized this agent to do that?” If you can’t answer it today, ASI03 is telling you that’s a problem you need to solve.

Sources & further reading

Whenever you’re ready, here are 3 ways I can help:

DevSecOps Pro - My flagship course for security engineers and builders. 32 lessons, 16 hands-on labs, and templates for GitHub Actions, AWS, SBOMs, and more. Learn by doing and leave with working pipelines. Learn more about DevSecOps Pro

Career Hacking Quest - A practical course and community to help you land security roles. Bi-weekly live resume reviews, interview strategies, and step-by-step guidance for resumes, LinkedIn, and outreach. Learn more about Career Hacking Quest

Lunir - My startup aimed at making breaches optional. Working on a product to make software supply chain remediation easy.

Frequently asked

Questions

How is Identity and Privilege Abuse (ASI03) different from Tool Misuse (ASI02)?

ASI02 is about an agent misusing tools it already has legitimate access to. The agent has the right permissions but uses them in unintended or unsafe ways. ASI03 is about how agents acquire access they shouldn't have through inheritance, caching, or delegation chains. Tool Misuse is about what you do with the keys you were given. Identity Abuse is about getting keys you were never supposed to have.

What is the confused deputy problem and why does it matter for AI agents?

The confused deputy is a classic security concept where a trusted entity is tricked into misusing its authority on behalf of an untrusted one. In agentic systems, a high-privilege agent (the deputy) receives a request from a low-privilege agent and executes it using its own elevated permissions without verifying whether the original user authorized the action. The high-privilege agent is "confused" because it trusts the internal request. This is especially dangerous in multi-agent systems where agents communicate freely.

Can't I just use my existing IAM system to manage agent identities?

Existing IAM systems are designed for human users and traditional service accounts. They weren't built for entities that delegate dynamically, cache context between sessions, and pass credentials through chains of autonomous actors. Major platforms are starting to address this. Microsoft Entra, AWS Bedrock Agents, and Salesforce Agentforce all provide agent identity management capabilities. Evaluate whether your IAM system can handle per-task scoped tokens, signed intent binding, and delegation chain monitoring. If it can't, you need a platform that can.

What if our agents need to share context to function?

Sharing context is fine. Sharing credentials is not. The fix is separating the data an agent needs to do its job from the authentication material it uses to access systems. An agent can receive task context (what to do and why) from an upstream agent without also receiving that agent's API keys or OAuth tokens. Each agent authenticates independently with its own scoped credentials.

Get the next one

Subscribe to the Playbook

You've got the playbook

Now put it to work with us.

Whether you need a pipeline built, a team trained, or a decision pressure-tested, we help product security leaders turn strategy into shipped, secure software.

Book a Strategy Session See Services