The OWASP Top 10 for Agentic Applications is a risk taxonomy, not a checklist that makes an Agent safe. Use it to connect each credible attack path to an enforceable control, an owner, a test, an observable signal, and a recovery procedure.

Key Takeaways

  • Agent security is a system property: model behavior, tools, identities, data, runtime, operators, and recovery all matter.
  • The OWASP list is a taxonomy and prioritization aid, not a permission system or certification.
  • Put authorization, tenant isolation, confirmation, budgets, and rollback at enforceable service boundaries.
  • Treat external content, memory, tool results, and inter-agent messages as untrusted.
  • Test in an isolated environment with synthetic data and reversible side effects.

The Official Risk Themes

The 2026 edition groups agentic risks around these themes:

ID and official risk theme Engineering question
ASI01 Agent Goal Hijack Can untrusted content redirect the Agent away from the authorized task?
ASI02 Tool Misuse and Exploitation Can a valid Tool be called with an unsafe target, argument, or sequence?
ASI03 Identity and Privilege Abuse Are Caller, Agent, Tool, and object authorization explicit and checked server-side?
ASI04 Agentic Supply Chain Vulnerabilities Can a model, Skill, plugin, Tool, dependency, or workflow change without review?
ASI05 Unexpected Code Execution Can generated or retrieved code reach an interpreter, shell, or dynamic loader?
ASI06 Memory and Context Poisoning Can untrusted state persist and influence later tasks?
ASI07 Insecure Inter-Agent Communication Are messages authenticated, authorized, bounded, and replay-resistant?
ASI08 Cascading Failures Can one Agent, Tool, or dependency amplify a failure across the workflow?
ASI09 Human-Agent Trust Exploitation Can people over-trust a confident Agent or approve an unclear side effect?
ASI10 Rogue Agents Can an Agent persist, evade oversight, or act outside its intended lifecycle?

The names and descriptions should be checked against the current OWASP edition. Severity is contextual: a read-only research assistant and an agent that can transfer funds do not share the same impact.

Threat Modeling by Control Boundary

1. Identity and authorization

Authenticate the human or service, then authorize every tool call and object access against the current subject, tenant, purpose, and state. Do not let a model-generated identity, tool name, confirmation string, or Agent Card grant permission. Propagate only the minimum delegated capability and make expiry, revocation, and audit explicit.

2. Tools and side effects

Give tools narrow schemas, bounded resource selectors, timeouts, rate limits, idempotency keys, and explicit side-effect classes. Separate read, propose, and commit operations. Require fresh confirmation or human review for irreversible or high-impact actions. Validate again at the tool server; prompt-level restrictions are not enforcement.

3. Untrusted content and memory

Retrieved documents, web pages, emails, files, tool results, and memories can contain instructions or false state. Keep provenance, source revision, tenant, freshness, and trust status with each item. Use write admission, expiry, supersession, deletion propagation, and replay tests. A sanitizer or delimiter may reduce risk but cannot establish a trust boundary.

4. Code execution and the supply chain

Do not execute model output or third-party workflow code in the application process. If execution is required, use a separate sandbox with a minimal filesystem, network policy, CPU/memory/time limits, non-secret credentials, and an artifact review step. Pin dependencies and tool manifests, verify provenance, scan updates, and retain a rollback version. “Official,” “verified,” or “popular” labels are not proof of safety.

5. Inter-agent communication and failure

Treat every inter-agent message as an API request. Authenticate the sender, authorize the requested capability, bound payloads and recursion, prevent replay, and attach correlation and cancellation state. Use circuit breakers, budgets, deadline propagation, idempotency, and an explicit outcome_unknown state so a timeout does not become an unsafe retry.

A Layered Defensive Architecture

text
human/service identity
  -> task and tenant policy
  -> bounded planner
  -> tool gateway with server-side authorization
  -> isolated execution and data boundary
  -> result validation and human approval
  -> redacted audit event
  -> rollback, deletion, and incident response

Each layer has a different owner. Input classification belongs to the application; object authorization belongs to the resource service; isolation belongs to the runtime; retention and incident response belong to the operating organization. A single “AI firewall” cannot replace these controls.

Turn the Taxonomy Into Runtime Control

A risk register becomes useful only when it reaches the action path. The OWASP Agent Control Standard (ACS) v0.1.0 defines an early wire contract in which an Observed Agent calls a separate Guardian at lifecycle hooks and receives allow, deny, modify, ask, or defer. Its Instrument, Trace, and Inspect profiles can help standardize evidence, but adoption and conformance remain deployment claims rather than proof of safety.

ACS is one possible control plane, not a substitute for application authorization. Its reference implementation explicitly documents an unauthenticated wire and a fail-open default as current gaps. A production design must authenticate the decision channel, bind requests to an immutable Agent and policy identity, choose fail behavior by consequence, enforce decisions before effects, and verify that no alternate path bypasses the hook.

Control layer Trusted decision Evidence to retain
Identity principal, tenant, workload, delegated subject issuer, audience, credential class, expiry, policy revision
Capability allowed Tool revision, resource selector, destination registry digest, schema digest, requested effect
Intervention allow, deny, modify, ask, or defer before execution decision ID, reason code, normalized argument digest
Effect authoritative resource and business invariant idempotency key, transaction or provider result
Recovery revoke, quarantine, compensate, restore, or notify affected run IDs, artifact hashes, final effect status

The following dependency-free Go gate demonstrates the minimum distinction between a model proposal and an authorized effect:

go
package main

import (
	"errors"
	"fmt"
)

type Principal struct {
	Subject string
	Tenant  string
	Roles   map[string]bool
}

type ToolRequest struct {
	Tool, Tenant, Effect string
	Approved             bool
}

func authorize(principal Principal, request ToolRequest) error {
	if principal.Subject == "" || principal.Tenant != request.Tenant {
		return errors.New("identity_or_tenant_denied")
	}
	if request.Tool != "invoice.refund" || request.Effect != "external_write" {
		return errors.New("capability_denied")
	}
	if !principal.Roles["refund_operator"] || !request.Approved {
		return errors.New("role_or_approval_denied")
	}
	return nil
}

func main() {
	principal := Principal{
		Subject: "user-42",
		Tenant:  "tenant-a",
		Roles:   map[string]bool{"refund_operator": true},
	}
	request := ToolRequest{
		Tool:     "invoice.refund",
		Tenant:   "tenant-a",
		Effect:   "external_write",
		Approved: true,
	}
	fmt.Println(authorize(principal, request))
}

// Output: <nil>

The real resource service must also resolve the invoice, verify ownership and refundable state, bind approval to exact arguments and expiry, enforce idempotency, and record the committed outcome. An upstream allow is evidence for one decision, not a bearer capability for future calls.

Defensive Testing Protocol

Use a manifest with:

  • synthetic identities, tenants, documents, secrets, and transactions;
  • allowed actions and forbidden side effects;
  • model, tool, policy, dependency, and prompt revisions;
  • expected authorization, refusal, escalation, and rollback outcomes;
  • redacted telemetry and retention/deletion rules.

Test by risk slice:

  1. Behavior redirection through retrieved content and tool results.
  2. Wrong-tenant, wrong-object, expired, and revoked capabilities.
  3. Unsafe argument combinations, replay, duplicate commit, and timeout.
  4. Memory persistence, stale state, deletion, and cross-tenant leakage.
  5. Inter-agent spoofing, recursion, oversized payloads, and cascading failure.
  6. Code execution attempts, dependency changes, and sandbox escape signals.
  7. Human approval clarity, fatigue, override, and post-approval audit.

Keep these tests inside an owned, isolated environment. Report coverage and residual risk; never claim that a clean run proves absence of vulnerabilities.

Observability Without Over-Collection

Record enough to reconstruct an action without retaining every raw prompt:

text
event_id, request_id, subject_hash, tenant_id_hash
policy_revision, tool_revision, model_revision
action_class, authorization_decision, approval_state
input_provenance, outcome, retry_count, latency

Redact secrets and personal data, restrict access, define retention, and test deletion and legal holds. Logs are evidence for investigation, not a substitute for authorization or an excuse to retain hidden reasoning.

Regulatory Mapping Is a Separate Review

OWASP guidance and the EU AI Act answer different questions. For a legal mapping, record the jurisdiction, provider/deployer role, intended purpose, risk classification, applicable article, date, transition rule, and evidence owner. Do not turn an OWASP label into a legal deadline, or a legal deadline into an OWASP severity rating.

Release Gates

  1. No production Tool without server-side identity, object authorization, scope, timeout, and audit.
  2. No persistent Memory without provenance, write admission, expiry, deletion, and tenant isolation.
  3. No code execution without isolation, resource limits, non-secret credentials, and review.
  4. No inter-Agent delegation without authenticated peers, bounded authority, replay protection, and Artifact policy.
  5. No irreversible action without idempotency, outcome handling, action-bound confirmation, and rollback where possible.
  6. No release without representative abuse, replay, recovery, privacy, dependency-change, and control-bypass tests.

Frequently Asked Questions

Does implementing all ten OWASP categories certify an Agent as secure?

No. The list is a threat-discovery aid. Assurance depends on the exact deployment, identities, Tools, data, models, policies, tests, operations, and residual-risk decision. An organization still needs evidence that controls are enforced on every relevant path.

Can Prompt Injection filtering stop Agent goal hijacking?

No single classifier or sanitizer can establish that boundary. Preserve provenance, minimize capabilities, enforce authorization at protected resources, constrain egress and execution, require action-bound approval where needed, and test indirect and multimodal paths.

Is sandboxing enough for unexpected code execution?

No. A Sandbox reduces blast radius according to its filesystem, process, network, credential, and resource controls. It does not decide whether execution was authorized, prevent supply-chain compromise, or prove that an external side effect is safe.

What does ACS add to the OWASP risk list?

The Agent Control Standard defines a wire contract for lifecycle interventions and evidence between an Observed Agent and a Guardian. It can standardize where a policy decision occurs, but applications still own identity, object authorization, effect verification, failure posture, and bypass testing.

How should an Agent security incident be contained?

Disable the affected capability or artifact, revoke credentials, stop new runs, quarantine related Memory and outputs, identify executions by immutable revision and digest, reconcile external effects, restore clean state, notify owners, and turn the confirmed chain into a regression test.

Conclusion

The OWASP Top 10 for Agentic Applications is most useful as a shared vocabulary for finding gaps. Security comes from enforceable boundaries, bounded authority, trustworthy identity, isolated execution, measured recovery, and accountable operations. Treat the model as an untrusted decision component, keep side effects under service control, and re-run the threat model whenever tools, data, models, tenants, or workflows change.

Primary Sources