T3 · OWASP Agentic AI v1.1

Privilege Compromise

Last reviewed 2026-05-08 · Severity heuristic: critical

Definition

Privilege Compromise is the exploitation of mismanaged roles, dynamic permission inheritance, or overly broad scopes to escalate what an agent can do. Unlike conventional privilege escalation, the attack often does not require breaking access control. It only requires the agent to use permissions it already has, in combinations the system never anticipated. Implicit privilege escalation and Confused Deputy failures are the canonical patterns.

What it looks like in practice

Dynamic Permission Escalation. An HR onboarding agent is granted temporary write access to the Active Directory provisioning API for the duration of a new-hire workflow. A misconfiguration in the provisioning service means the elevated access token is cached indefinitely rather than revoked when the workflow completes. An attacker who triggers a second onboarding task via prompt injection finds the agent still holds admin-level directory rights and uses them to create a persistent backdoor account. No single step violated the access control model; the escalation happened because revocation was never enforced.

Cross-System Authorisation Exploitation. A multi-agent HR platform links an onboarding agent to a Finance agent for payroll initialisation. The onboarding agent holds an OAuth token scoped to HR data; the Finance agent holds one scoped to payroll records. When the onboarding agent calls the Finance agent on behalf of a newly created user, the Finance agent treats the request as implicitly authorised by the HR-agent’s identity and applies its own broader scope. An attacker who controls the onboarding agent’s inputs can direct it to trigger Finance-agent actions (such as modifying salary records) that were never in scope for either agent individually. This is the Confused Deputy failure: Finance trusts HR’s identity without independently verifying what was authorised.

Shadow Agent Deployment. A developer testing a new agent in a staging environment uses the same Non-Human Identity (NHI) service account as the production deployment because it is faster than provisioning fresh credentials. The staging agent, running in an environment with weaker network controls, is compromised by an attacker. That attacker now holds production-grade credentials: the staging and production agents share an identity. The attacker deploys a rogue agent process using those credentials, which operates silently with the full permission set of the legitimate production agent while the legitimate agent continues to run normally.

Why it’s dangerous

Agents commonly run under Non-Human Identities (machine accounts, service identities, agent-specific credentials such as Microsoft Entra Agent ID). NHIs may lack session-based oversight, persist far longer than user sessions, and chain through multiple backend systems. Combine that with the agent’s freedom to compose tools in unforeseen sequences, and individually-correct permissions can compose into an unauthorised capability.

Where it manifests

Look at the scopes assigned to Non-Human Identities versus what the agent can actually exercise. Trace delegation chains where one agent invokes another with a different identity. Examine any “on-behalf-of” flow where a user’s authorisation is converted into a service-account action further down the call graph.

Detection signals

Monitor the credential lifecycle and delegation chain for the following signals:

  • Agent NHI tokens whose last-rotated timestamp exceeds the organisation’s stated maximum token lifetime, indicating a revocation gap that may persist elevated permissions longer than intended.
  • An agent process authenticating to a backend service with a token whose original grant scope is wider than the calling function requires. Flag by comparing the token’s JWT scp or policy claims against a pre-declared minimum-scope manifest for each agent task type.
  • An agent identity authenticating from two or more distinct source IPs or process environments within a short window (e.g. both a staging subnet and a production subnet), which is a reliable signal of credential reuse across environments or active theft.
  • Delegation chain events where agent A passes an authorisation context to agent B and agent B’s resulting action touches a resource outside agent A’s own permitted scope. Detect by cross-referencing the caller’s access policy against the callee’s resulting resource access in the audit log.
  • A spike in the number of new privileged-account creation events (e.g. directory write operations) from an agent identity in a short window, which indicates either an unintended loop or an active exploitation of retained admin rights.

OWASP Top 10 for Agentic Applications 2026

The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T3 is covered by the following Top 10 entries:

  • ASI03 Identity & Privilege Abuse primary

    When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.

    OWASP LLM Top 10: LLM06:2025LLM01:2025LLM02:2025

Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.

Design principles at stake

When T3 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.

  • Defence-in-Depth Privilege Compromise succeeds without breaking any access control: it only requires the agent to use permissions it already holds in combinations the system never anticipated. Defence in depth means that correctly-assigned permissions at the identity layer are not the only gate: an orchestrator policy checks whether the current task actually justifies the combination of permissions being invoked, infrastructure egress controls limit what even a legitimately-authorised call can reach, and a separate compliance layer flags when an on-behalf-of flow launders a user authorisation into a service-account action with a scope the user never directly granted.
  • Zero Trust Non-Human Identities persist far longer than user sessions and chain through multiple backend systems, so an admission check at session start cannot cover the sequences of tool calls that compose into an unauthorised capability. Every tool call is a fresh policy evaluation: the sub-agent's token is re-checked against the current task scope; the delegation chain is verified at every hop rather than inherited; and a Shadow Agent that inherits legitimate credentials is caught the moment it attempts a call its own task scope cannot justify.
  • Least Privilege The attack surface is precisely the excess between what the agent is permitted to do and what the current task requires: Dynamic Permission Escalation retains temporary admin privileges through a misconfiguration because no system enforces that 'admin' credentials expire at task boundary. Zero-standing-privilege design, where each action draws a fresh narrowly-scoped short-lived credential for the specific resource and action the task needs, means a misconfiguration that leaves an admin token open can only survive until the token's TTL expires, not until an attacker discovers and reuses it.
  • Containment (blast radius) Privilege Compromise gains its leverage from the combination of credential scope and communication reach: once an agent's Non-Human Identity is exercised across HR and Finance via a Cross-System Authorisation Exploitation, the blast radius spans both systems simultaneously. Microsegmenting agents with allow-listed east-west paths (so a People-data agent's credentials have no route into Finance endpoints regardless of what instructions the agent receives) ensures that individually-correct permissions cannot compose into an unauthorised cross-system capability.
  • Separation of Duties An agent that can both request and self-approve an escalation, or that proposes a delegation chain and then executes it, eliminates the independent check that separation of duties is designed to enforce. The planner/executor/verifier split (where the planner holds no execution credentials, the executor performs only actions approved by a task token it did not issue to itself, and the verifier is isolated from the execution path) structurally prevents the implicit privilege escalation pattern where one agent accumulates authority by chaining its own approvals.
  • Least Agency / Minimal Autonomy Privilege Compromise often does not require an exploit: it requires only that the agent exercise permissions it was over-provisioned with 'just in case.' Limiting each agent to the three-dimensional scope of task x resource x action and demoting autonomy tiers when an agent attempts a combination not justified by the current task means the sequence of individually-authorised steps that composes into an unauthorised capability reaches a gate before any cross-system action completes.
  • Complete Mediation A Non-Human Identity that is checked once at admission and then caches its authorisation across a long session can accumulate an effective superset of what any single task required: the delegation chain from HR into Finance is exercised incrementally, with each step individually authorised, until the composite is an on-behalf-of flow that no single authorisation event actually granted. A tool-gateway chokepoint that re-checks every call against the current task's scoped token, with expiry and revocation validated on every invocation, prevents the accumulation pattern that makes cross-system exploitation possible.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T3, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

  • Tier 1 OPA authorisation (Open Policy Agent — a policy-as-code engine for every tool call an agent makes)

    An agent can invoke any tool it has access to, constrained only by its own reasoning. If that reasoning is manipulated or the agent's permissions are misconfigured, it will call tools it should not. OPA addresses this by placing a policy decision point between the agent and every tool invocation: a Rego policy evaluates the agent identity, the tool, and the parameter envelope before execution proceeds, and the agent cannot reason or argue past the result.

    why it helps Privilege Compromise relies on an agent identity holding more authority than its assigned role warrants. OPA enforces the declared scope of each agent identity at the decision layer, so a compromised identity is bounded to what its policy allows, regardless of what its prompt or memory claims.

  • Tier 1 SPIFFE (SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service)

    In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.

    why it helps Privilege Compromise relies on a stolen or misconfigured identity persisting long enough to be useful. SPIFFE issues short-lived SVIDs scoped per workload, so a compromised identity expires quickly and cannot be used to reach other workloads in the same deployment.

  • Tier 2 Agent MFA (MFA for high-privilege agent identities — step-up attestation at credential issuance and action time)

    An agent identity that holds broad write authority is a high-value target: compromising its credential gives an attacker persistent, authenticated access to every system that identity can reach. Multi-factor authentication addresses this by requiring a second factor at credential issuance time, so a stolen token is bounded to its issued lifetime and cannot be silently renewed. For non-human identities the second factor is workload attestation, hardware-bound key material, or certificate-backed proof rather than a phone or one-time code.

    why it helps Privilege Compromise relies on an attacker obtaining and holding a valid agent credential long enough to act on it. Step-up attestation at credential issuance binds the credential to a second factor the attacker does not hold, so a stolen secret is valid only for the lifetime of the issuance window it was bound to and cannot be silently renewed without passing attestation again.

  • Tier 2 Cross-system audit (Cross-system scope auditing — continuous permission reconciliation)

    An agent that operates across HR, Finance, cloud, and SaaS systems accumulates permissions at each boundary, often without any single team seeing the combined picture. Privilege accumulates silently across those boundaries until a quarterly review finds it, by which point a compromised or misconfigured agent has had weeks of unchecked reach. Cross-system scope auditing prevents that by continuously reconciling the agent's actual entitlements against a declared baseline across every system it touches and raising a ticket the moment drift is detected.

    why it helps Privilege Compromise occurs when an agent identity accumulates authority beyond its assigned role, either through misconfiguration or gradual drift across system boundaries. Cross-system audit directly detects that accumulation: it ingests entitlements from every system the agent touches, compares them against the declared baseline, and surfaces any net-new or over-provisioned permission before it can be exercised by a compromised agent.

  • Tier 2 Dual control (Human dual-control — four-eyes rule for irreversible high-impact approvals)

    An AI agent operating with broad authority can propose actions that are irreversible: deleting records, modifying IAM policies, moving funds. A single human reviewer at the approval gate is a single point of failure, one compromised account, one fatigued reviewer, or one successful social-engineering attempt is enough to commit the action. Human dual-control addresses that by requiring two distinct, independent humans to approve before the action commits.

    why it helps Compromised-operator escalation is the threat, an attacker who has taken over an admin account, or an insider acting unilaterally, attempts to approve a privilege-escalating action through the HITL gate. Requiring a second, independent human means a single compromised identity cannot unilaterally commit the action; the attacker must also control or deceive the second approver.

  • Tier 2 JIT elevation (Time-bounded privilege elevation — temporary credentials that expire automatically)

    An agent running with a permanent high-privilege identity gives an attacker, or a misconfigured agent, broad access for as long as that identity persists. Time-bounded privilege elevation addresses this by issuing a short-lived credential tied to a specific action window: the agent holds elevated access only for the duration it needs, and the issuing platform revokes that access automatically when the TTL expires. This is the just-in-time (JIT) access pattern from PAM practice, applied to non-human identities.

    why it helps Privilege Compromise gives an attacker the authority of a compromised agent identity. Time-bounded elevation limits how long that authority is valid: the stolen or manipulated credential expires at its configured TTL, and every subsequent action requires a fresh elevation that can be independently audited or denied.

  • Tier 2 JIT tool grants (Just-in-time tool grants — ephemeral access scoped to a single task)

    An agent that holds a persistent catalog of invokable tools can reach any of them at any point in its session. If its reasoning is manipulated or its identity is compromised, that persistent surface is fully available to an attacker. Just-in-time tool grants remove the standing surface: a policy broker issues a time-bound, task-scoped grant immediately before the tool is needed and revokes it automatically when the task completes or the window expires.

    why it helps Privilege Compromise relies on a compromised agent identity retaining access to tools beyond those its current task requires. JIT grants ensure that a compromised identity can only reach tools that have been explicitly granted for the running task; the rest of the catalog is structurally inaccessible until a new grant is issued.

  • Tier 2 NHI lifecycle (NHI lifecycle management — provision, rotate, audit, decommission)

    A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.

    why it helps Privilege Compromise depends on an agent identity retaining elevated access beyond its intended scope or lifetime. Narrow provisioning sets a defined scope ceiling at issuance; aggressive rotation shortens the window within which a compromised credential can be exercised; re-attestation removes scope that accumulated over time. Together they reduce both the authority a stolen credential carries and the duration it remains usable.

  • Tier 2 Policy bound (Policy-bound autonomy — declarative runtime enforcement of the agent's action space)

    An agent's authority is normally bounded only by its own reasoning. If that reasoning is manipulated, or the agent's identity is compromised, it will attempt actions the operator never intended to permit. Policy-bound autonomy addresses this by placing a declarative enforcement point between the agent and every consequential action: a policy engine evaluates the agent identity, the target tool, and the parameter envelope before execution, and the agent cannot reason or argue past the result.

    why it helps Privilege Compromise occurs when an agent identity acquires or is induced to exercise authority beyond its assigned role, for example through credential theft, prompt injection, or role confusion. The policy engine evaluates the declared scope of each agent identity on every request, so a compromised identity is bounded to what its policy allows regardless of what the agent's prompt or memory claims.

  • Tier 2 RBAC/ABAC (RBAC and ABAC: role-based and attribute-based access control for agents)

    Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.

    why it helps Privilege Compromise occurs when an agent accumulates permissions beyond what any single task requires, giving an attacker a large blast surface if the agent is manipulated or its credentials are stolen. Binding each agent identity to a named role at provisioning time, and further constraining individual tool calls via ABAC conditions, keeps the permissions envelope at task scope rather than system scope.

  • Tier 2 Token TTL (Short-lived tokens — bounding the credential exploitation window for agent identities)

    An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.

    why it helps Privilege Compromise occurs when an attacker obtains an agent credential and uses it to exercise authority the legitimate identity holds. Short TTL bounds the exploitation window to the token's remaining lifetime: a stolen credential becomes useless at expiry without a separate compromise of the renewal path.

  • Tier 2 Tool scope (Least-privilege tool scoping — a hard boundary on what each tool exposes)

    Each tool in an agent's catalog should expose only the methods, resources, and parameter ranges its designated role requires. Over-broad tool surfaces let individually authorised primitives compose into actions no human intended to grant; narrowing the scope at design time reduces both the attack surface and the blast radius of any compromise.

    why it helps Privilege abuse after an agent compromise is bounded by what the agent's token scope permits. Least-privilege scoping ensures a fully compromised agent still holds only the narrowest authority the task required, not the broadest authority it could ever have needed.

Multi-agent variants: OWASP MAS Guide

The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 6 named multi-agent variants of T3, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.

  • L3 Negotiation Hijacking extends T12, T3

    Manipulating inter-agent negotiation protocols to reshape outcomes / monopolise resources.

  • L6 Data Privacy Violations in Inter-Agent Interactions extends T3, T8

    Sensitive data leaked during inter-agent exchanges; a concern specific to multi-agent data sharing.

  • L6 Indirect Privilege Escalation extends T3, T14

    Agent-specific permissions exploited to execute high-privilege actions on a malicious user's behalf.

  • CL Inter-Agent Data Leakage Cascade extends T12, T3

    Sensitive data leaks agent-to-agent via compromised interactions, creating a system-wide privacy issue.

  • CL Privilege Compromise (cross-agent) extends T3, T14

    Compromised admin agent exploits legitimate access to create backdoors / modify security settings.

  • CL Excessive Agency / Permission Bypass extends T3, T14

    Chained authorization across MAS lets a malicious user execute beyond their granted permissions.

Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.

Catalogue extensions: Helmwart T18 to T49

This normalized catalogue includes 4 multi-agent entries based on the OWASP MAS Threat Modelling Guide v1.0 that extend T3. The source guide reuses some numbers between worked systems; these Helmwart entries provide stable detail pages, MAESTRO layers, and mitigation coverage.

Red-team pivot: MITRE ATLAS techniques

MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.

AML.T0012 Valid Accounts view on ATLAS ↗

Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.

Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.

AML.T0055 Unsecured Credentials view on ATLAS ↗

Adversary discovers credentials stored in plain configuration files, environment variables, or model context where they should not be exposed.

Agentic angle: Agent configuration files (system prompts, tool descriptors, MCP manifests) are a fresh credential exposure surface.

AML.T0083 Credentials from AI Agent Configuration view on ATLAS ↗

Adversary extracts credentials, API keys, or service-account tokens from an agent's configuration files, system prompts, or environment.

AML.T0098 AI Agent Tool Credential Harvesting view on ATLAS ↗

Adversary uses access to an AI agent to retrieve credentials stored in or accessible through the agent's connected tools: document stores, code repos, productivity platforms.

Agentic angle: Agent tools aggregate credentials from many integrated services; harvesting them grants lateral movement across the victim's entire connected toolchain.

Sources