Agentic AI Security: How to Test AI Agents Against the OWASP Agentic Top 10 (2026)

Agentic AI security is the practice of protecting AI agents, systems that plan and take multi-step actions through tools, memory and other agents, from being steered into actions their owners never intended. The OWASP Top 10 for Agentic Applications for 2026, published in December 2025, names the ten highest-impact risks, from Agent Goal Hijack (ASI01) to Rogue Agents (ASI10). Testing an agent means checking what it can do, not just what it says: scope every tool and identity, try to poison its inputs and memory, and prove that high-impact actions stop at a human or policy gate.

What Is Agentic AI Security?

A chatbot answers. An agent acts. Once a large language model can call tools, read and write memory, delegate to other agents and run for many steps without a person reviewing each one, the security question changes from "what could the model say?" to "what could the model do, and with whose permissions?"

Agentic AI security covers that whole system: the model, the planner or orchestration logic, the tools and APIs the agent can call, the identities and tokens it uses, the memory and retrieval stores it reads and writes, the other agents it talks to, and the humans who approve its actions. OWASP's core point is that agents amplify existing weaknesses. A prompt injection that only produces a wrong answer in a chatbot can send an email, move money or delete data when an agent processes it.

OWASP's answer to this wider attack surface is a principle it calls least agency: do not give a system more autonomy than the task needs, because unnecessary autonomy expands the attack surface without adding value. If you already know the OWASP LLM Top 10, think of the agentic list as what happens when those model-level risks gain hands.

This guide walks through each of the ten risks using OWASP's exact names, with a lab-safe way to test it, the controls to verify and the signal that tells you the control works. It then goes deeper on the three areas where most agent assessments find problems: tool and permission scoping, memory poisoning and human-in-the-loop approval.

The OWASP Top 10 for Agentic Applications (2026) at a Glance

The list was published on December 9, 2025 by the OWASP GenAI Security Project's Agentic Security Initiative. It condenses the project's larger Agentic AI Threats and Mitigations taxonomy into ten entries, each with a description, common examples, attack scenarios and mitigations. The names below are as they appear in the entry headings of the document; the summary graphic writes two of them with an ampersand (for example, "Tool Misuse & Exploitation").

The entries cross-reference the 2025 edition of the OWASP LLM Top 10. For example, ASI02 and ASI03 both build on LLM06:2025 Excessive Agency, and ASI01 extends LLM01:2025 Prompt Injection from a single bad response to a hijacked multi-step plan.

How to Test an AI Agent

An agent assessment borrows from application, API and red team testing, but it has to account for two things ordinary tests do not: the system's behavior is probabilistic, and its real attack surface is whatever it is allowed to touch. The six phases below are the model we recommend.

1. Authorize and contain. Agree on written scope, test accounts and a staging tenant. Agents send real emails and call real APIs, so point tools at sandboxes, mock services or test mailboxes, and use canary data (unique marker strings and fake records) so any leak is visible and harmless. Our penetration testing scope guide covers the rules-of-engagement side.
2. Map the agent. Inventory the goal and system prompt, every tool and its real capabilities, the identity each action runs as, every memory and retrieval store, peer agents and protocols, third-party components and every point where a human approves something. Most high-severity findings come from this map, not from clever prompts.
3. Threat model the trust boundaries. For each input channel, ask what an attacker could put there and which tools that content could reach. A lightweight threat modeling pass against the ten ASI entries keeps coverage honest.
4. Test each risk with repeated trials. Run every scenario many times, with variations. In January 2025, NIST's Center for AI Standards and Innovation (CAISI) reported that new red-team attacks raised agent hijacking success in its AgentDojo-based tests from 11% for the strongest baseline attack to 81%, and that repeating attacks raised the average success rate across five injection tasks from 57% to 80%. A single clean run proves little.
5. Chain the findings. Real incidents combine risks: an injected document (ASI01) triggers an over-scoped tool (ASI02) running under a borrowed identity (ASI03). Run at least one end-to-end scenario per critical workflow.
6. Report, fix and retest. Each finding should show the input, the agent's reasoning trace or tool calls, the action that executed, the control that should have stopped it and a pass criterion for the retest. See our penetration testing report guide for the general structure.

Open-source harnesses help with phase 4. AgentDojo provides environments for evaluating attacks and defenses on LLM agents, and Microsoft's PyRIT automates risk identification for generative AI systems. They support manual testing; they do not replace the mapping in phase 2.

Testing Each OWASP Agentic Top 10 Risk

Each entry below gives OWASP's framing, a lab-safe test approach, the controls to verify and the pass signal. The test cases describe what to check, not attack payloads, and they assume a staging environment with canary data.

ASI01: Agent Goal Hijack

What it is. Agents cannot reliably tell instructions from content. Attackers use web pages, documents, emails, calendar invites, tool outputs or peer-agent messages to change what the agent is trying to do. OWASP cites EchoLeak, a zero-click indirect prompt injection in Microsoft 365 Copilot tracked as CVE-2025-32711, which Microsoft scored 9.3 (critical). Our prompt injection guide explains the underlying mechanism.

How to test. Plant instruction-bearing content in every channel the agent reads: a document in the retrieval corpus, an email to a test mailbox, a calendar invite, a page on a test domain and a mock tool response. Each carrier asks for an observable but harmless out-of-scope action, such as sending a canary string to a tester-owned mailbox or calling a tool the task does not need. Vary placement (visible text, metadata, tool output) and repeat each trial. Include a slow variant: a recurring input that nudges priorities over several days, which OWASP describes as goal drift through scheduled prompts.

Controls to verify. All natural-language input treated as untrusted; system prompts and goals locked under change control; a runtime check that pauses execution when the proposed action deviates from the original task; least-privilege tools; human approval for goal-changing actions; logs that record goal state and alert on unusual tool sequences.

Pass signal. No out-of-scope action executes without a gate, and every deviation is logged and alerted.

ASI02: Tool Misuse and Exploitation

What it is. The agent stays within its granted permissions but uses a legitimate tool unsafely: deleting data, calling costly APIs in a loop, chaining an internal CRM lookup with an external email tool, or resolving a look-alike tool name. OWASP even describes an auto-approved ping tool being abused to leak data through DNS queries, a channel we cover in our article on DNS data exfiltration.

How to test. For each tool, compare what the task needs with what the tool exposes. Then try to make the agent use a read tool for writes, combine an internal data tool with an outbound channel, loop an expensive call against a capped budget and pick a similarly named tool. Check egress by asking the agent to reach a tester-controlled canary domain. Confirm that arguments are validated by code outside the model, not by the model itself.

Controls to verify. Per-tool least-privilege profiles (scopes, maximum rate, egress allowlists) expressed as authorization policy; authentication and human confirmation for destructive actions such as delete, transfer and publish; sandboxed execution with deny-by-default egress; a policy enforcement point that validates intent and arguments; usage budgets; just-in-time credentials; fully qualified tool names with version pins; immutable logs of every tool call.

Pass signal. The agent cannot perform any action outside the tool's documented profile, and chained internal-to-external flows are blocked or require approval.

ASI03: Identity and Privilege Abuse

What it is. Agents act through delegated sessions, API keys and OAuth tokens, often without a governed identity of their own. OWASP lists un-scoped privilege inheritance from manager to worker agents, cached credentials reused across sessions, confused-deputy relays between agents, permissions that change mid-workflow (time-of-check to time-of-use) and fake agent personas.

How to test. For every action, record which identity it runs as. From a low-privilege test user, try to make the agent act with its maker's or a service account's rights. Check whether a delegating agent passes its full scope to a worker. Start a long workflow, revoke the test user's permission partway through and see whether the agent finishes anyway. In a test registry, check whether an agent with a misleading descriptor receives privileged tasks.

Controls to verify. Per-agent identities; short-lived, task-scoped tokens; re-authorization of each privileged step by a central policy engine; human approval for privilege escalation; tokens bound to subject, audience, purpose and session; monitoring for permissions gained through delegation chains.

Pass signal. Every action is attributable to a specific agent identity acting for a specific user, and revoked rights stop in-flight work.

ASI04: Agentic Supply Chain Vulnerabilities

What it is. Agents compose models, tools, plug-ins, prompt templates, MCP servers, other agents and registries at runtime, so the supply chain is live rather than fixed in a manifest. OWASP's examples include a poisoned prompt that shipped in version 1.84.0 of the Amazon Q extension for VS Code and a malicious npm package impersonating the postmark-mcp server that secretly copied emails to an attacker. The broader pattern matches classic software supply chain attacks.

How to test. Build an inventory of AI components and check each for pinning by version and hash. Find anything loaded remotely at runtime, such as prompt templates, tool descriptors or agent cards, and check whether it is verified before use. Read tool descriptions for hidden instructions. In a test registry, publish a look-alike tool or server and see whether resolution selects it. Trigger the kill switch for one component and confirm it is disabled everywhere.

Controls to verify. Signed manifests and tool definitions; SBOMs and AIBOMs; curated registries with allowlisting and pinning; sandboxed containers for sensitive agents; prompts and orchestration scripts under version control with review; mutual authentication between agents; runtime re-verification of signatures and hashes; an emergency kill switch.

Pass signal. Unsigned, unpinned or unexpected components are rejected before activation.

ASI05: Unexpected Code Execution (RCE)

What it is. Coding agents and agents with shell, interpreter or deserialization paths can turn text into executed code, leading to host or container compromise. OWASP covers direct shell injection, unsafe eval in memory systems, hallucinated code with backdoors and lockfiles regenerated from unpinned dependencies.

How to test. Inside an isolated sandbox, trace every path from natural-language input to execution: shell tools, code interpreters, eval calls, template engines and package installs. Use a benign marker, such as creating a uniquely named file in the working directory, to prove reachability without harm. Then inspect the sandbox itself: the user it runs as, network access, filesystem scope and whether generated code runs without review.

Controls to verify. No eval in production agents; code generation separated from execution by a validation gate; non-root, network-restricted sandboxes with a dedicated working directory; an allowlist for auto-execution under version control; human approval for elevated runs; static scanning before execution; pinned dependencies.

Pass signal. Untrusted input cannot reach an execution path without validation, and anything that does run is confined to a sandbox with no route to production.

ASI06: Memory & Context Poisoning

What it is. Agents keep conversation summaries, long-term memory, embeddings and RAG stores. Attackers seed that context with false or malicious entries that bias later reasoning and tool use, across sessions and sometimes across users. OWASP separates this from ASI01: goal hijack changes the agent now, while memory poisoning persists. Research such as AgentPoison has shown how poisoned memory or knowledge bases can be used to red-team agents.

How to test. Find every write path into memory: what triggers a write, who can cause it and whether content is validated before commit. In the lab, use a normal user session to plant a false fact, such as a fake refund policy, then check whether a later session, a different user or a peer agent retrieves and acts on it. Seed near-duplicate content in one tenant and check whether retrieval returns another tenant's data. Check whether the agent re-ingests its own outputs as trusted memory, and whether you can roll back to a clean snapshot.

Controls to verify. Validation of memory writes before commit; segmentation by user, tenant and domain; authenticated, curated sources only; provenance on every entry; expiry of unverified memory; no automatic re-ingestion of the agent's own output; snapshots with rollback and quarantine; retrieval weighted by trust and tenancy.

Pass signal. A planted entry does not cross a user or tenant boundary, carries provenance that flags it as unverified and can be removed by rollback.

ASI07: Insecure Inter-Agent Communication

What it is. Multi-agent systems coordinate over APIs, message buses, shared memory and protocols such as MCP and Agent2Agent (A2A). Without authentication, integrity and semantic validation, messages can be intercepted, spoofed, replayed or downgraded to weaker modes.

How to test. Map every agent-to-agent channel and its transport security. On a lab bus, try to inject an unsigned message, replay a captured delegation message after its task window, force a fallback to a legacy or unencrypted mode and register a spoofed peer in discovery. Check whether receivers validate message schemas and audiences.

Controls to verify. Mutual authentication with per-agent credentials; signed messages with payload and context hashes; nonces, session identifiers and timestamps tied to task windows; pinned protocol versions with downgrade rejection; attested registries and signed agent cards; typed, versioned message schemas.

Pass signal. Unsigned, replayed or out-of-window messages are rejected and logged.

ASI08: Cascading Failures

What it is. ASI08 describes how one fault, whether a hallucination, a poisoned memory entry or a tampered tool, spreads across agents and workflows. OWASP names observable symptoms: rapid fan-out, spread across tenants or domains, oscillating retries between agents and queue storms of identical intents.

How to test. In staging, inject a single faulty output, such as a false alert or a wrong risk limit, into one agent and measure the fan-out downstream. Check whether circuit breakers, rate limits and blast-radius caps trip, and whether a human gate sits before propagation. OWASP also suggests replaying recorded agent actions in an isolated clone of production before expanding any policy.

Controls to verify. Isolation and segmentation between agents; planning separated from execution by an independent policy engine; one-time, task-scoped credentials; rate limiting with automatic pause; circuit breakers between planner and executor; tamper-evident logs with lineage for every propagated action.

Pass signal. A single bad input is contained to one agent or one workflow, and the propagation path is traceable in logs.

ASI09: Human-Agent Trust Exploitation

What it is. People trust fluent, confident agents. Attackers, or a hijacked agent, use that trust to get a human to approve the harmful final step, which also hides the agent's role from forensics. OWASP describes fabricated rationales, missing confirmation steps, emotional manipulation and "read-only" previews that trigger side effects when opened.

How to test. Review every approval screen: does it show the exact action, parameters and destination, or only a model-written explanation? In the lab, feed the agent a document with altered payment details and check whether the approver sees where the data came from. Open preview panes and watch for network calls or state changes. Run social-engineering scenarios only as part of an approved exercise with consenting staff.

Controls to verify. Explicit confirmations for sensitive actions; plain-language risk summaries that are not generated by the model; provenance metadata on recommendations; previews that cannot cause side effects; visual risk cues for high-impact actions; a way for users to report suspicious agent behavior; training for approvers.

Pass signal. Approvers see raw, verifiable facts, and a manipulated recommendation is visibly marked as coming from an unverified source.

ASI10: Rogue Agents

What it is. A rogue agent deviates from its intended function or scope and keeps acting harmfully, even after the original trigger is gone. OWASP covers goal drift and scheming, workflow hijacking, collusion, self-replication through provisioning APIs and reward hacking, such as a cost-cutting agent deciding that deleting backups is the cheapest outcome.

How to test. Pull the kill switch and revoke credentials mid-task; confirm the agent stops within an agreed time. Check whether behavioral monitoring alerts when the agent calls a tool outside its declared manifest. Verify that the agent cannot create new agents or service accounts, and that destructive actions are blocked regardless of the objective it is optimizing. Confirm signing keys are never directly available to agents.

Controls to verify. Signed, immutable logs of actions, tool calls and inter-agent messages; trust zones with restricted execution environments; watchdog monitoring for abnormal behavior; kill switches and credential revocation; signed behavioral manifests validated before each action; attestation and human approval before a quarantined agent returns to production.

Pass signal. Any agent can be stopped and cut off from its credentials quickly, and deviation from its manifest raises an alert.

The Agent Test Matrix at a Glance

Use this matrix to plan coverage and to check that a report covers all ten entries. It is our summary of the approach above.

Tool and Permission Scoping

Most agent findings trace back to tools that can do more than the task requires. OWASP's guidance under ASI02 and ASI03 is consistent: define a least-privilege profile for every tool, express it as an authorization policy rather than a prompt instruction, and give each agent its own short-lived, task-scoped identity.

Fill in this worksheet for every tool before testing, then test against it. The example rows show the kind of narrowing to expect.

Three rules make the worksheet useful. First, the gap between "needs" and "exposed" is your finding list before any prompt is written. Second, permissions belong in the API gateway, IAM policy or policy engine, because a system prompt that says "never delete" is a request, not a control. Third, re-check authorization when the action executes, not only when the workflow starts, to close the time-of-check to time-of-use gap OWASP describes under ASI03. Agents that call your own services also inherit every weakness in those APIs, which is why API penetration testing belongs in the same plan.

Securing Agent Memory Against Poisoning

Memory is what makes an attack persistent. A one-off injection ends with the session; a poisoned memory entry fires again tomorrow, for another user, in another agent. Treat memory as a database that untrusted users can write to, because in practice they can.

The controls that matter, drawn from OWASP's ASI06 mitigations:

• Gate the write path. Scan and validate every memory write before commit, and decide explicitly which events may write long-term memory at all.
• Segment by default. Separate memory per user, tenant and domain, with per-tenant namespaces in shared vector stores.
• Record provenance. Store the source, time and trust level of each entry, and require higher trust before high-impact memory can influence an action.
• Expire what is unverified. Decay or expire low-trust entries so a poisoned fact does not live forever.
• Block self-reinforcement. Do not automatically feed the agent's own outputs back into trusted memory.
• Keep a way back. Snapshot memory, version it and support quarantine and rollback when poisoning is suspected.

When you test, the useful question is not "can I write something false?" because the answer is almost always yes. It is "how far does a false entry travel, how long does it last and can the team find and remove it?"

Human-in-the-Loop That Holds Up Under Attack

Human approval is the control OWASP recommends most often, and it is also the one attackers target directly under ASI09. A gate only works if the approver sees the truth and is not asked to approve so often that approval becomes reflex; OWASP's threat taxonomy calls the second problem overwhelming the human in the loop.

We recommend tiering approvals by consequence, not by tool:

Design rules for the approval step:

• Show the exact action, parameters, destination and data, plus where the triggering content came from. Do not rely on the agent's own explanation of why.
• Bind the approval to that exact action, so the agent cannot change a parameter after the human clicks approve.
• Re-check the user's authorization at execution time.
• Make previews side-effect free.
• Measure approval volume and time-to-approve. A rising approval rate with falling review time is a warning sign, not a success metric.

Human review reduces risk; it does not remove it. Pair it with the tool scoping and policy enforcement above so that a single rushed click cannot cause irreversible harm.

Where MCP Fits

The Model Context Protocol (MCP) is a common way to connect agents to tools and data sources, which puts it in the middle of several ASI entries. OWASP notes that tool definitions increasingly arrive through MCP servers, so a poisoned tool descriptor is ASI02 and a malicious or compromised server is ASI04. The MCP project's own security best practices cover confused-deputy attacks on proxy servers, forbid token passthrough, recommend progressive scope minimization and require consent before a client runs a local MCP server command. OWASP also maintains a separate MCP Top 10 for protocol-level risks. In an agent test, treat every MCP server as a third-party component with its own identity, scopes and update channel.

For tool poisoning, server trust and how to test MCP integrations end to end, see our guide to MCP security.

Common Mistakes When Securing AI Agents

• Relying on the system prompt for security. Instructions guide the model; only code and policy outside the model enforce limits.
• Giving agents a human's full session. Use separate agent identities and narrow, short-lived tokens.
• Testing once. Agent behavior is probabilistic, so run repeated trials and treat a low success rate on a high-impact action as a real finding.
• Testing the model, not the system. Most impact comes from tools, identities and memory, not from what the model says.
• Approving everything. Approval fatigue turns a human gate into a rubber stamp.
• No kill switch. If you cannot stop an agent and revoke its credentials quickly, every other finding is more severe.

Frequently Asked Questions

What is agentic AI security?

Agentic AI security is the protection of AI agents and the systems around them: tools, identities, memory, peer agents and human approvers. It focuses on preventing an agent from being manipulated into harmful actions, limiting what it can reach and detecting when it behaves outside its intended scope.

What is the OWASP Top 10 for Agentic Applications?

It is a list of the ten highest-impact risks for AI agents, published by the OWASP GenAI Security Project in December 2025 as the 2026 edition. The entries run from ASI01 Agent Goal Hijack to ASI10 Rogue Agents, and each includes examples, attack scenarios and mitigations.

How is agentic AI security different from LLM security?

LLM security focuses on the model as a component: what it outputs and what data it leaks. Agentic AI security adds what the system does with tools, permissions, memory and other agents over many steps. A prompt injection that produces a bad answer in a chatbot can trigger real actions in an agent.

How do you penetration test an AI agent?

Authorize and contain the test, map every tool, identity, memory store and approval point, threat model the inputs, then test each OWASP agentic risk with repeated trials in a staging environment using canary data. Report each finding with the input, the actions taken, the missing control and a retest criterion.

What is memory poisoning in AI agents?

Memory poisoning, OWASP's ASI06 Memory & Context Poisoning, is the corruption of an agent's stored context, such as summaries, long-term memory or RAG data, so that future sessions are biased or unsafe. It persists across sessions and can spread between users or agents if memory is not segmented.

Is human-in-the-loop approval enough to secure an agent?

No. Approval helps, but attackers target the approver directly and too many requests cause approval fatigue. Combine tiered approvals that show raw actions and provenance with least-privilege tools, policy enforcement outside the model and monitoring.

Next Step: Test Your Agents Before They Act in Production

An agent is only as safe as the most powerful action it can be talked into. Map its tools, identities and memory, test each OWASP agentic risk with repeated trials and make sure every high-impact action stops at a gate that a person or policy controls.

DeepStrike's LLM and AI penetration testing covers prompt injection, sensitive data leakage and AI access controls, with reporting aligned to the OWASP LLM Top 10, MITRE ATLAS and the NIST AI Risk Management Framework. If you are preparing an agent for production, contact DeepStrike to scope an assessment of its tools, identities, memory and approval flows.

Sources and References

• OWASP Top 10 for Agentic Applications for 2026 (OWASP GenAI Security Project)
• OWASP Agentic AI – Threats and Mitigations
• OWASP LLM06:2025 Excessive Agency
• OWASP MCP Top 10
• NVD: CVE-2025-32711
• NIST CAISI: Strengthening AI Agent Hijacking Evaluations
• AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases (arXiv)
• AgentDojo (GitHub)
• PyRIT (GitHub)
• Model Context Protocol: Security Best Practices
• MITRE ATLAS
• NIST AI Risk Management Framework