Using OWASP's Agentic Top 10 to Govern Systems That Act

An LLM application produces output. An agent can turn output into action.

That difference is why the OWASP Top 10 for Agentic Applications 2026 belongs beside the OWASP LLM Top 10 in an AISecOps program.

The agentic list focuses on systems that plan, use tools, maintain context, communicate with other agents, and make decisions across several steps. Those capabilities introduce failure modes that do not fit neatly inside a prompt-and-response security review.

The ten agentic risks

OWASP’s 2026 list contains:

1. ASI01: Agent Goal Hijack. An attacker or poisoned input redirects the objective, plan, or intermediate goals.
2. ASI02: Tool Misuse and Exploitation. The agent uses a legitimate tool in a harmful way or combines tools into an unsafe sequence.
3. ASI03: Identity and Privilege Abuse. Excessive, inherited, cached, or delegated access lets the agent act beyond the intended authority.
4. ASI04: Agentic Supply Chain Vulnerabilities. Compromised tools, MCP servers, agent definitions, models, frameworks, or other runtime components alter behavior.
5. ASI05: Unexpected Code Execution. Natural-language paths lead to unsafe generated or interpreted code execution.
6. ASI06: Memory and Context Poisoning. Malicious or incorrect context persists and influences later decisions.
7. ASI07: Insecure Inter-Agent Communication. Agents accept spoofed, altered, over-privileged, or unverified messages and delegations.
8. ASI08: Cascading Failures. One incorrect result or compromised component spreads through connected workflows.
9. ASI09: Human-Agent Trust Exploitation. A convincing agent persuades a person to approve, disclose, or perform something unsafe.
10. ASI10: Rogue Agents. An agent operates outside intended constraints because of compromise, misalignment, failure, or unexpected behavior.

Several risks overlap with ordinary application security. The agentic difference is persistence and reach. One hostile input can affect a plan, call several tools, alter memory, influence another agent, and produce a delayed action after the original interaction has ended.

Risk-tier the capability, not the model

An agent inventory should describe what the system can do, not only which model it uses.

I would record:

• the agent’s approved purpose and prohibited goals;
• whether it can plan or create subgoals;
• every tool operation, including destructive and external actions;
• service identities, delegated authority, and credential lifetime;
• memory sources, retention, provenance, and rollback;
• peer agents and inter-agent protocols;
• code execution paths and sandbox boundaries;
• maximum transaction, data, time, recursion, and spending limits;
• approval and emergency-stop behavior;
• whether actions are reversible.

This produces a much better risk tier than a label such as “uses a frontier model.” A small model with production write access may deserve tighter controls than a larger model confined to a read-only sandbox.

Translate each risk into architecture

The Agentic Top 10 is most useful when it changes the system design.

Risk area	Architectural response
Goal hijack	Bind the run to an approved goal, separate instructions from untrusted content, and check high-impact actions against the original intent
Tool misuse	Allowlist operations, validate parameters, separate read and write, and enforce policy outside the model
Identity abuse	Give each agent its own identity, attenuate delegated permissions, use short-lived credentials, and deny by default
Supply chain	Approve, version, sign, and monitor models, tools, MCP servers, agent cards, prompts, and frameworks
Code execution	Isolate execution, restrict files and network access, inspect generated code, and require approval for risky commands
Memory poisoning	Preserve provenance, isolate tenants and sessions, validate retrieval, set retention, quarantine suspect memory, and support rollback
Inter-agent communication	Authenticate peers, authorize every delegation, bind messages to a task, validate schemas, and record the chain
Cascading failures	Add circuit breakers, bounded retries, idempotency, rate and cost limits, dependency health checks, and graceful degradation
Human trust exploitation	Make uncertainty and intended actions visible, require independent confirmation, and prevent polished language from bypassing policy
Rogue agents	Monitor behavior, constrain runtime, revoke access quickly, keep a reliable stop path, and restore a known-good state

The common principle is that policy cannot live only in the prompt. Prompts guide behavior. Services, identities, sandboxes, schemas, and approval systems enforce boundaries.

How it fits the eight AISecOps domains

The agentic list gives every domain concrete work.

Governance and inventory

Define what counts as an agent, register it, assign an owner, document its autonomy, and risk-tier it by capability and consequence. Treat material changes to tools, memory, identity, peers, or goals as review events.

Secure development and deployment

Publish secure patterns for goal binding, tool calling, code execution, memory, delegation, circuit breakers, and human approval. Put tests in delivery paths so a control cannot be removed silently.

Identity and access

Manage the complete non-human identity lifecycle. Avoid shared credentials. Scope tokens to the agent and task. Reduce privilege during delegation instead of forwarding the original authority.

Data protection

Apply classification and egress controls to prompts, retrieval, memory, tool parameters, and outputs. Context stores deserve the same access control and retention discipline as other sensitive data stores.

Threat detection and monitoring

Trace goal changes, tool sequences, privilege elevation, peer messages, memory writes, code execution, approval events, repeated failures, and stop requests. Baseline behavior by agent role rather than across the entire fleet.

MCP and tool governance

Maintain an approved catalog, pin versions, verify provenance, review requested scopes, detect definition changes, and enforce authentication at the server. A tool description is untrusted metadata, not a security policy.

Incident response and adversarial testing

Build playbooks for hijacked goals, stolen agent credentials, poisoned memory, malicious tools, uncontrolled execution, and cascading failures. Test whether the agent really stops, credentials really revoke, and state really rolls back.

Vulnerability and supply chain management

Track the complete agent bill of materials: model, framework, SDK, tool, MCP server, prompt package, memory component, retrieval pipeline, and serving infrastructure. Monitor dynamic components after approval, not only at onboarding.

Create tests from the list

Each applicable ASI entry should produce at least one repeatable scenario.

Can outside content insert a new goal? Can a read tool be chained with a send tool to leak data? Does a subagent inherit more permission than it needs? What happens when a tool definition changes after approval? Can a poisoned memory survive into a new session? Will malformed peer output cascade into downstream actions? Does the emergency stop work while the agent is executing?

The test needs an observable result. A blocked action, a revoked token, a broken circuit, a quarantined memory, or a required approval is stronger evidence than the agent explaining that it understood the rule.

Use both OWASP lists

The OWASP LLM Top 10 still applies. Agents remain LLM applications, so prompt injection, sensitive disclosure, improper output handling, poisoned data, retrieval weaknesses, and resource consumption do not disappear.

The agentic list adds the security consequences of autonomy. It helps the program answer a harder question: what happens after the model is wrong?

NIST AI RMF provides the governance cycle around those decisions. MITRE ATLAS turns the risks into adversary paths that can drive detection, threat modeling, and red-team work.

The OWASP Agentic Top 10 is the framework that keeps an AI security program focused on the whole system. The model may choose the next action, but the architecture still decides what actions are possible.