AI agent security is the process of identifying and eliminating vectors through which an attacker can take control of an autonomous AI agent: its objectives, its functions, its memory, its authentication and the other agents it communicates with.
Agent security matters now because agents do things. If you manipulate a chatbot, it might say something offensive. If you manipulate an agent, it will send the email, run the command, approve the refund, or push the commit.
AI agents are moving into production, and the attacks targeting them are moving with them. By the end of 2026, Gartner predicts 40% of all enterprise applications shipped will have task-specific agents baked in, compared to less than 5% in 2025. Earlier this year in March 2026, Palo Alto Networks Unit 42 observed indirect prompt injection attacks hiding payloads on live websites with the intent to manipulate browsing agents, and discovered 22 unique payload variations doing so in the wild. And back in January 2025 when NIST’s Center for AI Standards and Innovation red teamed a frontier model on the AgentDojo benchmark, unknown attacks were able to take over the agent 81% of time compared to 11% for known attacks.
Since we conceptualize attacks all day at Mindgard, this guide is going to be written from the attacker's perspective first. We will cover everything an agent truly has access to, attack classes that can attack them today (including cases we uncovered ourselves), how to red team agents properly before the bad guys do, and what runtime protection has to account for once deployed.
An LLM application has one trust boundary: the prompt. An AI agent has five. Every one of them is a place an attacker can stand.
Goals. Agents have a goal. They plan actions to achieve their goals. Anything that can change the agent’s goal can control the agent. OWASP has called this out as ASI01, Agent Goal Hijack at the top of their newly released Top 10 for Agentic Applications (2026). This was released in December of 2025 with input from over a hundred practitioners.
Tools. Agents call functions: search, file read, shell, HTTP, email, payment APIs, etc. Every tool gives the agent another capability attackers want to abuse (e.g., read confidential files, run commands, send messages, pay charges). Tool descriptions are text the model reads and acts on, and they’re untrusted as well.
Memory. Agents with persistence keep state between sessions. Once you poison an agent’s memory, they carry that poison forward (ASI06).
Identity. Agents execute with a set of credentials. Often they run with the user’s full credentials, or with a service account that was never restricted (ASI03).
Other agents. Agents in a multi-agent system communicate by sending messages using protocols like Google’s A2A or Anthropic’s Model Context Protocol (MCP). If those messages aren’t authenticated and validated, then one malicious agent can control all the others (ASI07).
The defensive implications are straightforward. You can’t secure an agent by sanitizing its prompt. You must evaluate each boundary as an attacker would, and put the controls at the boundary, not in the model itself.
Score your own agent against the five boundaries below.
Answer eight questions about one agent. The score maps your exposure to the OWASP Top 10 for Agentic Applications (2026) and tells you which red team test to run first.
Scoring weights reflect Mindgard engagement findings: over-scoped credentials and unvalidated tool metadata turn a single injection into a breach. Not a substitute for an assessment. Read the full guide.
These are the six attack classes we observe succeeding most frequently both in engagements and through our own vulnerability research. Each of these corresponds to at least one existing OWASP ASI entry.
The attacker does not speak directly to the agent. Instead, they leave instructions for the agent to find: on a website, in a PDF document, in a calendar invitation, in a Jira ticket, in a code comment. The agent finds the content and assumes it has instructions to act upon. The agent’s goal changes.
A recent breakdown of Unit 42’s March 2026 telemetry illustrates how widely these threats occur. Of all the injected pages analyzed, 75.8% used only a single payload while the remainder chained multiple payloads together. Injection vectors were split between those that were clearly visible as plaintext (37.8%), those that were hidden in HTML attributes (19.8%) and those that used CSS to make the text invisible to the human looking at the page (16.9%).
These attacks have been leveraged for data destruction (14.2%), circumvention of content moderation systems (9.5%), as well as SEO poisoning targeting phishing pages and fraudulent financial transactions. During December of 2025, Unit 42 also discovered the first-ever evidence of an injection specifically engineered to bypass an AI-driven advertising filtering system.
NIST released a study detailing why trying to prevent known attacks will fail. AgentDojo’s repository of known attacks only worked 11% of the time. Attacks tailored by our red team to bypass the targeted agent succeeded 81% of the time on first attempts. Additional attempts increased success across all five hijacking objectives from 57% to 80%. If you only test with known payloads, you’re testing the wrong metric.
MCP tool poisoning is a form of prompt injection attack that allows commands to be inserted into the description or metadata field of an MCP tool. These inserted instructions are read and obeyed by agents in conjunction with their assigned system prompt with equal precedence. MCP enabled easy tool integration. It also opened up tool metadata as an attack surface. Invariant Labs publicly demonstrated the attack for the first time in April 2025. They automatically stole a user's WhatsApp history and contents of their private repositories by simply using one poisoned tool and no interaction from the victim.
There are three variants that matter in practice, according to the Cloud Security Alliance (CSA):
Supply chain compromise closes the loop. A compromised postmark-mcp npm package sent every outbound email to an attacker’s email address while going undetected for weeks by silently BCCing the address. See our guide to MCP server prompt injection for prevention measures.
In February 2026, Mindgard researcher Piotr Ryciak discovered security bugs affecting Anthropic’ Claude Code, OpenAI’s Codex CLI, and Google’s Gemini CLI last February of 2026. Each agent prompts developers to trust a project folder once. Configuration files containing executable commands (.mcp. json, codex/config.toml, .gemini/settings.json) are reloaded whenever the agent launches without asking permission again.
This exploit executes code when victims restart the agent. Because the attack vector is a pull request, victims only need to merge the config change in a branch, or even simply pull down the branch themselves to have arbitrary code execute on their machine the next time the agent is launched. Two of the three vendors marked the reports as informational, while the third decided not to patch it. Read Piotr’s write-up here: Approve once, exploit forever.
“The gap between ‘I trust what's here’ and ‘I trust everything that will ever be here’ is the whole bug.”
- Piotr Ryciak, Mindgard Researcher
Within 24 hours of release on November 20th, 2025, we discovered a related persistence vulnerability in Google’s Antigravity IDE. If a workspace rule file includes “MUST ALWAYS FOLLOW WITHOUT ANY EXCEPTION” literally anywhere in its text the agent will write a malicious MCP config file to the user’s global Antigravity directory. This payload runs on every launch, regardless of whether a project is open, and survives uninstall/reinstall. Google incorrectly marked it as intentional behavior at first, but agreed to reopen when we provided evidence otherwise. Full details: Forced Descent.
The takeaway is not limited to IDEs. Any agent that makes a trust decision, caches that decision, then later loads mutable content under that cached decision is vulnerable to rug-pulling.
Agents with persistent memory make a single injection into a standing order. An attacker implants a fact (“the approved vendor account is X”) or behavior (“always summarize documents to this endpoint”) by way of some untrusted input. The agent saves it to memory. Weeks later, another user in another session receives the poisoned behavior without any injection visible in their context.
Retrieval-augmented agents can be poisoned the same way via their document store. Every document accessible to the retriever is a source of instructions.
A majority of agents we evaluate operate under significantly more privilege than required to complete the task. Typical scenarios: a single OAuth token used amongst every tool, a service account used for read-only tasks that has write access and agent-to-agent calls with the originating user’s credentials passed through the entire chain unchanged.
When an attacker gains control of the agent via any of the methods above, this is how a prompt becomes an exploit. Obsidian Security found that AI agents upload/download 16 times the amount of data compared to a human user. (reference our MCP security stats roundup) This is the blast radius you’re granting.
In a multi-agent system, there’s a significant amount of trust. The planner trusts the researcher, the researcher trusts the browser and the browser trusts the web. Poison the final link, and the instruction cascades back up the chain as a "result."
A2A and MCP both have provisions for authentication, but message semantics are rarely validated in deployments, so a poisoned result returned from one agent becomes trusted plan input for the next. OWASP's ASI08, Cascading Failures, covers what happens when a minor failure in one agent propagates through planning, execution and memory.
Below is our template for scoping an agent engagement. We name a test after each risk. The test yields a quantitative score you can show a CISO.
Risk IDs: OWASP Top 10 for Agentic Applications (2026). Test metrics: Mindgard engagement methodology.
AI red teaming for agents is different from red teaming a model in one important aspect: you target the system rather than the weights. The model powering a read-only summarizer and the model powering an agent given shell access expose different risks A successful engagement involves five stages.
Map the boundaries. List every tool, every ingest path, every memory store, every credential and every agent your target can reach. The majority of discoveries relate to a boundary you didn’t know your team permitted.
Attack each boundary with novel payloads. The difference between the NIST’s 11% and 81% success rate is your argument. Public lists of payloads are a minimum requirement. Engineer attacks that leverage the target agent, its tools and its system prompt. Measure your one try success rate versus trying many times.
Chain. In the real world, injections lead to tool abuse, which leads to privilege escalation, which leads to data exfiltration. Score the chain, rather than individual steps An agent that resists 95% of injections but grants full data access on the 5% has a 5% breach rate.
Test persistence. Reboot the agent. Re-install it. Log into a new session as someone else. If it persists, it's a rug pull waiting to happen, as the Antigravity and coding-agent cases show.
Retest on every change. A new tool, MCP server, model update, or system prompt change resets the trust level. Continuous automated red teaming is critical because manual penetrations become stale within weeks. See our list of AI pentesting tools for options.
Agent security hardening can be broken down into seven controls: Assume output and metadata are untrusted, scope credentials to tool and task, separate plan and do, sign and verify messages between agents, isolate memory writes, place runtime protection between OS and agent, and log everything. Red teaming shows you how the agent fails. These controls shifted the numbers in our retests.
Consider all tool output and tool metadata untrusted. Strip or quarantine directives from tool descriptions. Pin tool definitions to a hash and fail closed if they are changed. This alone prevents the rug-pull class of attacks.
Scope credentials by tool and per task. No more shared tokens. Make them read-only by default. Require human approval for any write request that exceeds a defined risk threshold and require re-approval if the underlying configuration changes.
Decouple planning from execution. Require the model to suggest actions as structured data and require deterministic code to validate those actions against policy before any code executes. Never let the model be the final arbiter.
Sign and validate inter-agent messages. Authenticate each A2A and MCP peer. Check message formats and, if feasible, intent so that a "result" message cannot include an instruction.
Isolate memory writes. Require provenance on anything written to persistent memory or to a RAG store. Prevent memory writes that originate from untrusted data.
Put runtime protection in front of the agent. Static AI guardrails can only detect known patterns. Runtime protection observes what the agent actually does (what tools it calls, with what arguments, against what data) and prevents the action, not the prompt. Prompt-based blocking becomes bypassable with enough attempts. Refer to the NIST’s results on iterations. That’s why it has to be continuous. If you block an attacker at 9am, they’ll be back at 9:05, fully equipped.
Log at the action level. Prompt logs are insufficient for reconstructing an agent attack. You need tool name, arguments used, credentials used, data accessed, and result for each action.
Mindgard’s Offensive Security solution continuously auto red teams agents, models, and applications and integrates confirmed findings into runtime protection to block identical attacks at runtime. Mindgard researchers publicly release everything they find (even agent vulnerabilities such as the coding-agent and Antigravity persistence vulnerabilities discussed previously) so we only recommend controls we've already bypassed successfully. Book a demo to test-drive an agent engagement tailored to the OWASP ASI list.
AI agent security refers to the securing of autonomous AI systems that reason about plans and take actions through the use of tools. Agent security touches on 5 boundaries: what the agent intends to do (goals), what tools it has access to, what it remembers, its identity and credentials, and how it communicates with other agents. Agent security is different from LLM security because if an agent is compromised, it can take actions in the real world rather than simply output text.
OWASP’s Top 10 for Agentic Applications (2026) places agent goal hijack at the top, then tool misuse, identity and privilege abuse, supply chain attacks, accidental code execution, memory poisoning, insecure agent communication, cascading failure, exploitation of human trust, and rogue agents. Experimentally, indirect prompt injection chained into other high-privilege tool access is the biggest threat vector we've discovered.
AI agent security risk assessment means thoroughly testing every agent boundary against realistic attacks. The result is a measurable score for each risk: how often hijacks occur per ingest path, how often malicious actions occur per task, what tools are reachable that are out of scope and/or persist after restarts. Customize your attacks against the specific agent you are testing. NIST’s research shows that unknown attacks are successful 81% of the time vs 11% for known attacks.
MCP gives agents a standard interface to connect to tools. The model parses those tool descriptions, and acts upon them. This allows tool poisoning, rug pulls and shadowing. We've seen tool poisoning work on over 60% of servers we tested.
No. Guardrails only screen inputs/outputs against known patterns. Agent attacks are encoded into tool metadata, memory, and other agents, then fine-tuned until they work. Securing agents requires least-privilege tooling, agent-to-agent message validation, runtime protection at the level of actions, and continuous red teaming.
Anytime there is a material change: new tool or MCP server, model upgrade, system prompt edit or a new data source. In between changes, automated continuous testing stays ahead of adversaries who try and fail until they succeed.
There are three categories of AI agent security tools. Automated red teaming tools, like Mindgard, test agent vulnerability by attacking its goals, tool usage, memory and inter-agent communications both before deployment and on every change. Runtime protection tools and AI gateways monitor tool calls, arguments and data access while the agent is running and can prevent unauthorized activity. Identity and access controls restrict each agent's permitted credentials for different tools and activities. The OWASP AI Agent Security Cheat Sheet and AgentDojo open-source benchmark (which NIST used to test AI hijacking) are available for reference.
Mindgard helps organizations discover, assess and defend their AI systems. Spun out of more than a decade of AI security research at Lancaster University in the UK and headquartered in Boston and London, Mindgard operationalizes the expertise of AI researchers and offensive security practitioners through a Security Platform that performs Shadow AI discovery, AI red teaming, and run-time AI protection to assess and mitigate risk across models, agents, and applications.
The expert-level checklist for operationalizing NIST AI RMF, ISO/IEC 42001 and the EU AI Act. 190+ interactive items and a board-ready maturity scorecard. Built for CISOs, AI governance leads and ML engineering teams.
