ASI03 · OWASP Agentic Top 10

Identity & Privilege Abuse

Definition

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.

What it means in practice

An HR automation agent is deployed with a service account that, by design, has read access to the employee directory, write access to onboarding tickets, and the ability to send email on behalf of the HR team. A single injected instruction, embedded in a CV the agent is asked to screen, tells it to export the full employee list and mail it to an external address. The agent does not need to escalate; it already holds all three capabilities. The access controls were correct for a human who acts in sequence; the agent can exercise them all in one turn.

This is the core problem with credential delegation at the agent level: a principal scoped "for this task" in practice inherits the full permission envelope of its parent account. The blast radius is not determined by the task scope but by every permission the delegated credential holds. The mitigation path is least-privilege delegation: short-lived, narrowly scoped credentials issued per task rather than per agent, with every chained delegation step requiring an explicit grant. Map the agent's full permission surface before deployment: if any single-turn combination of those permissions is unacceptable, the credential is already too broad.

Threat catalogue links

Base-catalog T-numbers follow OWASP source material; normalized MAS scenario entries are Helmwart editorial cross-references. Role colour-codes Helmwart's display weight: chips in the hero use the same scheme.

Primary: strongest pivot. Removing this T-number would gut the entry. Contributing: co-equal mechanism that combines with others to produce the ASI risk. Related: touches the entry but isn't its core; useful cross-reference.
  • T3 Privilege Compromise primary

    Mismanaged roles, dynamic inheritance, or overly broad scopes let agents escalate.

    Open threat detail →
  • T9 Identity Spoofing and Impersonation primary

    Auth mechanisms exploited to impersonate agents, users, or services; misuse of persistent agent identities.

    Open threat detail →
  • T22 Service Account Exposure primary

    Agent service-account credentials accidentally exposed via commits or insecure stores, creating an infrastructure vulnerability.

    Open threat detail →
  • T24 Dynamic Policy Enforcement Failure contributing

    Bug in dynamic policy engine prevents correct policies applying to new contexts (e.g. new employee scopes).

    Open threat detail →
  • T34 Wallet Key Compromise contributing

    Attacker steals private keys from agent wallet, gaining full transaction-signing authority.

    Open threat detail →
  • T36 Smart Contract Vulnerability Leading to Agent Impersonation contributing

    Bug in a smart contract lets an attacker act under the agent identity via that contract's logic.

    Open threat detail →
  • T40 MCP Client Impersonation contributing

    Attacker presents a forged MCP client identity to access an MCP server's tools and data.

    Open threat detail →
  • T43 Network Exposure of MCP Server contributing

    MCP server reachable from networks beyond its intended trust zone; surface available to unintended callers.

    Open threat detail →

MITRE ATLAS technique

MITRE ATLAS catalogues adversary techniques against AI systems. The technique(s) below represent the red-team pivot for this entry: what an attacker is actually doing on the wire. Source: mitre-atlas/atlas-data v5.6.0.

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.

OWASP LLM Top 10 cross-references

From OWASP Appendix A (canonical inheritance)

Helmwart mechanistic crossover (named in OWASP body text, not in Appendix A)

Recommended mitigations

No single control answers an ASI; it is met by a layered stack. The cards below are ranked by how directly each control counters ASI03: the chips on each card name the threat of this ASI it actually covers, colour-coded by that threat's role.

Counters the core

Cover one or more of this ASI's primary threats — the strongest direct response.

Short-lived tokens — bounding the credential exploitation window for agent identities Tier 2
T3T9T22T36

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.

Read more →
NHI lifecycle management — provision, rotate, audit, decommission Tier 2
T3T9T22

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.

Read more →
SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service Tier 1
T3T9T34T36T43T40

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.

Read more →
MFA for high-privilege agent identities — step-up attestation at credential issuance and action time Tier 2
T3T9

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.

Read more →
RBAC and ABAC: role-based and attribute-based access control for agents Tier 2
T3T43T45

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.

Read more →
Policy-bound autonomy — declarative runtime enforcement of the agent's action space Tier 2
T3T24

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.

Read more →
Cross-system scope auditing — continuous permission reconciliation Tier 2
T3

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.

Read more →
Human dual-control — four-eyes rule for irreversible high-impact approvals Tier 2
T3

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.

Read more →
Identity behaviour monitoring — continuous UEBA for non-human identities Tier 2
T9

An AI agent operates under a non-human identity (NHI): a service principal, a task role, or a workload credential. That identity produces a stream of access events that, for a well-scoped agent, forms a narrow and predictable behavioural baseline. Identity monitoring applies User and Entity Behaviour Analytics (UEBA) to that stream, alerting when an observed access pattern deviates statistically from the baseline. Because agent behavioural distributions are tighter than those of human users, a deviation is a higher-confidence signal, and a spoofed or stolen credential used from the wrong workload origin is exactly the anomaly the technique is built to detect.

Read more →
Insider threat program — personnel security for operators of high-privilege agentic systems Tier 2
T9

Privileged-access personnel are the human layer behind every agentic system. A person with legitimate administrative credentials can tamper with logs, manipulate approval gates, or extract training data through authorised channels, and no technical control prevents it when the access itself is valid. An insider threat program addresses that gap: it governs who holds operator access, what they agree to, how quickly credentials are revoked on departure, and whether anomalous behaviour is surfaced before damage accumulates.

Read more →
Inter-agent message signing — end-to-end integrity for A2A and MCP Tier 2
T9

An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.

Read more →
Just-in-time tool grants — ephemeral access scoped to a single task Tier 2
T3

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.

Read more →
Least-privilege tool scoping — a hard boundary on what each tool exposes Tier 2
T3

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.

Read more →
Open Policy Agent — a policy-as-code engine for every tool call an agent makes Tier 1
T3

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.

Read more →
Out-of-band verification — independent-channel confirmation for irreversible agent actions Tier 2
T9

An agent that can propose payments, update banking details, or modify production configuration is, by construction, a manipulation surface. If the only thing standing between a proposed change and its execution is the agent's own UI, a successful prompt injection or RAG poisoning attack requires no additional steps. Out-of-band verification breaks that dependency by routing a one-use confirmation code through a channel that is structurally separate from the agent's primary interaction channel, so an attacker who controls the agent's context cannot complete the approval without also compromising the user's registered secondary device.

Read more →
Secret scanning on agent-generated artefacts — detecting credentials before they escape the trust boundary Tier 2
T22

An agent produces code, configuration files, tool-call payloads, and log records continuously and at a rate no human reviewer can match. Any of those artefacts may contain a live API key, service token, or private certificate, placed there accidentally through model context, or deliberately through prompt injection or context poisoning. Secret scanning places an inspection gate at every agent output seam: regex patterns match known token formats, entropy analysis detects arbitrary high-entropy strings, and validator calls confirm which candidates are live credentials. The CI-secret-scanning pattern is mature; the agentic specialisation is seam placement, moving the scanner from the repository gate to the agent egress point, where artefacts can be intercepted before they reach any downstream system.

Read more →
Time-bounded privilege elevation — temporary credentials that expire automatically Tier 2
T3

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.

Read more →
Broader coverage — 6 controls that address contributing or related threats
Blockchain transaction guard — pre-commit safety checks for every agent-initiated transaction Tier 2
T34T36

A blockchain transaction, once committed, cannot be undone. An agent that signs and broadcasts a transaction without an enforcement layer before it can exceed its authorised value, call a contract it was never provisioned to reach, or drain a wallet in a runaway loop, and by then the funds are gone. A transaction guard intercepts each proposed transaction before signing, checks it against value bounds, a contract allowlist, a gas or compute-unit limit, and a replay-protection nonce, and refuses to sign anything that falls outside declared policy.

Read more →
Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments Tier 2
T43T45

A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.

Read more →
Fail-closed gate — refuse rather than act on uncertain output Tier 2
T24

An agent that is uncertain about what to do next faces a choice: refuse and ask for clarification, or proceed on its best guess. In low-stakes situations that tradeoff is tolerable. In agentic systems that write, delete, or send, a confident-sounding but wrong output can commit an irreversible action. A fail-closed gate resolves that choice structurally: below a configured confidence threshold, the agent stops and escalates rather than guessing.

Read more →
gVisor sandbox — a user-space kernel that intercepts every syscall a container makes Tier 1
T45

When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. gVisor prevents this by inserting a user-space kernel implementation between the container and the host: the container's syscalls go to the Sentry process, not to the host kernel, so the reachable attack surface from inside the container is structurally smaller.

Read more →
MCP server attestation — cryptographic proof of server identity and binary integrity Tier 2
T40

An MCP client connecting to a server has no built-in way to verify that the server at a given address is the expected workload or that its binary has not been replaced. An attacker who can intercept or substitute the server exploits that gap directly. MCP server attestation closes it by requiring the server to present cryptographic proof of two properties before the connection proceeds: that it holds a valid workload identity bound to a trusted certificate, and that its binary matches a signed hash recorded at build time.

Read more →
Plan-vs-goal validation — independently check each proposed step against the original goal Tier 2
T24

A plan-then-execute agent produces a sequence of steps before acting. If the planner is manipulated, it will emit steps that serve the attacker's goal rather than the user's. Plan-vs-goal validation addresses this by placing an independent validator between the planner and the execution loop: it evaluates each proposed step against the originally-declared goal before the agent is permitted to act on it.

Read more →

Sources