AI Agent Security Fundamentals

An AI agent doesn't just answer questions. It plans, calls tools, writes to databases, sends emails, and coordinates with other agents across sessions. That single fact changes what a security failure means: instead of a chatbot saying something wrong, a compromised agent can take real action inside real systems. A static, compromised LLM is bounded by what it generates in text. A compromised agent can read confidential files, modify database records, send emails, execute code, and invoke other agents on a victim's behalf. This piece looks at why you need a different security model for that shift in capability, and at where today's model, built mostly around the Model Context Protocol, still falls short.

Why AI agents create a different security problem

The clearest illustration of this gap is a real attack: CVE-2025-32711, known as EchoLeak, hit Microsoft 365 Copilot with nothing more than a crafted email. No link was clicked and no attachment was opened. The agent simply read the email as part of its normal work, and prompt injection embedded in that email quietly pulled out the victim's emails, chat logs, files, and other documents. The user took no action at all, which is exactly the point: the agent's normal, authorized behavior was the delivery mechanism.

Wiz Research describes the condition that makes attacks like this possible as the "lethal trifecta": untrusted input, access to sensitive data, and the ability to act, all present in the same execution path. Traditional application security treats these as separate concerns, so separate teams handle them with separate tools.

Three properties follow from this that have no real equivalent in stateless LLM systems. Harm can emerge from a chain of individually authorized actions rather than from any single bad action. A defense placed at one point in the system can miss an attack that's routed through a different component entirely. And an attack doesn't have to be immediate: a payload can sit dormant for weeks before the conditions are right for it to execute.

Research out of TU Berlin and the Max Planck Institute in 2026 draws an explicit comparison: AI agents face the same core challenges that operating systems have always faced, namely isolating resources, separating privileges, and mediating communication between processes that shouldn't fully trust each other. Decades of work on sandboxing, access control, and process isolation gave operating systems their answer to those challenges. Agent systems are, by comparison, early. The rest of this piece works through why, starting with the protocol that now underlies most of this activity.

MCP as the primary attack surface for enterprise agents

Anthropic released the Model Context Protocol in November 2024, and by early 2026 it had become the default way to connect LLM-based agents to outside tools, with Claude, GitHub Copilot, and Cursor all building it in natively. Before MCP existed, hooking an agent up to a CRM or a ticketing system meant building a custom integration by hand. That friction was annoying, but it forced engineers to actually think about authentication, permissions, and scope before anything shipped. MCP removes that friction. A developer can point an MCP server at a production database and have it running by the end of an afternoon. The speed is the feature. It's also the risk.

Tool selection and invocation run entirely through free-form, natural-language descriptions that the LLM reads and interprets at the moment it decides what to do. The agent gives a tool's description the same weight it gives its own system prompt. There's no separate channel for instructions versus data. It's all just text in the same context window.

MCP's architecture has three tiers: a Host that embeds a Client, a Client that talks to MCP Servers over JSON-RPC 2.0, and Servers that expose Tools, Resources, and Prompts. This structure solved a real problem, the fragmentation of dozens of bespoke integrations, but it introduced new weak points at each boundary between those tiers.

The scale involved isn't theoretical. MCP adoption figures show tens of millions of monthly SDK downloads, thousands of active public servers, and first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. If you scan public MCP servers, somewhere between a third and more than four-fifths carry exploitable flaws, and only a small share use OAuth. Server adoption has outrun the security controls meant to govern it.

Tool poisoning: how a trusted tool becomes an attack vector

Researchers at Invariant Labs built a working proof of concept against Cursor IDE, showing how far this can go. They set up what looked like an ordinary MCP server. Its tool description, however, contained a hidden instruction: read the user's private SSH key at ~/.ssh/id_rsa and send it back to the malicious server as a raw parameter in a tool call. The entire chain executed without the user ever knowing it happened.

That attack works because of a basic limitation in how these systems process language. When an MCP server registers a tool, its name and description go straight into the LLM's context. It does, so it treats embedded instructions as directives to follow rather than text to merely consider. The model has no built-in way to tell a description that informs apart from one that commands, because both arrive with equal weight in the same context window.

Microsoft Defender researchers describe a more mundane version: a finance team connects its agent to a third-party invoice enrichment tool. The tool gets approved, but nobody gives it a real security review. Later, the attacker updates the tool's description to instruct the agent to collect unpaid invoices and attach them to the next outbound call. Because MCP tool descriptions can change after approval with no re-review requirement, the update goes live and triggers no alert.

The scale of the problem is visible in benchmark numbers. The MCPTox benchmark ran adversarial versions of 353 real tools pulled from 45 live MCP servers against 20 different language models. Even the model with the strongest refusal behavior still complied with poisoned instructions more than a third of the time. Separate research presented at AAAI 2026 found that if a malicious MCP server crafts its tool-response payloads carefully, it can push model outputs toward policy-violating completions with a mean attack success rate of roughly three in four.

A rug pull is when a server behaves normally until after approval, then changes its behavior. Cross-server tool shadowing is when one server's tool claims the same name as another's and overrides it in context. Neither has a native defense built into the MCP specification.

Prompt injection through external content

Tool descriptions are one channel for injected instructions. Once an agent reads external content as part of its normal job, which is most of what agents do, every email, document, web page, and database record it touches becomes a potential vector too.

EchoLeak remains the clearest production case of this happening in the real world. The injected instruction arrived inside an ordinary email, got pulled into context during routine information-gathering, and ran silently, so no user had to do anything at any point.

An adversarially crafted document picked up during a routine web search can quietly corrupt an agent's long-term memory. Weeks later, in a session that has nothing to do with the original search, that corrupted memory changes the agent's behavior, with no visible anomaly at the moment of infection or at the moment it's exploited. The survey classifies this as a T3, or cross-session cumulative, threat, and its coverage analysis flags this class as a real gap in existing benchmarks and defenses.

You can sanitize input and filter output, but both need a fixed line between trusted and untrusted input that you already know. Agentic systems don't have that line, because the agent is actively going out and fetching content from its environment as a normal part of doing its job. There's no single gate to sanitize at.

The ceiling on what this can cause keeps rising, too. In January 2026, three CVEs were found in Anthropic's Git MCP server that allowed remote code execution through prompt injection, since patched. That incident shows how prompt injection in an MCP context can escalate past data theft into actual code execution on the host system. Indirect injection, meaning content the agent retrieves on its own rather than something an attacker sends it directly, is categorically harder to catch than direct injection, because it arrives through a channel the agent is built to trust by default.

Given that, the controls that matter most are at the point of execution, checking what an agent is about to do before it does it, rather than only at the point where content first enters the system.

Over-scoped permissions and inherited access

Most breaches in deployed agent systems don't come from a clever attack. They come from agents that were handed far more access than any single task required, because nobody treated scoping credentials down as part of the build.

A tool built to read one database table can quietly end up with write access to the entire database, simply because nobody went back and narrowed its credentials after the initial build shipped. Any agent that invokes that tool inherits whatever access the tool happens to have, whether it needs it or not.

Creators typically issue OAuth tokens for agents once, at the moment they authorize the integration, and they size them to the maximum access they might conceivably need rather than the minimum the agent's actual workflow uses. Nothing trims that access back later, even once you know the agent's real behavior well.

This pattern predates agents. Roughly half of enterprise non-human identity credentials are long-lived API keys, and you can trace a meaningful share of non-human identity security incidents back to over-privileged identities. Agents don't invent this problem, but they make it worse structurally, because the attack surface is now automated and runs at scale.

The problem compounds in multi-agent systems. When Agent A invokes Agent B, the permission model has to account for both agents. If trust passes transitively, so Agent B simply inherits Agent A's permissions without any explicit authorization step, then a narrow compromise in one corner of the system can spread across an entire orchestration network.

This isn't just a runtime risk, either. In February 2026, a typosquatting campaign on npm called "Sandworm_Mode" used lookalike package names to get victims to install rogue MCP servers. Those servers then pulled SSH keys, cloud credentials, npm tokens, LLM API keys, and other secrets out of the environment. You don't just find permission scope failures as a configuration mistake after the fact. They're exploitable at the supply chain level, before an agent ever runs.

MCP authentication and the 2026 spec revision

MCP's original approach to authentication left every security decision up to whoever was implementing a given server. In practice, that meant most servers shipped with no meaningful authentication at all. The spec's stance on auth was effectively "bring your own token," and it included no native defense against tool poisoning, rug pulls, or cross-server shadowing.

The numbers reflect that gap. Only a small fraction of MCP server deployments use OAuth, and Trend Micro identified 492 MCP servers exposed directly to the open internet with no client authentication and no traffic encryption at all.

The July 28, 2026 revision to the MCP spec closes a real part of this gap. It aligns authorization with OAuth 2.1 and OpenID Connect, adds issuer validation under RFC 9207, introduces client-identity metadata documents, and adds a step-up authorization flow for handling insufficient-scope errors. Some of this builds on requirements the 2025-06-18 revision already put in place, when it made resource indicators under RFC 8707 and protected-resource metadata discovery under RFC 9728 mandatory.

What the revision doesn't fix is the delegation chain. OAuth authenticates the final hop in a chain of connections, but it keeps no record of how that chain got there. In a multi-hop setup, where an orchestrator delegates work to a specialist agent that then calls an MCP tool, the token at the end proves that last connection happened. It says nothing about the chain of trust that led to it. That's the piece multi-agent systems still need, and it's the piece the 2026 revision, for all it improves, leaves for whatever comes next.