Status note (19 July 2026): OWASP published the Top 10 for Agentic Applications for 2026 on 9 December 2025. This article uses the official risk themes as a starting point for defensive engineering. It does not claim that the list is exhaustive, that a control guarantees safety, or that it replaces legal, platform, or application-specific review.

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:

OWASP theme Engineering question
Agent Behavior Hijacking Can untrusted content redirect the agent away from the authorized task?
Tool Misuse and Exploitation Can a valid tool be called with an unsafe target, argument, or sequence?
Identity and Privilege Abuse Is the caller, agent, tool, and object authorization explicit and checked server-side?
Agentic Supply Chain Vulnerabilities Can a model, plugin, tool, dependency, or workflow change without review?
Unexpected Code Execution Can generated or retrieved code reach an interpreter, shell, or dynamic loader?
Memory and Context Poisoning Can untrusted state persist and influence later tasks?
Insecure Inter-Agent Communication Are messages authenticated, authorized, bounded, and replay-resistant?
Cascading Failures Can one agent, tool, or dependency amplify a failure across the workflow?
Human-Agent Trust Exploitation Can people over-trust a confident agent or approve an unclear side effect?
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.

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 irreversible action without idempotency, outcome handling, confirmation, and rollback where possible.
  5. No release without representative abuse, replay, recovery, privacy, and dependency-change tests.

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.

Sources to verify