AI Security Second Brain

Identity and Privilege Threats (T3, T9)

Properties1
descriptionPrivilege compromise through dynamic role inheritance (T3) and identity spoofing including theft of persistent agent identities (T9), plus the confused-deputy and non-human-identity framing that underpins both.

6 min read

⭐ Star on GitHub

Summary: Privilege compromise through dynamic role inheritance (T3) and identity spoofing including theft of persistent agent identities (T9), plus the confused-deputy and non-human-identity framing that underpins both.

Sources: raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf

Last updated: 2026-07-29

The confused deputy, named

The clearest statement of the agentic authorisation problem in the corpus (source: Agentic-AI-Threats-and-Mitigations-1.1.pdf, p. 13):

As identity flows into integrated tools and APIs, a Confused Deputy vulnerability arises when an AI agent (the “deputy”) has higher privileges than the user but is tricked into performing unauthorized actions on the user’s behalf. This typically occurs when an agent lacks proper privilege isolation and cannot distinguish between legitimate user requests with proper authorizations and adversarial injected instructions.

The worked example: an agent permitted to execute database queries, without validating user input and credentials, tricked into running high-privilege queries the attacker could not run directly.

The prescribed fix is two-part and both parts are necessary — scope agent entitlements by least privilege when acting on behalf of a user, and validate that the user submitting the prompt is authorised for the requested action. The second half is the one implementations skip.

Non-Human Identities

Agents “often operate under NHIs when interfacing with cloud services, databases, and external tools. Unlike traditional user authentication, NHIs may lack session-based oversight, increasing the risk of privilege misuse or token abuse if not carefully managed” (p. 14). Machine accounts, service identities and agent-based API keys.

The absence of session semantics is the structural issue: there is no login, no timeout, no “who was at the keyboard.” Revocation and rotation become the only levers.

T3 — Privilege Compromise

“Privilege Compromise occurs when attackers exploit mismanaged roles, overly permissive configurations, or dynamic permission inheritance to escalate privileges and misuse AI agents’ access” (p. 26).

OWASP identifies four distinct failure modes (pp. 14, 26):

  1. Overly broad API scopes — restrictions enforced at the tool API, but the scope permits “exfiltrating data instead of retrieving authorized information.”
  2. Implicit privilege escalation — agents inheriting excessive permissions from user sessions or service tokens.
  3. Tool chaining across boundaries — “even when individual tool APIs enforce restrictions, agents can chain multiple tools in unexpected ways, bypassing intended security controls,” e.g. retrieving sensitive data via an external API and embedding it in a user-visible response.
  4. Autonomous inheritance — “AI agents autonomously inherit permissions, creating security blind spots where temporary or inherited privileges can be abused.”

Partially covered by LLM06 Excessive Agency, but amplified “as agents can dynamically delegate roles or invoke external tools.”

Scenarios (p. 26): Dynamic Permission Escalation (temporary admin rights invoked “under the guise of troubleshooting,” then persisted via a misconfiguration); Cross-System Authorization Exploitation (escalating from HR to Finance through an agent with access to both); Shadow Agent Deployment (an attacker creates a rogue agent that inherits legitimate credentials and operates undetected).

Shadow Agent Deployment is the bridge to T13 — the mechanism is a privilege failure, the effect is a rogue agent.

T9 — Identity Spoofing and Impersonation

“Attackers exploit authentication mechanisms to impersonate AI agents, human users, or external services, gaining unauthorized access and executing harmful actions while remaining undetected” (p. 29). Particularly dangerous “in trust-based multi-agent environments.”

v1.1 sharpens this considerably around persistent agent identity. The table entry names “the theft or misuse of a formal, persistent agent identity (e.g., Microsoft Entra Agent ID), enabling privileged, long-term API access that bypasses the agent’s conversational interface and its guardrails” (p. 18).

That is the sentence to remember. Every guardrail described elsewhere in the document — prompt filtering, output validation, consent flows, HITL — sits on the conversational path. A stolen agent credential routes around all of it.

Six scenarios (pp. 29–30):

  1. User Impersonation — indirect prompt injection into an agent with email privileges, sending malicious mail as a legitimate user.
  2. Agent Identity Spoofing — compromising an HR onboarding agent to create fraudulent accounts within normal-looking behaviour.
  3. Behavioral Mimicry — a rogue agent imitating a legitimate agent’s interaction style and decision-making.
  4. Cross-Platform Identity Spoofing — an adaptive agent altering its identity per authentication context; also privilege inheritance abuse in external tools like GitHub.
  5. Incriminating Another User — acting under another identity to make them liable.
  6. Persistent Agent Identity Takeover — extracting a long-lived API token from misconfigured cloud storage, impersonating the agent across enterprise services, lateral movement via backend automation pipelines. “Because the agent identity is treated as a trusted entity, the attacker maintains undetected, persistent access until the identity is explicitly revoked or rotated.”

Scenario 6 is a conventional secrets-management failure with an agentic blast radius. The token is ordinary; what it authorises is not.

Mitigations — Playbook 4

Pp. 39–40. Both threats plus, per the overview table, T16.

Proactive

  • Cryptographic identity verification for agents
  • Granular RBAC and ABAC scoped to role
  • MFA for high-privilege agent accounts
  • Continuous reauthentication for long-running sessions
  • No cross-agent privilege delegation unless explicitly authorised by a predefined workflow
  • Mutual authentication for AI-to-AI interactions — bidirectional verification
  • Limit credential persistence; short-lived, expiring credentials

Reactive

  • Dynamic access controls that auto-expire elevated permissions
  • Behavioural profiling for inconsistent role assignments
  • Two-agent or human validation for authentication changes
  • Real-time flagging of role inheritance anomalies
  • Time-boxed privilege elevation with automatic downgrade

Detective

  • Track agent behaviour over time for identity inconsistencies
  • Flag privileged actions outside normal scope
  • Correlate identity validation against historical access trends
  • Monitor repeated failed authentication attempts
  • Flag cascading or recursive tool execution across agents, which “may indicate privilege escalation via protocol misuse”; isolate agents producing suspicious protocol traffic such as a sudden spike in MCP tool invocations

The last bullet is the only place Playbook 4 addresses T16 — consistent with the overview table, inconsistent with the playbook’s own header. See agentic-threat-taxonomy for the full list of internal inconsistencies.

Zero trust is the document’s summary posture: “clear identity flows, strict RBAC and a zero-trust model for agent access to enterprise environments” (p. 14).

Graph View

Backlinks