What is identity and privilege abuse in AI agents?

Identity and privilege abuse in AI agents occurs when an agent has more permissions than it needs for its task, or when it uses another entity's identity to access resources beyond its own authorization. It is the third risk in the OWASP Agentic Top 10.

How it happens

Over-provisioned agents: The agent is given admin-level API keys or database credentials because it was easier than creating scoped credentials. When the agent is compromised through prompt injection, the attacker inherits those elevated privileges.

Credential forwarding: The agent uses the human user's credentials to access systems, effectively impersonating the user. Actions taken by the agent appear as if the user performed them, bypassing agent-specific audit trails.

Privilege escalation: The agent discovers that it can modify its own permissions through tool calls. For example, an agent with access to an IAM API could grant itself additional roles.

Cross-tenant access: In a multi-tenant system, an agent serving one tenant accesses resources belonging to another tenant because isolation boundaries are not enforced at the agent level.

The principle of least privilege

Every agent should operate with the minimum permissions required for its task:

• A search agent needs read access to the search API. Nothing else.
• A support agent needs read access to customer records and write access to support tickets. Not admin access to the entire database.
• A code agent needs file read/write in the project directory. Not shell access to the host system.

Enforcement with policies

rules:
  # Support agent policy
  - tool: "customer.lookup"
    action: allow
  - tool: "ticket.create"
    action: allow
  - tool: "ticket.update"
    action: allow
  - tool: "customer.delete"
    action: block
    reason: "Support agents cannot delete customers"
  - tool: "*"
    action: block
    reason: "Tool not authorized for support agent role"

Binding agents to identities

Agents should have their own identities, separate from the users they serve. This enables:

• Agent-specific audit trails: Actions are attributed to the agent, not the user
• Agent-specific permissions: The agent has its own credential scope
• Revocation: An agent's access can be revoked without affecting the user

When the agent needs to act on behalf of a user, use delegated credentials with limited scope and short expiration, similar to OAuth tokens with restricted scopes.

Detection

Monitor for privilege abuse patterns:

• Agent attempting to access tools outside its assigned role
• Agent using credentials that belong to a different entity
• Agent attempting to modify its own permissions
• Unusual resource access patterns that suggest cross-tenant leakage

Sentinel tracks denied actions per session. A pattern of permission-denied errors indicates the agent is probing for access beyond its authorization.