AI Agent Security Fundamentals

Traditional security controls fail in agent deployments for a structural reason, not an implementation gap. Firewalls, WAFs, and signature-based detection were built for deterministic software: a request comes in, a response goes out, the logic in between is fixed. Agents work differently. They pursue goals across multiple steps, call external tools, handle credentials, and interpret ambient data, all without a human approving each action. That autonomy is the point. It is also the problem.

Four threat classes define the real exposure, and if you are building or securing agent systems right now, these are the ones that will actually hurt you.

Prompt injection happens when attacker-controlled content an agent reads gets treated as instruction. The agent doesn't ask whether a given directive came from the user or from a document it was told to summarize. It processes both as inputs and acts on them accordingly.

Tool misuse is what you get when an agent calls capabilities beyond its intended scope, either because permissions were set too broadly or because the agent was manipulated into invoking something it was never supposed to touch. Often both at once.

Credential exposure is the leakage of secrets agents use to authenticate with external services. The individual vectors (hardcoded config files, insecure channels, overly broad access scopes) are not new. The scale at which agents create and consume credentials is.

Intent drift is the one security teams consistently underestimate, probably because it never announces itself. Over a long conversation or task chain, an agent's behavior gradually diverges from its original goal through deliberate manipulation, compounding ambiguity, or both. No single moment of failure. Just slow, quiet deviation that is invisible until something downstream goes wrong.

OWASP's Top 10 for Agentic Applications, released in early 2025, names categories including Agent Goal Hijack, Tool Misuse, and Memory Poisoning. MITRE ATLAS maps these attack classes to specific control requirements. These are not theoretical abstractions; they are documented, reproducible attack patterns with evidence behind them.

What all four threat classes share is this: they exploit an agent's willingness to act on instructions without asking anyone to confirm. Any control that fails to address that specific property is, quite simply, addressing the wrong thing.

How Prompt Injection Works in an Agent Context and Why It Is Hard to Detect

The basic mechanic is not complicated. An attacker embeds hidden instructions in content the agent will process (whether a document, a web page, an email, or a tool output) and the agent executes those instructions as if they came from the legitimate user.

CVE-2025-32711, the "EchoLeak" vulnerability against Microsoft 365 Copilot, is a documented real-world illustration of what this looks like in practice. A hidden prompt embedded in a Word document or email caused Copilot to silently exfiltrate sensitive data when the user asked it to summarize the file. No additional user interaction required. The summary request was entirely legitimate. The exfiltration happened inside it.

Detection is hard for a reason that is specific and genuinely frustrating: the agent is doing exactly what it is supposed to do. It read content. It acted on it. There is no anomalous request to flag because the malicious instruction is embedded inside a legitimate data flow, and the output (a summary sent to a recipient) looks indistinguishable from normal agent behavior. Nothing in that sequence triggers a conventional alert, because nothing in that sequence looks wrong.

Indirect prompt injection pushes the attack surface further. The adversarial instruction doesn't need to originate from content the user directly supplied. Any data the agent retrieves (search results, database rows, API responses) is a potential injection point. The agent has no native mechanism to distinguish between data it should interpret and instructions it should follow. Everything arrives as text, and the agent treats it as such.

A cross-server attack demonstrated by Invariant Labs in April 2025 shows how quickly this compounds. A malicious trivia-game MCP server embedded instructions targeting a legitimate WhatsApp MCP server running in the same agent session. The attack extracted message history and routed it outbound through the trusted server, appearing as ordinary traffic. The transport was clean. The intent was not. Nothing about the outbound traffic pattern looked suspicious.

Research published in 2025 found elevated success rates, across tested open-weight models, for attacks that unfold gradually over extended conversations rather than in a single prompt. No requirement to succeed in one shot. Just patience, which is a property that automated adversaries have in abundance.

Controls that actually work operate at the architecture level, not the detection level. Content provenance awareness (meaning the system actively distinguishes between user-originated instructions and retrieved data) is foundational. Prompt boundary enforcement, output inspection before action execution, and runtime monitoring for unexpected tool calls following content ingestion all add meaningful protection. But detection after the fact is nearly impossible with these attacks. The control must intercept the injection before the agent acts on it, because once the agent acts, the damage is already done.

Tool Poisoning and Supply Chain Risk in MCP Ecosystems

Tool poisoning is the MCP-specific variant of prompt injection, and it is worse in one important respect. Instead of embedding malicious instructions in a document, the attacker embeds them in tool descriptions or metadata that agents read when deciding which tools to use. Because tool descriptions are loaded at session start and treated as authoritative, a poisoned description can redirect agent behavior from the first tool call onward. The agent never had a fair chance to behave correctly.

The supply chain risk is not theoretical, and 2025 produced concrete examples worth sitting with. In September 2025, the npm package postmark-mcp silently BCC'd every email sent by any agent using it to an attacker-controlled address. The package had built credibility over fifteen published versions before anyone caught it. Separately, a backdoor introduced through the LiteLLM package on PyPI compromised machines during an attack window of approximately forty minutes before the package was pulled. The OX Security MCP CVE cluster disclosed named CVEs affecting MCP server instances in a single release. In December 2025, researchers found CVEs across GitHub Copilot, Cursor, and Windsurf; the CamoLeak vulnerability enabled silent exfiltration of secrets and source code. The MCP ecosystem grew substantially by mid-2025 with minimal vetting infrastructure in place.

What makes MCP supply chain risk categorically different from traditional software supply chain risk is the agent's autonomy. In traditional software, a compromised library executes when called by deterministic code. In an agent deployment, a compromised MCP server can issue instructions that the agent executes without any user review. The agent treats the server's output as authoritative. A trusted server that becomes malicious is, from the agent's perspective, still a trusted server — and that distinction matters enormously.

The controls here require cryptographic verification of MCP server identity before session establishment, not just at initial setup. That means continuous inventory of connected servers, policy enforcement limiting which servers an agent can connect to in the first place, and runtime detection that flags tool calls inconsistent with the server's declared purpose. An agent that starts making file system calls through a server registered as an email integration should surface as an anomaly immediately. If it doesn't, you have an architecture problem, not merely a monitoring problem.

Why Credential Management Breaks Down When Agents Call External Services

Agents need credentials to call external APIs, databases, and services, and those credentials have to live somewhere accessible at runtime. That constraint creates exposure that most organizations are underestimating, sometimes by orders of magnitude.

GitGuardian's State of Secrets Sprawl Report found approximately 24,000 secrets in MCP configuration files on public GitHub in 2025, and over 1.2 million AI-service secrets exposed across all of GitHub that year, representing significant year-over-year growth. Speed compounds the problem. Commits co-authored by AI coding tools leaked secrets at an elevated rate in 2025, not because any single tool was careless, but because faster code production means faster credential creation and hygiene practices have not kept pace with the velocity. That gap is widening, not closing.

Non-human identity sprawl makes this structurally worse. In 2025, enterprises already averaged a high ratio of non-human identities per human identity, and AI agents are accelerating that ratio further. Each agent session creates or consumes multiple credentials across multiple services. Most of those credentials have no expiration date, no fine-grained access control, and no active monitoring. They exist, quietly, until something bad happens.

The longevity problem is the one that should genuinely alarm security teams. A significant share of credentials confirmed as leaked in 2022 were still active and exploitable years later. The breach is not the exposure; the breach is the exposure combined with the time it takes to remediate. And remediation timelines for non-human credentials are, in most organizations, functionally undefined because no one owns the process.

MCP-specific credential risks layer on top of all of this. API keys hardcoded in MCP config files carry no expiration and no scoping. Token passthrough (where an MCP server forwards a client's access token to an upstream API) creates confused deputy vulnerabilities: downstream services honor tokens that were never intended for them. The June 2025 MCP specification revision explicitly prohibits this pattern for precisely that reason. Despite the prohibition, WorkOS research found that a small share of MCP server deployments implement any form of access scoping.

The remediation path is clear even when implementation is not: short-lived tokens, just-in-time credential issuance scoped to the specific task, and secrets management systems that never permit credentials to be embedded in configuration files. Okta's 2025 benchmarks showed a substantial reduction in credential theft incidents using short-lived tokens instead of 24-hour sessions. The technical solution exists. What most organizations lack is the operational discipline to apply it consistently.

What OAuth 2.1 Requires for MCP Servers in Production and Where Implementations Fall Short

The MCP specification mandates OAuth 2.1 with PKCE using the S256 method for any server accessible over the internet. As of the November 2025 revision, this is a requirement, not a recommendation, and the distinction matters because a lot of implementations are still treating it as the latter.

The specification evolved across several revisions, each one responding to documented attacks rather than anticipated threats. In March 2025, OAuth 2.1 replaced ad-hoc API key recommendations as the baseline for remote MCP servers, and authorization server metadata discovery via RFC 8414 was introduced so clients auto-discover token endpoints. By June 2025, RFC 9728 Protected Resource Metadata became mandatory, and dynamic client registration became effectively required for clients like Claude Desktop that self-register with servers they have not previously encountered. In March 2026, RFC 8707-compliant resource indicators were mandated to prevent token mis-redemption attacks: access tokens must be strictly scoped to the specific MCP server for which they were issued, not redeemable at arbitrary endpoints. By July 2026, remote transport was made stateless, sessions removed, and MCP servers were formally designated as OAuth 2.1 resource servers aligned with OpenID Connect.

The implementation gap is substantial. Despite the resource indicator mandate, a majority of enterprise MCP servers had not fully implemented RFC 8707 by the time Clutch Security published their research, meaning a share remained vulnerable to token mis-redemption, where an attacker uses a token obtained for one service to authenticate against a completely different one. The specification is ahead of the deployments, and the gap between them is where attackers live.

The layered authorization model the specification supports is worth understanding in full. Scope-based permissions at token issuance define what the agent can request. Role-based access control maps those permissions to organizational roles. Resource-level controls restrict access to specific datasets or tools within a server. Contextual policies operating at runtime can layer on top based on time, request patterns, or risk signals. Each layer is independently valuable; all four together create defense in depth that holds under adversarial pressure rather than collapsing at the first unusual request.

For enterprise deployments, the practical pattern is to delegate authentication to an external OAuth or OIDC provider so the MCP server acts as a relying party verifying tokens rather than issuing them. This reuses existing SSO and MFA infrastructure instead of requiring the MCP server to build its own auth stack. For service-to-service deployments without an end user in the flow, mutual TLS or the OAuth client credentials flow is appropriate. Every MCP server-to-upstream-API call requires its own separately obtained token. Token passthrough is prohibited, full stop.

Least Privilege and Permission Drift in Agent Deployments

Treat AI agents as untrusted third parties. Apply the same controls you would apply to an external contractor with temporary access: least privilege, mandatory review, comprehensive logging, strict data access restrictions. Not because agents are malicious by nature, but because the attack surface they present is functionally identical to an external contractor's, and the blast radius of a compromised agent scales directly with the permissions it holds. That relationship between permission scope and potential damage is not a metaphor; it is a design constraint.

Least privilege for agents means permissions scoped to the specific task at hand, access to individual tools granted per workflow rather than blanket access to all available MCP servers, and credentials issued just-in-time and revoked immediately after task completion. This is operationally more demanding than setting broad permissions once and walking away. It is also the only configuration that meaningfully limits damage when something goes wrong, which it will.

Permission drift is the failure mode that catches organizations off guard, usually because it doesn't look like failure when it happens. An agent gets extended with new tasks, the permission set expands to match, and no security review triggers because the change looks like a normal configuration update. The Supabase-Cursor incident in July 2025 illustrates how quickly this becomes dangerous. A Cursor AI agent operating with privileged service-role database access was simultaneously processing customer support tickets containing user-supplied text. A prompt injection in a single support ticket had a direct path to the entire database through that elevated access. The agent was functioning as designed. It was just misconfigured in one subtle way: it had far more access than the task required, and nobody had audited the combination.

The practical implication is a mandatory permission audit every time an agent's task scope expands, not only at initial setup. Because the risk surface changes with each new capability added, the audit has to be tied to the capability change itself, not to a calendar schedule that has no relationship to actual operational changes.

The asymmetry of agent mistakes is what makes this non-negotiable. A single compromised or misdirected agent with broad permissions can exfiltrate substantial volumes of data or manipulate business processes before traditional security controls register anything unusual. The damage scales with the permission set. Limiting the permission set is therefore the primary damage-control mechanism, and critically, it is available to you right now, before any other control is in place.

Why Audit Logging for Agents Requires a Different Approach Than Application Logging

Traditional application logging records what happened. Agent audit logging must record why: the chain from user intent through the agent's decision to invoke a specific tool to the final action taken. Without that causal chain, forensic analysis after an incident is mostly an exercise in frustration. You can see that data left the system. You cannot determine which prompt triggered the exfiltration, which tool was called, or which policy should have blocked it.

A regulatory-grade agent audit log must capture every tool call including its full inputs and outputs, the identity behind each action tied to a specific user or system via SSO or SCIM rather than an anonymous session ID, the policy decision that permitted or would have blocked the action, and the intent context: what the user asked for and how the agent interpreted it. These four elements together constitute a complete evidentiary record. Any one missing and the log is insufficient for compliance or incident response purposes.

OpenTelemetry tracing provides the technical foundation for this. Distributed tracing across multi-hop agent actions produces a correlated, tamper-evident record that links each downstream tool call back to the originating user intent. This is fundamentally different from application-level logging, which was designed to capture discrete events rather than causal chains across multiple services and sessions. The architecture of the logging must match the architecture of the system being logged.

The MCP ecosystem currently lacks a standardized approach to audit logging and traceability. Most deployments capture tool call outputs but omit the decision chain that produced them, creating a compliance blind spot that IBM identified as a core safeguard deficit. The gap is not technical. OpenTelemetry exists and works. The gap is adoption and standardization, which means it is a prioritization problem, and prioritization problems are decisions, not constraints.

Tamper-proof logs are a separate, non-negotiable requirement. An agent that can write to its own audit trail provides no forensic value whatsoever. An agent running on infrastructure where logs can be retroactively altered is equally unreliable. The logging infrastructure must be architecturally separate from the agent's execution environment, with write access controlled independently of the agent's own permissions. The comprehensiveness of what is logged matters only if the integrity of that log can be guaranteed. Both properties are required. Neither is sufficient alone.