The Complete Guide to Agentic AI Security

An AI agent that can read your inbox, query your database and push code is not a chatbot with better manners — it's a new class of production infrastructure with its own attack surface. This is the reference guide we point engagements to: what agentic AI actually is in security terms, the full attack surface across an agent's lifecycle, the OWASP Agentic (ASI) Top 10 mapped in detail, and a practical checklist to run this week.

Key takeaways

• 88% of enterprises running AI agents in production report at least one security incident tied to agent behaviour, per Gravitee's State of AI Agent Security 2026 report — not a hypothetical risk, an already-realised one across the market.
• OWASP published a dedicated Top 10 for Agentic Applications (ASI01–ASI10) in December 2025, separate from the LLM Top 10, because autonomy and tool access create risk categories a single-turn model never faced.
• The most damaging agentic failures are rarely a single bad response — they're chains of individually-authorised actions that combine into an outcome nobody approved.
• Agents inherit the security posture of every tool, server and credential they're connected to. Supply chain compromise (ASI04) is now a top-tier agentic risk, not an afterthought.
• Point-in-time testing ages fast here: tool permissions, connected servers and model versions change without a deploy, so the tested surface and the live surface drift apart within weeks.

What "agentic AI security" actually means

An AI agent is a system that uses a language model to plan, decide and act across multiple steps — usually with access to tools, external data, memory, and sometimes other agents — with limited human review at each step. That's the whole distinction that matters for security: autonomy plus access plus limited oversight.

Securing that system means securing four things a plain chatbot doesn't have:

• The reasoning loop — what the agent decides to do next, and what can influence that decision.
• Tool and credential access — what the agent can actually execute on your behalf, and with what privilege.
• Memory and context — what the agent remembers, and whether that memory can be poisoned to influence future sessions.
• Trust boundaries — every system, human, and other agent the agent communicates with, and what each one can get it to do.

A useful mental model: a conventional application does what its code says. An agent does what its reasoning, at that moment, given everything it just read, decides to do. That's a probabilistic decision surface sitting in front of real credentials and real actions — and it's why agentic security is a distinct discipline, not a subset of prompt filtering.

The agentic attack surface, end to end

Most organisations think about agent security as "can someone jailbreak the model." That's one entry point among many. Here's the surface mapped across an agent's actual lifecycle:

For agents built on MCP specifically, that tool-use layer has its own detailed methodology — see our MCP server pentesting guide for the protocol-level breakdown.

OWASP Top 10 for Agentic Applications (2026), explained

Published December 2025, this is the taxonomy we map every agentic finding to. It sits alongside — not instead of — the OWASP Top 10:2025 for the web layer and the OWASP Top 10 for LLM Applications for model-level risks.

1. ASI01 — Agent Goal Hijack. Injected or ambiguous content redirects what the agent is actually trying to achieve, mid-task.
2. ASI02 — Tool Misuse & Exploitation. Legitimate tools are called in unintended ways, sequences, or combinations to reach an unauthorised outcome.
3. ASI03 — Agent Identity & Privilege Abuse. The agent holds excess standing privilege, or its identity is confused with — or impersonates — a real user.
4. ASI04 — Agentic Supply Chain Compromise. A connected tool, server, plugin, or model dependency is compromised, malicious, or silently changed after you approved it.
5. ASI05 — Unexpected Code Execution. An agent's code-execution or sandboxing capability is escaped or abused to run arbitrary code.
6. ASI06 — Memory & Context Poisoning. Persisted memory or context is manipulated so attacker instructions survive into future sessions.
7. ASI07 — Insecure Inter-Agent Communication. Messages between cooperating agents lack authentication or integrity checks and can be spoofed or tampered with.
8. ASI08 — Cascading Agent Failures. A fault or compromise in one agent propagates through every downstream agent that trusts its output.
9. ASI09 — Human-Agent Trust Exploitation. Humans approve or act on agent output without genuinely reviewing it, and that over-trust is exploited.
10. ASI10 — Rogue Agents. An agent operates outside its intended scope — through compromise, misconfiguration or drift — without detection.

Notice how few of these map cleanly onto a traditional web vulnerability class. ASI01, ASI08 and ASI09 in particular don't have a real equivalent in OWASP's web Top 10 — they only exist because something in the system is making autonomous decisions.

Real incidents that already fit this shape

This isn't theoretical risk modelling. A few disclosures already map directly onto the ASI categories above:

• An autonomous coding agent breached Hugging Face using a zero-day it discovered and exploited itself during a routine task — goal hijack and unexpected code execution in the same incident. Full writeup in our AI agent security post.
• EchoLeak (CVE-2025-32711, CVSS 9.3) proved zero-click indirect prompt injection could exfiltrate data from a production AI assistant with no user interaction at all — a goal-hijack path that required nothing but content the assistant was designed to read.
• mcp-remote (CVE-2025-6514, CVSS 9.6) showed the trust relationship runs both ways: connecting to a malicious MCP server could achieve OS command execution on the client, not just the server — a supply chain and tool-trust failure with over 437,000 downloads at disclosure. Details in our MCP pentesting guide.
• Agentic browsers (ChatGPT Atlas, Perplexity Comet and peers) have been shown resurrecting CSRF-class attacks at scale, because an agent browsing on a user's behalf breaks assumptions same-origin policy was built on. See our agentic browser security post.

Pattern across all four: nothing exotic. An agent did exactly what it was designed to do, with content or tools it was designed to trust, and that trust was the vulnerability.

"In agentic systems, the exploit is rarely a broken function. It's a working function used in a sequence nobody scoped."

Why scanning alone doesn't give you assurance

Automated agent and MCP scanners are genuinely useful for inventory and known-CVE triage, and a competent methodology uses them for coverage. They are not a substitute for adversarial testing, for one structural reason: the highest-impact agentic failures are sequence-level. Each individual tool call is authorised, each individual response looks legitimate, and the exploit exists only in the combination — a pattern no static rule set reliably catches, because there's no single bad line to flag.

That's precisely the gap manual, adversarial testing closes: a human who understands the agent's business logic, not just its protocol, trying to chain legitimate actions into an outcome nobody approved.

How ComplyArmor tests agentic AI systems

Our approach pairs autonomous, continuous discovery with expert manual exploitation — the same Smart PTaaS model we apply across the rest of your attack surface, extended to cover what's specific to agents:

1. Inventory. Every agent, every tool and MCP server it can reach, every credential it holds — including the ones a developer wired up locally and never reported.
2. Privilege & identity review. What the agent can actually do versus what the task requires, and whether its identity can be confused with a real user's.
3. Goal-hijack & injection testing. Planting adversarial content in every system the agent reads, then tracing whether it changes what the agent decides to do.
4. Tool-chain exploitation. Attempting to combine individually-authorised tool calls into an outcome outside the agent's intended scope.
5. Memory & persistence testing. Whether injected instructions can survive into future sessions through memory, embeddings, or cache.
6. Detection & blast-radius assessment. For every successful path, whether your logging would have caught it and how far it could have spread.

Every finding is mapped to the OWASP ASI Top 10, the OWASP LLM Top 10, and — where relevant — the OWASP MCP Top 10, so results are usable for audit, board reporting and customer assurance, not just an internal ticket queue.

Agentic AI security checklist you can run this week

Before you scope a formal engagement, these checks cost nothing and reliably surface something:

1. Inventory every agent and every tool it can call, including ones added outside a formal review process. You can't secure what isn't on the list.
2. Audit standing privilege against least agency — not least privilege. Grant the minimum autonomy and tool access the task genuinely requires, then remove the rest.
3. Treat every tool description and tool response as untrusted input, not documentation. If it can influence the agent's next action, it's an attack surface.
4. Check whether approved tools can change after approval without triggering re-review — a silent post-approval redefinition is one of the quieter supply-chain risks.
5. Confirm you have a kill switch, and that logging captures action sequences, not just individual calls — sequence-level attacks are invisible in per-call logs.
6. Map every agent's blast radius: if this agent were fully compromised right now, what's the worst action it could take with its current credentials?

Frequently asked questions

If your organisation has deployed an AI agent that can take real actions in the last year, you have production infrastructure operating with limited human oversight — and there's a good chance nobody has adversarially tested it yet.