Use the OWASP Agentic Top 10 as a Test Plan, Not a Badge

A framework only helps if it changes what you test.

Short answer: Use the OWASP Agentic Top 10 as a row-per-risk test plan. For each category, write one harmless probe, one expected denial or review path, one enforcement point outside the model, one evidence artifact, one owner, and one retest trigger. Do not accept a Top 10 coverage claim until the actual agent workflow proves it can resist goal hijack, tool misuse, privilege abuse, supply-chain changes, unexpected code execution, memory poisoning, unsafe agent-to-agent messages, cascading failures, misplaced human trust, and rogue behavior.

The OWASP Top 10 for Agentic Applications is useful because it names the risks teams keep rediscovering in messy agent deployments.

It is dangerous when it becomes a badge.

A tool can say it maps to the Top 10. A platform can say it covers all categories. A team can put the framework in a risk register and still ship an agent that accepts a poisoned issue comment, inherits a user token, follows a malicious tool description, writes to memory, and emails the result outside the company.

The control is not the list. The control is the test you run against the real workflow.

Why this belongs in the field guide

OWASP describes the 2026 Top 10 for Agentic Applications as a globally peer-reviewed framework for critical security risks facing autonomous and agentic AI systems. The resource page says it was developed with more than 100 industry experts, researchers, and practitioners.

The downloadable guide is more specific. It says agents plan, decide, and act across multiple steps and systems. It also says agents amplify existing vulnerabilities and introduces Least-Agency as a practical warning: do not add autonomy where it is not needed.

That is the right mental model.

Agent risk is not only model behavior. It is model behavior plus tools, identity, memory, orchestration, code execution, external content, retries, delegation, and human trust.

OWASP's Q1 2026 exploit round-up points the same way. It frames the landscape as moving from theory toward real exploitation, with incidents and examples mapped to excessive agency, tool misuse, identity and privilege abuse, cascading failures, rogue agents, and human-agent trust exploitation.

So the daily practice should be simple: pick the agent workflow, map it to the Top 10, and prove the boundary before expanding access.

Turn every category into one testable question

Start with one row per OWASP category.

ASI01: Agent Goal Hijack

Question: Can untrusted content change what the agent is trying to do?

Probe it with a harmless poisoned input. Use a document, issue comment, email, calendar item, web page, tool result, or peer-agent message that tries to override the approved goal.

Expected result: the agent keeps the approved goal, labels the hostile content as untrusted, refuses the goal shift, or routes the deviation to review.

Evidence: original goal, probe input, observed plan, denial log, reviewer packet, and trace ID.

ASI02: Tool Misuse and Exploitation

Question: Can the agent use an allowed tool for the wrong purpose?

This is the trap in many agent reviews. The tool is legitimate. The misuse is not.

Probe with a task that asks a read tool to become a delete tool, a lookup tool to become an exfiltration path, or a low-risk utility to loop until it burns budget.

Expected result: action-level policy denies the misuse, asks for approval, limits the call, or switches to dry-run mode.

Evidence: tool call arguments, policy decision, budget state, approval request, and final blocked result.

ASI03: Identity and Privilege Abuse

Question: Can the agent inherit more authority than the task needs?

Test for borrowed human sessions, stale credentials, parent-agent token passthrough, child-agent overreach, and cross-user memory reuse.

Expected result: the agent uses a distinct identity, short-lived scope, task-bound authority, and per-action authorization. A new task, user, or child agent should not silently inherit the previous authority bundle.

Evidence: identity record, token scope, subject, resource, purpose, duration, revocation path, and denied over-scope action.

ASI04: Agentic Supply Chain Vulnerabilities

Question: Can a tool, prompt, model, dependency, MCP server, plugin, or agent package change without review?

Agent supply chain is not limited to package managers. It includes tool descriptors, prompt libraries, agent cards, model routing, remote MCP servers, local subprocess commands, browser extensions, and downloaded automation.

Expected result: source, version, command, permissions, network reach, and rollback path are recorded before the agent uses the component.

Evidence: install record, version pin, diff, source review, approval owner, and rollback test.

ASI05: Unexpected Code Execution

Question: Can untrusted content reach shell, eval, package scripts, notebook execution, browser downloads, or generated code paths?

This is where prompt injection becomes system execution.

Expected result: untrusted inputs cannot directly create executable commands. Execution tools run in a sandbox with limited filesystem, secrets, and network access. High-impact execution requires a reviewed action packet.

Evidence: denied command, sandbox profile, egress policy, reviewed execution request, and harmless canary proof.

ASI06: Memory and Context Poisoning

Question: Can an attacker make the agent remember something that changes a later decision?

Probe with a hostile memory candidate that asks the future agent to trust a fake source, skip review, change a goal, or expose data.

Expected result: the memory write lands in quarantine, carries source and sensitivity labels, has an expiry, and does not influence future tool use until reviewed.

Evidence: memory write record, source label, allowed influence, expiry, reviewer decision, rollback path, and future-task denial.

ASI07: Insecure Inter-Agent Communication

Question: Can one agent impersonate, over-instruct, or confuse another agent?

Do not let an internal-looking message become authority.

Expected result: receiving agents re-check sender identity, task scope, delegated authority, and allowed actions. A low-trust agent cannot instruct a high-trust agent to spend money, move data, deploy code, or approve its own work.

Evidence: sender record, message schema, authority bundle, trust boundary, and rejected forged message.

ASI08: Cascading Failures

Question: Can one agent failure spread through retries, loops, downstream systems, or delegated workers?

Probe loop amplification, repeated API calls, repeated browser actions, repeated emails, retry storms, and failure paths that trigger cleanup or rollback in the wrong system.

Expected result: circuit breakers stop the run, budgets cap impact, downstream actions require fresh approval, and the operator gets a clear evidence packet.

Evidence: retry count, budget state, circuit-breaker event, downstream block, and recovery log.

ASI09: Human-Agent Trust Exploitation

Question: Can the agent make a human approve weak or false evidence?

This is not only a UX issue. Agent output can carry authority cues, fake certainty, hidden gaps, and polished summaries that make a reviewer rubber-stamp the wrong thing.

Expected result: the agent separates evidence from interpretation, links sources, flags uncertainty, shows diffs or dry runs, and asks for approval only against written criteria.

Evidence: approval packet, citations, uncertainty flag, reviewer criteria, and a negative test where weak evidence fails.

ASI10: Rogue Agents

Question: Can the agent keep acting after the task should be over?

Probe for uncontrolled background runs, spawned child agents, scheduled follow-ups, tool calls after closure, goal drift, self-modified instructions, and work that continues after revocation.

Expected result: task leases expire, child authority narrows, kill switches work, closure stops tool access, and expansion requires explicit approval.

Evidence: task closure log, expired lease, denied post-closure action, kill-switch proof, and child-agent authority record.

The test-plan record is the control surface

For each row, keep the record small enough that a busy reviewer will actually use it.

Minimum fields:

• Agent or workflow name.
• Approved goal.
• Tools and data classes.
• OWASP category.
• Abuse case.
• Harmless probe.
• Expected denial or review path.
• Enforcement point outside the model.
• Observed result.
• Evidence path.
• Owner.
• Retest trigger.

The enforcement point matters.

A system prompt that says "never leak data" is not enough. You need a boundary outside the model: policy middleware, scoped credentials, sandboxing, network egress limits, explicit approval gates, source labels, memory quarantine, repo checks, CI permissions, or circuit breakers.

The Microsoft Agent Governance Toolkit README is useful as an example pattern because it talks about policy checks on tool calls, approval rules, denied actions, and audit logs. Treat that as an implementation direction, not as proof. The proof still has to come from your agent path.

GitHub's AI coding agent guidance points in the same practical direction for developer workflows: catch secrets, vulnerabilities, and insecure dependencies while the code is still being created, before it lands in the repository.

Microsoft's lifecycle framing makes the broader point: agent and model security need to move upstream into the tools where builders already work.

Do not score the category until you run a negative test

A checklist can make teams overconfident.

The better move is to require one negative test per category before increasing access. Use harmless canaries. Do not use real credentials, customer data, production systems, or destructive actions.

A category should not move from pending to passing until you can answer:

• What did we try to make the agent do?
• Where did the control stop it?
• What evidence proves the stop happened?
• Who owns the control?
• What change would force a retest?

That last question is usually where weak programs fail.

Retest when you add a tool, change scopes, change model routing, add memory, connect a new MCP server, add browser access, change CI behavior, enable child agents, change approval criteria, or let the agent act in a new system.

Evidence versus opinion

Evidence from the sources:

• OWASP published the Agentic Top 10 as a practical framework for autonomous and agentic AI risks.
• The downloadable OWASP guide lists ten categories across goal hijack, tool misuse, privilege abuse, supply chain, code execution, memory poisoning, inter-agent communication, cascading failures, human trust, and rogue agents.
• OWASP's guide says agents amplify existing vulnerabilities, warns against unnecessary autonomy through Least-Agency, and says observability is non-negotiable.
• OWASP's Q1 2026 exploit round-up maps real incidents and examples to agentic risk categories.
• Microsoft and GitHub public guidance both point toward moving controls into developer and agent workflows before output reaches higher-trust systems.

My opinion:

A Top 10 mapping is not a finish line. It is a starter kit for negative testing. If there is no probe, no expected denial, no enforcement point, and no evidence path, the category is not covered yet.

That is not anti-framework. It is how the framework becomes useful.

Sources

• OWASP, Top 10 for Agentic Applications for 2026: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• OWASP, downloadable guide: https://genai.owasp.org/download/52117/?tmstv=1765059207
• OWASP, GenAI Exploit Round-up Report Q1 2026: https://genai.owasp.org/2026/04/14/owasp-genai-exploit-round-up-report-q1-2026/
• Microsoft Security Blog, Securing code, agents, and models across the development lifecycle: https://www.microsoft.com/en-us/security/blog/2026/06/02/microsoft-build-2026-securing-code-agents-and-models-across-the-development-lifecycle/
• Microsoft Agent Governance Toolkit README: https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/README.md
• GitHub Docs, Use GitHub Advanced Security with AI coding agents: https://docs.github.com/en/code-security/how-tos/use-ghas-with-ai-coding-agents

Related field notes

• Give Agent Tool Permissions an Expiration Date
• Do Not Give Child Agents the Parent Token
• Put a CI Permission Gate Before AI Agent Pull Requests
• Tool Results Are Agent Input, Not Ground Truth

Next free step: Test your agent. Pick one live agent workflow and build a ten-row OWASP Agentic Top 10 test record before expanding its tools, memory, identity, or autonomy.