The OWASP resource page is dated 9 December 2025. The full report identifies itself as Version 2026. That explains why both years appear in references to the same release. OWASP developed the list with input from more than 100 security researchers and practitioners.
The list is a risk and mitigation framework. An audit also needs defined criteria, a complete population, evidence from the enforcement point, and a test that can fail. This guide adds that operating layer. Each of the ten OWASP Agentic Security Initiative (ASI) categories maps to a runtime response, a compact evidence package, and a reproducible audit procedure. The mapping is an independent KLA interpretation of the OWASP report.
The complete runtime control and evidence map
Start with the action an agent can take, the authority required for that action, and the system boundary that can enforce the rule. A detector can raise a signal. The runtime control determines whether the action proceeds, pauses, slows down, or stops.
The evidence column names the minimum package an auditor should request. The audit test column defines the negative case: a deliberately hostile or invalid condition that the control must contain.
| OWASP risk | Runtime control | Evidence package | Audit test |
|---|---|---|---|
| ASI01 Agent Goal Hijack | Tag external content as untrusted; compare proposed action intent with the approved goal; block or require approval when goal, destination, or parameters drift. | Pinned goal and policy version; input provenance; policy decision; proposed tool arguments; Lineage Record; downstream-call result. | Place conflicting instructions in a retrieved document and verify the original goal remains authoritative and no unapproved call reaches the destination. |
| ASI02 Tool Misuse and Exploitation | Enforce a Tool Catalog allowlist, typed argument constraints, Data Boundaries, output checks, rate limits, and approval for consequential operations. | Tool definition and version; effective allowlist; policy decision; input and output hashes; approval record; execution result. | Ask an allowed tool to perform an out-of-scope operation and verify the runtime blocks or pauses it before the connector call. |
| ASI03 Identity and Privilege Abuse | Bind each action to a distinct workload identity, current delegated authority, tenant context, least privilege, expiry, and revocation checks. | Agent Registry entry; credential reference; effective permissions; delegation chain; tenant context; authorization and policy decisions. | Replay the action with an expired, revoked, cross-tenant, or over-scoped credential and verify denial with zero resource mutation. |
| ASI04 Agentic Supply Chain Vulnerabilities | Inventory and pin models, agents, tools, prompts, packages, and connector descriptors; verify approved provenance and integrity before activation. | Component inventory; manifest and dependency hashes; signatures or attestations where used; review decision; change history. | Change a pinned descriptor, package, prompt, or agent manifest and verify activation or execution fails until the new version is reviewed. |
| ASI05 Unexpected Code Execution (RCE) | Use an execution sandbox, narrow filesystem and network access, command and module restrictions, bounded resources, and approval for destructive actions. | Sandbox profile; policy decision; command or code hash; egress decision; resource limits; execution output and termination reason. | Submit code that imports a forbidden module, writes outside the allowed path, or reaches an undeclared host and verify containment. |
| ASI06 Memory & Context Poisoning | Separate sources by trust level; validate and version memory writes; preserve provenance; require approval for high-impact shared-context changes. | Source identity; retrieval result; content hash; memory version; writer identity; validation decision; dependent Lineage Records. | Insert a poisoned memory item, then start a fresh run and verify the item is rejected, quarantined, or prevented from changing a consequential action. |
| ASI07 Insecure Inter-Agent Communication | Authenticate peers; use typed, versioned messages; bind audience, task, nonce, and expiry; re-evaluate authority at each handoff. | Sender and receiver identities; message schema version and hash; task binding; authorization decision; handoff receipt chain. | Replay, alter, downgrade, or misroute a valid message and verify the receiver rejects it without advancing the Process. |
| ASI08 Cascading Failures | Set budgets, rate limits, retry ceilings, concurrency limits, circuit breakers, blast-radius caps, and a controlled degraded path. | Process and dependency map; configured limits; execution metrics; breaker transitions; Assurance Alert or incident; recovery record. | Force a dependency timeout or bad upstream result and verify retries, fan-out, cost, and downstream mutations stay within the declared bounds. |
| ASI09 Human-Agent Trust Exploitation | Present a Decision Request with consequence, source evidence, uncertainty, and policy basis; require current checks and an accountable reviewer. | Decision Request snapshot; evidence-open and check-verification events; reviewer identity; rationale; decision history; resulting action. | Give the reviewer a confident recommendation with missing or stale evidence and verify approval stays unavailable or records the explicit exception. |
| ASI10 Rogue Agents | Monitor behavior against the declared purpose and release; pause or freeze the agent; revoke access; block further actions; route incident response. | Declared purpose and Release; behavioral signals; policy versions; pause or freeze event; credential revocation; incident and recovery timeline. | Change behavior during an active run, trigger the stop control, and verify new calls cease while completed evidence remains available. |
Runtime responses: keep the decision vocabulary precise
KLA policy decisions use four outcomes: allow, warn, require_approval, and block. Require approval creates a Decision Request and pauses the governed action. A warning records the condition while the declared action continues. A block terminates the governed action.
Throttling belongs to the execution layer. Rate limits, budgets, retry ceilings, and circuit breakers restrict volume and propagation. They can also produce a policy signal that warns, requires approval, or blocks. Keeping these concepts separate makes the audit trail easier to reconcile: the policy result explains authority, while the execution limit explains capacity and containment.
ASI01 Agent Goal Hijack
Goal hijack occurs when hostile instructions redirect an agent objective, plan, or consequential action. The hostile content can arrive through a user message, retrieved document, tool result, template, or peer-agent message. The control point belongs immediately before the proposed action reaches a tool or handoff.
Record the approved goal, the provenance of every untrusted input, the policy and Release versions, the proposed tool arguments, and the resulting action. During testing, place a conflicting instruction in content the agent will retrieve. A passing result preserves the approved goal, records the attempted deviation, and shows zero unapproved downstream calls.
ASI02 Tool Misuse and Exploitation
A legitimate tool can still expose the wrong operation, destination, record set, or call volume. Tool name approval alone gives weak assurance. The runtime must evaluate the concrete operation and arguments against the agent allowlist, Data Boundaries, risk level, and current authority.
The MCP audit guide covers the tool-call record in detail. For this OWASP test, keep the tool legitimate and make the requested operation invalid. Confirm the policy gate stops the request before connector dispatch, the Lineage Record contains the attempted arguments, and the target system shows no mutation.
ASI03 Identity and Privilege Abuse
Every agent and delegated actor needs a distinct identity with current, narrow authority. The enforcement decision must carry tenant context and apply again when execution occurs. A valid identity with an expired delegation or the wrong tenant remains unauthorized for that action.
Test four cases: expired authority, revoked authority, excessive scope, and cross-tenant access. Each case should produce a denial that identifies the failing boundary. Reconcile the denial with target-system records to prove the attempted action created no mutation. The AI agent permissions guide provides the broader entitlement review.
ASI04 Agentic Supply Chain Vulnerabilities
The agentic supply chain includes models, agent releases, prompts, policy packs, tools, connectors, packages, retrieval sources, and update channels. Keep a versioned inventory and bind every active component to a reviewed manifest or approved catalog entry.
Change one pinned artifact during the audit. A manifest hash, connector descriptor, prompt, or dependency version is enough. Verify that the changed component cannot activate under the prior review record. Store the old and new hashes, provenance, reviewer decision, and activation result so the test can be repeated.
ASI05 Unexpected Code Execution (RCE)
Agents that generate or select code need containment around every execution. Apply filesystem boundaries, egress rules, module restrictions, resource limits, timeouts, and a separate approval gate for destructive or privileged operations.
A useful test combines three payloads: a forbidden module import, a write outside the permitted path, and an undeclared network destination. Capture the submitted code hash, sandbox profile, enforcement result, egress decision, and termination reason. The host should remain unchanged after each attempt.
ASI06 Memory & Context Poisoning
Persistent memory turns one compromised input into a later control failure. Treat memory and retrieved context as versioned data with source identity, trust level, writer identity, validation status, and a record of every run that consumed it.
Seed a poisoned memory item, then start a new session whose task would be influenced by it. Verify the item is rejected, quarantined, or prevented from changing a consequential action. Reviewers should be able to trace every dependent decision back to the exact memory version and source.
ASI07 Insecure Inter-Agent Communication
Inter-agent messages carry instructions, data, tool results, and delegated authority. Authenticate both peers and bind each message to its task, audience, schema version, nonce, and expiry. Re-check the sender authority at the receiving boundary.
Replay a valid message, change its audience, alter a typed field, and attempt a schema downgrade. Each case should stop before the receiving stage advances. The evidence package should let an auditor walk the handoff receipts in order and detect a changed middle message.
ASI08 Cascading Failures
One dependency failure can amplify through retries, fan-out, tool chains, and downstream agents. Bound the Process with per-step budgets, call and retry ceilings, concurrency limits, circuit breakers, and a declared degraded path.
Force a timeout and a plausible but invalid upstream result. Measure downstream calls, retry count, duration, spend, queue depth, and resource mutations. A passing test stays inside every declared limit, raises the configured Assurance Alert or incident, and records the recovery decision.
ASI09 Human-Agent Trust Exploitation
Human review only controls risk when the reviewer can see the action, consequence, applicable policy, uncertainty, and supporting evidence. A confident recommendation cannot substitute for those facts. Decision routing should name the accountable role and preserve the reviewer action.
Provide a Decision Request whose recommendation sounds certain while a required artifact is missing or stale. Verify the reviewer cannot approve through the normal path until the check is current, or that an authorized exception records its scope and rationale. Reconcile the final decision with the action that followed.
ASI10 Rogue Agents
A rogue agent departs from its declared purpose or Release after deployment. Monitor actual actions against that declaration and keep the pause, freeze, access revocation, and incident controls outside the agent decision path.
Trigger the stop control during an active run. Confirm that new calls cease, delegated credentials become unusable, queued work follows the declared recovery path, and completed Lineage Records remain available. Record who stopped the agent, the signal that triggered the response, and the conditions for recovery.
How KLA implements the control and evidence layers
Current KLA paths separate the runtime decision, human decision, execution record, and portable evidence package. The records available to a reviewer depend on the instrumented execution path, tenant configuration, and export scope. Test each configured layer for the specific agent, tenant, policy set, and review period under audit.
Offline bundle verification checks signatures, artifact hashes, the bundle Merkle root, and recorded anchor bindings within the exported scope. It does not establish source truth, population completeness, correct policy configuration, or effective operation outside the tested records.
| KLA layer | Current control role | Evidence to review |
|---|---|---|
| Agents, Agent Registry, Tool Catalog, and Data Boundaries | Declare the active Release, agent identity, permitted tools, and governed data access boundaries. | Release and manifest hashes, inventory records, effective tools and boundaries, change history. |
| KLA Policy Engine and Policy Builder | Evaluate governed actions and tool inputs or outputs with allow, warn, require_approval, or block outcomes. Policy-evaluation failure resolves fail closed. | Policy version, decision and reason codes, candidate hashes, entitlement context, remediation and approval reference. |
| Decision Desk | Pause consequential actions for an accountable human and bind the decision to required evidence checks. | Decision Request snapshot, reviewer identity, evidence-open and check-verification events, rationale and decision history. |
| Execution and incident controls | Depending on the governed path and tenant configuration, enforce tool allowlists, rate limits, budgets, circuit breakers, sandbox boundaries, and pause or freeze state. | Execution configuration, enforcement events, metrics, termination reason, incident response and recovery. |
| Lineage Explorer and Audit Trail | Expose proposed and completed actions, policy decisions, tool calls, approvals, versions, timestamps, and actor attribution. | Lineage Records, policy and approval events, tool input and output hashes, execution result, linked Audit Trail entries. |
| Evidence Room | Collect scoped records into a Sealed Evidence Bundle whose internal integrity can be checked offline. | Bundle manifest, scope and omissions, artifact hashes, signing-key details, verification result. |
Build an audit workpaper that can fail
Use one row per risk, system boundary, and test period. Record the population source, control owner, policy or configuration version, test input, expected result, observed result, evidence identifiers, exceptions, and retest date.
The 12-domain enterprise audit framework explains scoping, authority, populations, sampling, evidence integrity, reporting, and ongoing assurance. The AI agent audit program turns those domains into fieldwork, sample design, findings, and follow-up.
- Define the population. List every active agent Release, consequential action type, tool, identity, memory store, and peer-agent route in scope.
- Pin the criteria. Record the OWASP Version 2026 category, internal control statement, policy version, configured limit, and expected runtime response.
- Run negative cases. Execute the ten hostile or invalid conditions in a safe environment with the same enforcement path used by the scoped system.
- Reconcile zero-action claims. A block requires target-side proof that no mutation or connector call occurred.
- Verify the evidence chain. Trace the input, policy decision, human decision where applicable, execution result, and portable evidence artifact.
- Report limitations. Name unavailable populations, untested boundaries, incomplete evidence, and configuration differences between test and production.
Evidence quality checks for every ASI category
A screenshot of a configured rule proves presentation. An enforcement test proves behavior for one condition. Stronger assurance connects configuration, execution, and downstream state across a defined population.
| Question | What good evidence shows |
|---|---|
| Is the source authoritative? | The record comes from the enforcement point or an independently reconciled target system. |
| Is the scope explicit? | Tenant, agent, Release, policy version, action type, tool, environment, and time window are named. |
| Is the record complete? | Input provenance, decision, approval where applicable, execution result, and omissions are present. |
| Is integrity testable? | Hashes, signatures, receipt chains, or ledger proofs can detect a changed artifact within the stated verification boundary. |
| Is the test reproducible? | The test input, expected result, observed result, timestamps, and evidence identifiers let another reviewer repeat it. |
| Is operation proven? | Samples or full-population analytics show how the control behaved during the review period. |
Source, version, and interpretation boundary
OWASP publishes the canonical names, descriptions, examples, and mitigation guidance. Use the official resource page and Version 2026 report as the source for the taxonomy. The report lists the current categories as ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution (RCE), ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, and ASI10 Rogue Agents.
The runtime responses, evidence packages, audit procedures, and KLA mapping in this guide are KLA editorial material. Treat the mapping as an assurance workpaper. OWASP publishes the taxonomy; reviewers remain responsible for their certification, legal interpretation, and compliance conclusions.
The existing OWASP ASI and EU AI Act crosswalk covers regulatory article mapping. This guide stays focused on runtime enforcement and test evidence.
Frequently Asked Questions
Was the OWASP Top 10 for Agentic Applications published in 2025 or 2026?
OWASP dates the resource page 9 December 2025. The full document calls itself Version 2026. Both labels refer to the same release.
Does an OWASP mapping prove that an agent is secure?
A mapping establishes coverage criteria. Assurance also requires a complete scope and population, configured controls, negative tests, operating evidence, exception review, and retesting after material changes.
What is the minimum evidence for an agent action?
Record the agent and human identities, tenant, Release, policy version, input provenance, proposed action and arguments, policy decision, approval where required, execution result, timestamps, and integrity material. Include target-side reconciliation for blocked actions.
How often should teams rerun the ten audit tests?
Run them before activation and after material changes to models, prompts, tools, policies, permissions, memory, routes, or runtime infrastructure. Set a periodic cadence based on action risk and use incidents or drift signals as additional retest triggers.
Key Takeaways
The OWASP Top 10 supplies a stable vocabulary for agentic security risk. The operational question is whether each risk reaches an enforcement point, produces a bounded runtime response, and leaves evidence another reviewer can test. Build the ten negative cases into release acceptance, preserve the complete decision chain, and repeat the tests whenever authority or behavior changes.