OWASP Agentic AI Top 10: A Practical Control Map for Running Agents

The OWASP Top 10 for Agentic Applications is useful if you use the actual list.

The old version of this article did not. It promoted generic controls into category names, left out official categories and ranked some risks as mostly academic without evidence. That makes a practical guide harder to trust.

OWASP's 2026 list gives us ten named risks. The job is to connect each one to a control that can be tested.

The official categories

ID	OWASP category	First control to test
ASI01	Agent Goal Hijack	Treat retrieved content as untrusted and require approval when the proposed action departs from the user's goal.
ASI02	Tool Misuse and Exploitation	Restrict each tool by action, resource, rate and network destination. Preview destructive changes.
ASI03	Identity and Privilege Abuse	Use a distinct agent identity with task-scoped, short-lived credentials. Recheck authorization at each privileged step.
ASI04	Agentic Supply Chain Vulnerabilities	Inventory, pin and verify models, prompts, tools, MCP servers, agent cards and update sources.
ASI05	Unexpected Code Execution (RCE)	Keep model output away from an unrestricted shell. Sandbox execution and constrain files, processes and egress.
ASI06	Memory & Context Poisoning	Separate memory by user and task. Restrict writes, preserve provenance and support review and rollback.
ASI07	Insecure Inter-Agent Communication	Authenticate agents and messages. Carry the original user intent and authorization through delegation.
ASI08	Cascading Failures	Set budgets, timeouts and circuit breakers. Make retries idempotent and stop propagation when a dependency fails.
ASI09	Human-Agent Trust Exploitation	Label agent output, show evidence and make approval screens specific about the action and consequence.
ASI10	Rogue Agents	Enforce runtime policy, monitor behavioral drift and provide a tested way to pause or revoke the agent.

Logging matters across the list. It is not one of the ten category names. OWASP repeatedly uses observability as a mitigation because you need to know which goal, identity, tool and approval produced an action.

Start with authority, not with the model

I operate a private multi-agent system. The stable lesson is simple: model quality does not compensate for broad authority.

Map the action path instead:

1. What content can the agent read?
2. Which part of that content can influence its goal or plan?
3. Which tools can it call?
4. Under whose identity does the tool run?
5. Which action is irreversible, privileged, financial or public?
6. Who can stop, review and reconstruct the run?

The dangerous boundary is usually where untrusted content reaches a capable tool under a trusted identity. A malicious web page is data until an agent treats it as an instruction and uses a credential to act.

Goal hijacking and tool misuse need separate controls

ASI01 and ASI02 often occur together, but they describe different failures.

Agent Goal Hijack concerns the objective or decision path. An email, document, API response or peer-agent message can redirect what the agent is trying to achieve.

Tool Misuse and Exploitation concerns how a legitimate tool is used. An agent may have permission to read a database and send email. Chaining those tools can still disclose data even when each individual call is allowed.

Prompt wording alone is not a security boundary. Use policy outside the model to validate the action, resource, destination and rate. Require a human to approve high-impact actions after seeing a dry-run or exact diff.

Identity must survive delegation

A user asks an orchestrator to complete one task. The orchestrator delegates part of it to another agent. If the second agent inherits the user's full credential, the system has lost least privilege and useful attribution.

Use a distinct identity for each agent or execution role. Issue credentials for the task, resource, purpose and duration. When one agent calls another, carry the original intent and recheck authorization before the privileged action.

Do not assume an internal message is trusted because it came from another agent. Authenticate the sender, bind the message to the active task and reject unexpected privilege changes.

Memory and supply chain are write paths

Persistent memory changes future behavior. Prompt templates, tool descriptions and agent cards change how the system interprets capability. Treat all of them as controlled configuration.

For memory:

• separate users, tenants and tasks;
• restrict who and what can write;
• keep the source and time for each entry;
• validate retrieved entries before they influence a plan;
• preserve versions and test deletion or rollback.

For the agentic supply chain:

• keep an inventory of models, prompts, tools, MCP servers and peer agents;
• pin versions or approved identities where possible;
• verify origin before installation or activation;
• review changes to tool schemas and descriptions;
• block runtime discovery from untrusted registries unless the use case requires it and the risk is controlled.

An installed package is one supply-chain path. Runtime-loaded tools and agent metadata add more.

Code execution and cascading failure need containment

If an agent can turn model output into shell commands, SQL, infrastructure changes or application code, assume the output can be hostile or wrong.

Sandbox the execution. Limit the filesystem, process capabilities and network egress. Use typed arguments instead of a free-form command when a narrow tool can do the job. Require approval for destructive operations.

Then plan for failure between agents and tools. Set a maximum number of steps, calls, retries, tokens, time and spend. Make repeated actions safe. Stop the chain when a dependency produces an unexpected result. A fluent explanation is not evidence that the workflow succeeded.

Human review has to be an actual boundary

A confirmation button is weak if it only asks whether the user wants to continue.

A useful approval shows:

• the action and target;
• the identity and credential scope;
• the data that will leave the system;
• the exact diff or transaction where possible;
• the source of the recommendation;
• the rollback path.

This reduces Human-Agent Trust Exploitation and limits damage from several other categories. It also gives the reviewer something concrete to challenge.

A practical first pass

Do not begin by assigning every category a maturity score. Pick the agent with the highest-impact tool and run one action end to end.

Check its identity, scopes, external inputs, memory writes, delegation, execution sandbox, approval and logs. Remove any authority the task does not need. Then test indirect prompt injection through every channel the agent reads.

The OWASP list is a threat taxonomy. It becomes operational only when each risk maps to an owner, an enforceable control and a test that can fail.

Sources

• OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026," December 2025