OWASP’s agentic Top 10 as a vendor questionnaire: what to ask, and what an evasive answer sounds like

Most vendor security questionnaires still describe a chatbot. They ask about training data, prompt retention, and whether the model can output something offensive. They do not ask what happens when the model merges a pull request, refunds a customer, or emails a contact list. On December 9, 2025, the Agentic Security Initiative of the OWASP Gen AI Security Project published the OWASP Top 10 for Agentic Applications, built with more than 100 contributors, and it names ten ways a system that acts on your behalf fails.

This post converts ASI01 through ASI10 into questions you can send to a vendor, and it tells you what a specific answer sounds like next to a deflection. OWASP’s launch note explains the shift: the project had already written about excessive agency, and its authors decided agentic applications needed deeper and more specific coverage. For the controls you own rather than the ones you buy, pair this with our agent-security checklist.

Order the ten risks by what the agent can actually do

OWASP ranks Agent Goal Hijack first, and that ranking reflects the ecosystem rather than your deployment. The risk that should lead your questionnaire depends on the tools you hand the agent, so decide the order before you send anything.

1. List every tool the agent can call in your production configuration, including the read-only ones, before you open the OWASP list.
2. Pick your first risk from that inventory instead of from OWASP’s ranking. An agent with a shell or a code interpreter starts at ASI05. A system that hands work between agents starts at ASI07. An agent that only retrieves documents and replies in text starts at ASI01.
3. Ask the identity questions next, because ASI03 sets the blast radius for every other failure on the list.
4. Save ASI08 and ASI10 for last, and treat them as questions about detection and shutdown rather than about prevention.

Ask what the agent reads, because that is where the attacker writes

Two of the ten risks come down to one mechanism: text the agent ingests becomes text the agent obeys. A vendor who cannot draw the line between data and instructions has not solved either risk.

• ASI01 Agent Goal Hijack: ask which channels can change the agent’s objective, and whether retrieved web pages, tickets, and documents enter as data or as instructions. OWASP points to EchoLeak as its example, and agentic browsers that weaken same-origin assumptions show how ordinary page content reaches the planner. OWASP’s stated defense is treating retrieved content as untrusted and constraining the objective the agent is allowed to hold.
• ASI06 Memory and Context Poisoning: ask what the agent writes to long-term memory, who validates those writes, and how the vendor expires or rolls back a poisoned entry. OWASP cites a Gemini memory attack here, and the property that matters for procurement is delayed detonation: the injection lands in one session and the payoff arrives sessions or weeks later, long after anyone would connect the two. OWASP’s stated defense is validated memory writes and ephemeral context.

Push hardest on the memory question. Vendors handle the goal-hijack question well because they have rehearsed it. Ask instead how they would discover today that an agent wrote a malicious instruction into a customer’s memory store three weeks ago. Expect few clean answers, and treat the admission of a gap plus a plan to limit the damage as a better result than a confident denial.

Ask who the agent is, not just what it can do

Identity is the control that decides how far a compromise travels. When an agent runs under a shared service account, every other answer on the questionnaire matters less.

• ASI03 Identity and Privilege Abuse: ask whether each agent holds its own identity, how long its credentials live, and whether the downstream system re-checks the calling user’s tenant on every request. Asana’s connector shows what a missing re-check costs. BleepingComputer reported in June 2025 that a logic flaw in Asana’s MCP server exposed task details, project metadata, comments, and files across organization boundaries, and an Asana spokesperson put the number of affected customers at roughly 1,000. No attacker was involved, which is the point: the authorization path itself was wrong. OWASP’s stated defense is per-agent identity backed by short-lived scoped credentials.
• ASI04 Agentic Supply Chain Vulnerabilities: ask which connectors, tool definitions, and model versions the vendor pins, who signs them, and whether they publish an AI bill of materials. OWASP cites a GitHub MCP exploit, and our write-up on MCP tool poisoning and supply-chain risk maps directly onto this category. OWASP’s stated defense is signed components with provenance you can verify.

Continuity belongs in the ASI04 conversation too. Ask what the vendor does when a model provider retires the version their agent depends on, because a rushed swap changes behavior no one re-tested. The 2026 OpenAI deprecation wave is the version of that problem buyers are living through now, and the 2026 MCP protocol update is the version that hits connectors.

Ask what happens when a legitimate tool gets used against you

ASI02 and ASI05 rarely involve a hacked tool. They involve a working tool called with attacker-chosen parameters, or a natural-language path that reaches a shell nobody meant to expose.

• ASI02 Tool Misuse and Exploitation: ask who validates tool parameters, whether the agent’s tool scope narrows per workflow, and what triggers re-approval when a connector or tool definition changes after you approved it. Check Point Research’s MCPoison finding shows why the last part matters: CVE-2025-54136 let an attacker with write access to a shared repository swap the command behind an already-approved MCP entry in Cursor, because Cursor bound the trust decision to the entry’s name rather than to its contents. Cursor now requires approval on every modification and shipped the fix in version 1.3.
• ASI05 Unexpected Code Execution: ask where generated code runs, what that sandbox can reach on the network, and whether egress denies by default. OWASP cites an AutoGPT remote code execution case, and our reporting on safety tests that escaped their sandbox covers how isolation fails in practice. OWASP’s stated defense is sandboxed execution paired with deny-by-default egress.

The MCPoison pattern generalizes into a question worth asking every coding-agent vendor, including the ones behind GitHub Copilot and Cursor: does an approval expire when the thing you approved changes? A vendor who cannot answer that has a trust model bound to labels rather than to content.

Ask how a bad decision stops at one agent

Multi-agent systems fail differently from single agents. A forged message or a confidently wrong output propagates, and the downstream damage can outrun the original error.

• ASI07 Insecure Inter-Agent Communication: ask whether agents authenticate each other mutually, whether messages carry signatures, and what a receiving agent does with a message it cannot verify. OWASP’s stated defense is mutual authentication and signed messages, so a vendor who describes agents on a shared internal bus with no per-agent identity has answered ASI03 badly as well.
• ASI08 Cascading Failures: ask where the circuit breakers sit, what rate limits apply to agent-initiated writes, and which downstream systems keep running when the agent layer misbehaves. OWASP’s stated defense is blast-radius isolation, and the buyer-side test is whether the vendor can name the specific boundary that a failure will not cross.

Ask how the vendor protects the human who approves the action

The last two risks target people and detection rather than code. Security questionnaires rarely cover ASI09, and it is the risk that turns an approval step into a rubber stamp.

• ASI09 Human-Agent Trust Exploitation: ask which actions force an explicit confirmation, and what the confirmation screen shows the reviewer. OWASP describes the mechanism plainly: confident, polished explanations mislead human operators into approving harmful actions. A confirmation dialog that repeats the agent’s own reasoning is the vulnerability, not the control, so ask whether the reviewer sees the raw tool call and its parameters. Intuit’s human-in-the-loop pattern shows what deliberate approval design looks like in a shipped product.
• ASI10 Rogue Agents: ask what behavioral baseline the vendor monitors, what triggers an automatic stop, and whether the kill switch works without the agent’s cooperation. OWASP cites the Replit incident here. The answer you want names a control plane outside the agent, because a kill switch the agent can decline is a feature request.

What a specific answer sounds like next to a deflection

Restating the OWASP list gets you ten questions. Scoring the replies is the part that decides a purchase. Take one question, put it to the vendor verbatim, and listen for whether they describe a mechanism or a posture: “If your agent reads a support ticket that contains instructions, what stops it from following them?”

A specific answer names something you can check

• Names the boundary. The vendor explains that retrieved text enters the model in a separate channel from instructions, and can point to where the code enforces that split.
• Names the limit. The vendor enumerates the tools this workflow exposes, for example three read tools and one write tool, and confirms the write tool requires an approval the agent cannot grant itself.
• Names a failure. The vendor describes a case where the control did not hold, what they changed afterward, and roughly when.
• Names the evidence. The vendor cites red-team results with a date and an owner, and will share the methodology rather than only a summary score.
• Names the limits of the claim. The vendor volunteers which attacks the control does not stop, and that candor tells you more than a clean answer does.

An evasive answer redirects to something easier

• Points at the model provider instead of their own controls, as in “we build on a frontier model, so the model handles that.”
• Offers a certification in place of a mechanism. SOC 2 attests to process discipline and says nothing about whether retrieved text can redirect an agent.
• Describes intent rather than enforcement, as in “the agent is designed not to take that action.”
• Answers a neighboring question, as in “all data is encrypted in transit and at rest,” which is true and unrelated.
• Moves the control to the roadmap, as in “per-agent identity ships next quarter,” without saying what protects you until then.
• Claims no known incidents while also lacking exportable tool-call logs, which means the absence of incidents is an absence of visibility.

Treat the last item as disqualifying for any agent with write access. A vendor cannot claim a clean record and simultaneously admit they cannot show you what their agent did. If you want to test the vendor’s evidence rather than accept it, our agent evaluation framework covers how to run the checks yourself.

Run the review in this order

1. Send the ten questions in writing and require written answers, so you can compare vendors on the same wording later.
2. Score each answer as mechanism, policy, or roadmap, and treat anything that is not a mechanism as an open risk you now own.
3. Ask for one artifact per high-severity answer: a tool allowlist, an approval screenshot, a sample audit-log export, or a red-team report.
4. Re-run the ASI04 questions at renewal, because connectors, tool definitions, and model versions change between contracts even when the product name does not.
5. Write the unanswered questions into the contract as reporting obligations rather than dropping them at signature.

The ten categories will not change often. Your agent’s capabilities will change every release, which is why the inventory in step one drives everything else. When you are comparing platforms rather than auditing one, open the ChatGPT, Claude, and Gemini profiles side by side, save the shortlist, and attach these ten questions to it before the first vendor call.