Agentic AI security is the practice of keeping AI agents, software in which a language model plans steps and acts through tools, from being steered into actions their owners never intended. The root problem is that the model cannot reliably tell your instructions from text it reads along the way, so any email, web page, ticket or tool result an agent processes can become a command, and the agent’s tools decide how much damage that command can do. Securing an agent means limiting what it can reach and do with controls that sit outside the model, then testing those limits the way an attacker would.
When you want an agent tested, our AI and LLM penetration testing covers the agent, its tools and its MCP integrations at a fixed price, and the AI penetration testing cost guide shows the tiers: from $4,500 for a single chatbot or copilot with no tool access, and from $7,500 for an agent with one or two tools, each with a free retest.
What makes agentic AI security different
A chatbot produces text. An agent produces actions: it breaks a goal into steps, calls tools (search, email, a database, a shell, another agent), reads the results and decides what to do next, often with no person reviewing each step. Four things change.
The control plane is natural language. An agent’s next action is chosen by a model reading everything in its context: the system prompt, the user’s request, retrieved documents and every tool result. Any of it can carry instructions. That is indirect prompt injection, and in an agent it becomes agent hijacking.
Every tool is a privilege. An agent that can send email, query customer records or open pull requests holds those permissions on someone’s behalf, so a hijacked agent is an insider. Our guide to how integrations expand the LLM attack surface maps the paths each connection adds.
Agents are identities. Each agent authenticates with a token or service account that usually outlives the task. One agent serving many users with one credential becomes a confused deputy, doing things for a user that the user could not do directly: the agent version of an IDOR vulnerability. Tokens and consent grants are abused the same way in ordinary integrations, as our guide to malicious OAuth apps shows.
Results are probabilistic. In NIST’s agent hijacking evaluations of the upgraded Claude 3.5 Sonnet, the average attack success rate across five injection tasks was 57% on one attempt and 80% with 25 attempts per task. In AgentDojo’s Workspace environment, the strongest baseline attack succeeded 11% of the time and the strongest new attack developed for that model 81%. A test that tries each attack once, with off-the-shelf prompts, understates the risk.
The lethal trifecta and the Agents Rule of Two
Simon Willison’s lethal trifecta explains most agent compromises: an agent with access to private data, exposure to untrusted content and the ability to communicate externally can be made to read your data and send it out. Meta’s Agents Rule of Two makes it a design rule. Until prompt injection can be reliably detected, an agent should hold no more than two of these per session: it processes untrustworthy inputs (A), it can access sensitive systems or private data (B), and it can change state or communicate externally (C). An agent that needs all three needs supervision, such as human approval, rather than autonomy.
| Agent | A: untrusted input | B: sensitive data | C: acts or sends out | What to do |
|---|---|---|---|---|
| Support bot answering from public docs | Yes | No | No | Lower risk. Test for leakage of anything in its context |
| Inbox assistant that reads mail and sends replies | Yes | Yes | Yes | Approval on every send, or split reading and sending into separate sessions |
| Coding agent with a write token on repos that take public issues | Yes | Yes | Yes | One repo per token, approval on every push and pull request, sandboxed execution with no egress |
| Analytics agent querying the data warehouse | Partly (records hold third-party text) | Yes | Only if it renders links or images | Read-only, no URL or image rendering, row-level access per user |
Untrusted input is wider than teams assume (a CRM record or ticket written by an outsider counts), and sending out includes quiet channels: a rendered image URL, a link preview, a public pull request.
Agentic AI threats: the OWASP Top 10 for Agentic Applications
OWASP published the OWASP Top 10 for Agentic Applications in December 2025. It complements the OWASP Top 10 for LLM Applications, where agent risk sat mostly under LLM06:2025 Excessive Agency, and adds a principle worth adopting: least agency, meaning no autonomy the task does not need.
| ID | Risk | What it looks like |
|---|---|---|
| ASI01 | Agent Goal Hijack | Instructions hidden in an email, document, web page or tool result redirect the agent’s objective |
| ASI02 | Tool Misuse and Exploitation | A legitimate tool used unsafely: deleting, sending, spending, or chained with others to move data out |
| ASI03 | Identity and Privilege Abuse | The agent acts with more privilege than its user, or credentials carry across sessions and agents |
| ASI04 | Agentic Supply Chain Vulnerabilities | A malicious or compromised MCP server, plugin, model, prompt template or tool definition |
| ASI05 | Unexpected Code Execution (RCE) | Generated or injected code runs on a host, often a developer laptop or a code interpreter (remote code execution) |
| ASI06 | Memory and Context Poisoning | Planted content persists in memory or a retrieval index and steers later sessions |
| ASI07 | Insecure Inter-Agent Communication | Agents trust each other’s messages without authentication or integrity checks |
| ASI08 | Cascading Failures | One poisoned or wrong step spreads through a multi-agent workflow |
| ASI09 | Human-Agent Trust Exploitation | The agent misleads a person into approving something harmful |
| ASI10 | Rogue Agents | Behavior drifts from the agent’s purpose without an attacker steering it live |
Agent security incidents so far
| Incident | What happened | Control that contains it |
|---|---|---|
| EchoLeak, Microsoft 365 Copilot (CVE-2025-32711, June 2025) | A crafted email, later read by Copilot, could make it disclose data from the user’s context with no click. Microsoft scored it 9.3 | No automatic fetching of links or images built from model output |
| GitHub MCP server (Invariant Labs, May 2025) | A malicious public issue hijacked an agent that could read the user’s private repos; it leaked private data into a public pull request. Claude Desktop confirms each tool call by default; Invariant notes many users switch to “Always Allow” | Token scoped to the repos the task needs, one repo per session, approval kept on for writes |
| ForcedLeak, Salesforce Agentforce (Noma Security, September 2025) | Instructions hidden in a Web-to-Lead form ran when an employee asked the agent about the lead, and data left through an image request to an expired but still allowlisted domain. Rated 9.4 by Noma | Salesforce enforced Trusted URLs on September 8, 2025. Audit allowlists for expired domains |
| Fake Postmark MCP server on npm (Postmark’s notice, September 2025) | A package impersonating Postmark’s MCP server added a backdoor in version 1.0.16 that secretly BCC’d the emails it sent to an outside server | Allowlist MCP servers by verified publisher, pin versions, review updates |
Our October 2026 roundup of Claude Code and MCP vulnerabilities lists newer agent CVEs and fixed versions.
Coding agents also write code that ships. Our guide to the risks of AI-generated code covers what to review before it does.
Securing AI agents: controls that hold
In the first three incidents above, the model was trusted to enforce a boundary, and models cannot do that reliably; in the fourth, a tool the agent trusted was itself malicious. The controls that hold are deterministic and sit outside the model, in the tool layer, the identity system and the network.
- Give every agent its own identity. No shared service accounts; short-lived, narrowly scoped tokens; a record of which person each agent acts for. Inventory every agent, its owner and its credentials, including ones staff build in low-code tools.
- Grant least agency. Fewer and narrower tools: one that emails an approved domain rather than any address, a query tool with fixed parameters rather than raw SQL, no general shell. OWASP’s Excessive Agency guidance says to avoid open-ended extensions.
- Authorize in the tool layer, as the user. Run each action with the requesting user’s permissions and check authorization downstream on every call, which OWASP calls complete mediation. A rule in the system prompt can be talked around; a permission check in the tool cannot.
- Break the trifecta per session. Keep reading untrusted content apart from acting on sensitive data, set an egress allowlist, and do not render images or auto-fetch links that come from model output.
- Put people on high-impact actions, and show them the real action. Approval prompts must display the exact tool, recipient and parameters, not the agent’s description. No “always allow” for anything that writes, sends or spends.
- Treat memory as a data store. Isolate it per user, record where each memory came from, expire it, and keep a way to purge it.
- Sandbox code execution. No network by default, no cloud keys in environment variables, no host file system. Agents that leak their own credentials feed LLMjacking and stolen cloud keys.
- Pin your supply chain. Allowlist MCP servers, plugins and models, pin versions and tool definitions, and re-approve on change. Our guide to MCP server security testing covers tool poisoning in depth.
- Log every tool call and keep a kill switch. Record user, agent identity, tool, parameters, result and the content that preceded the call, and be able to revoke an agent’s credentials fast. Alert on a tool call no user asked for, a first-time outbound domain, a sensitive read followed by an external send, and tool definitions changed since approval.
- Earn autonomy in stages. AWS’s Agentic AI Security Scoping Matrix defines four scopes: no agency (read-only, human-initiated), prescribed agency (a person approves each change), supervised agency (multi-step actions within set bounds) and full agency (self-initiated and continuous). Move an agent up only when testing and monitoring show it stays inside its current bounds.
Guardrail products and prompt injection classifiers are a useful layer, not a boundary. Willison points out in the same trifecta post that these products often claim to catch 95% of attacks, and in web application security 95% is a failing grade. Our page on balancing LLM security and usability covers placing these controls without making the agent useless.
AI agent security testing: a 12-point plan
An agent test asks whether anything an attacker puts in front of the agent can make it act, reach data or send something out that its user did not intend, and how often. This is the plan Invadel runs; it doubles as a checklist.
| # | Area | What the tester tries | What a pass looks like |
|---|---|---|---|
| 1 | Map | Every tool, data source, identity, memory store, peer agent and approval point | An inventory that matches what the agent can actually call |
| 2 | Inbound channels | Indirect injection through mail, tickets, documents, web pages and tool results | No channel triggers a tool call the user did not ask for |
| 3 | Tool authorization | Tool calls through the agent as a low-privilege user and from a second tenant | The tool layer refuses, whatever the agent asks |
| 4 | Exfiltration paths | Links, images, outbound requests, emails, pull requests | Output cannot reach a destination outside an allowlist |
| 5 | Approval gates | Splitting or disguising an action to slip past approval | Approvals fire and show the real parameters |
| 6 | Memory | Content that persists across sessions and users | Planted content stays in its own session and user |
| 7 | Code execution and output handling | What the interpreter or shell can reach, and whether model output lands unescaped in a browser, query or command | No network, no credentials, no host file system; output is encoded for where it lands |
| 8 | Supply chain | Tool definitions, MCP servers and plugins, including changes after approval | Definitions are pinned; changes are blocked or re-approved |
| 9 | Agent to agent | Spoofed messages and delegation between agents | A low-privilege agent cannot task a high-privilege one |
| 10 | Loops and cost | Runaway loops and expensive requests | Rate, spend and step limits stop them |
| 11 | Logging | Reconstructing a test attack from your logs alone | Every tool call is attributable, and the agent can be stopped |
| 12 | Surrounding app | Authentication, sessions and the APIs behind the tools | The standard of a normal web or API penetration test |
How we run it safely
We test in staging with real tool definitions and sandboxed accounts where possible, and in production with read-only or dry-run tool modes, proving an injection would have sent the email without sending it. Attacks are repeated, every bypass is reproduced, and each finding records the channel, the tool reached and the impact, mapped to the OWASP Top 10 for Agentic Applications, the OWASP Top 10 for LLM Applications and MITRE ATLAS.
What an AI agent finding looks like in the report
This example is illustrative, not taken from a client engagement. It shows the fields each finding carries.
| Field | Example |
|---|---|
| Title | Indirect prompt injection through a support ticket triggers an outbound email |
| Channel | Ticket body, read when an employee asks the agent to summarize the ticket |
| Tool reached | send_email, called with an attacker-chosen recipient |
| Impact | Customer records from the agent’s context sent outside the company with no approval prompt |
| Reproduction | Payload, steps, and success rate over repeated attempts (for example 7 of 10) |
| Mapping | ASI01 Agent Goal Hijack; LLM01 Prompt Injection; MITRE ATLAS AML.T0051 LLM Prompt Injection |
| Fix | Restrict the tool to approved domains, require approval that shows the real recipient, keep ticket text out of the session that can send |
What it costs to test an AI agent
Agent tests use the published AI and LLM tiers:
| Your system | Tier | Fixed price from |
|---|---|---|
| One chatbot or copilot, one model, no tool access | Small | $4,500 |
| A retrieval (RAG) application, or an agent with one or two tools | Medium | $7,500 |
| An agentic system with many tools, MCP servers, several agents or models | Large | $12,000+ |
| Model-level red teaming of a model you host or fine-tune | Added scope | Quoted after scoping |
Every tier is fixed in writing and includes executive and technical reports, an attestation letter, the findings platform and a free retest, delivered by senior in-house testers. The retest repeats each attack that worked as many times as the original test did, because a fix that only lowers the success rate is not a fix. We onboard within 24 hours of a signed proposal; one LLM feature takes about a week of testing plus reporting, and multi-agent systems take longer. The cost calculator adds up several tests, and the sample report shows what you receive.
Frequently asked questions
What is agentic AI security? It is the security of AI systems that plan and act through tools, memory and other agents: what a manipulated agent can reach, change or send, and the identities, permissions and approvals around it.
How secure is agentic AI? No model resists every attack. In a public red-teaming competition hosted by Gray Swan and analyzed with NIST’s Center for AI Standards and Innovation and the UK AI Security Institute, more than 250,000 attack attempts from over 400 participants found at least one successful hijack against every one of the 13 frontier models tested (NIST). Security comes from what the agent can do when the model is fooled.
What is the AI agentic security framework? There is no single one. Most teams combine the OWASP Top 10 for Agentic Applications for threats, the OWASP Top 10 for LLM Applications for model risks, MITRE ATLAS for adversary techniques (our glossary of adversarial machine learning terms defines them), the Agents Rule of Two or AWS’s scoping matrix for design, and the NIST AI Risk Management Framework for governance.
What are the four types of agentic AI? There is no standard taxonomy. For security the useful split is autonomy, and AWS’s scoping matrix uses four levels: no agency, prescribed, supervised and full agency, with risk rising at each.
How is agentic AI used in cybersecurity? Security teams use agents to triage alerts, enrich investigations and review code. Those agents read attacker-controlled content by design (phishing emails, logs, suspicious files), so they need the same limits on tools, identity and egress as any other agent.
Can you test an AI agent in production without triggering real actions? Yes. We test in staging with sandboxed accounts where possible, and in production with read-only or dry-run tool modes, which prove an injection would have sent the email without sending it.
How much does it cost to test an AI agent? At Invadel, a single chatbot or copilot with no tool access starts at $4,500, an agent with one or two tools starts at $7,500, and an agentic system with many tools, MCP servers or multiple agents starts at $12,000. Each price is fixed before testing and includes a free retest.
The short version
Agentic AI security is mostly not about the model. Assume anything the agent reads can instruct it, limit what it can reach, change and send with controls the model cannot talk its way past, and test that with repeated attacks through every channel it reads. Our AI and LLM penetration testing does exactly that, from $4,500 for a chatbot without tools and $7,500 for an agent with tools (every tier here), with a free retest. Scope your agent test and get a fixed price in writing the same day.
Written by
Azad Khan, Senior GRC & Compliance
26+ years in the field. Focus: GRC, ISO 27001 & PCI DSS consulting. Part of the team that scopes, tests, and reports for our clients. Full profile →
