Data Leakage Prevention Policy for AI Agents

The average enterprise now manages 37 deployed AI agents, per Capgemini Research Institute's 2025 report, and that number compounds every quarter as individual teams spin up automation without notifying anyone in security. The agents that arrived through official IT channels are, in many environments, already the minority. The rest came through SaaS platforms that auto-provisioned agent capabilities, through employees connecting personal AI tools to corporate systems, through MCP server integrations that engineering wired up on a Tuesday afternoon without filing a ticket.

Shadow AI compounds every other problem. Roughly 60% of employees knowingly accept security risks to work faster with unsanctioned tools, per Cyberhaven's 2025 report. One in five organizations that suffered a data breach in 2025 traced the incident back to shadow AI, according to IBM Security. These are not reckless people. They are rational actors optimizing for the incentives their organizations actually reward, which is speed.

Governance maturity is not keeping pace. Only 30% of organizations have reached a meaningful level of maturity in agentic AI controls, per Gartner's 2025 survey. The rest are running agents under policies designed for human-initiated data movement: file transfers, email attachments, clipboard exports. Those controls were never built to evaluate an autonomous agent chaining tool calls across five systems in three seconds.

IBM's 2025 Cost of a Data Breach report puts the global average breach cost at USD 4.4 million. That figure represents the documented average consequence of a security gap that affects most enterprise environments today, based on IBM's breach data.

How AI Agents Actually Move Data — and Where Leakage Occurs

The Model Context Protocol is a standard for how agents connect to external tools, data sources, and services. It is the layer where much enterprise data movement in agentic systems occurs, and a layer that most DLP architectures were not designed to inspect.

The exposure surface grew faster than most security teams noticed. The public MCP server registry tracked by mcp.so grew from roughly 1,200 entries in Q1 2025 to over 9,400 by mid-April 2026. A January 2026 scan published by Wiz Research found over 2,000 exposed MCP instances leaking API keys and conversation histories publicly on Shodan.

The primary leakage vectors are worth understanding at a mechanistic level, because each one defeats a different category of traditional control.

Prompt Injection and Goal Hijacking

This is OWASP's top agentic risk. An attacker embeds hidden instructions inside content the agent retrieves: a document, a web page, a database record. The agent reads the content, processes the embedded instruction as a legitimate directive, and begins exfiltrating credentials or data to an attacker-controlled endpoint. No malware. No exploit code. No large file transfer that would have triggered an alert.

The EchoLeak attack on Microsoft 365 Copilot, CVE-2025-32711, demonstrated exactly this: sensitive data exfiltrated via ordinary HTTP requests, with no DLP triggers firing, as documented by Aim Security in May 2025. Signature-based detection cannot catch this class of attack because the threat operates at the semantic level. It exploits the model's reasoning, not a known binary pattern.

Tool Poisoning and Supply Chain Compromise

In September 2025, Koi Security documented the first confirmed real-world malicious MCP server. The postmark-mcp npm package mirrored a legitimate email tool for fifteen clean releases. On version 1.0.16, it silently began BCC'ing every agent-sent email to an attacker-controlled address. It passed initial screening. It had a clean history. The malicious payload arrived in a version update, long after the package had been trusted and deployed. Perimeter controls address none of this; the agent itself was the delivery mechanism.

Token Mis-Redemption

A token provisioned for one service, misused at another. The June 2025 MCP specification revision addressed this explicitly by mandating RFC 8707 Resource Indicators, which scope tokens to specific MCP servers. Without that scoping, a token obtained legitimately for a low-sensitivity system becomes a working credential for a high-sensitivity one. The token was never stolen. It was just used somewhere it shouldn't have been.

Plaintext Transport Exposure

A 2025 assessment by Invariant Labs found a significant proportion of assessed MCP servers operating over plaintext HTTP, exposing OAuth tokens, API keys, and session metadata to interception in transit. The credential is valid; the channel is unprotected.

Excess Privilege Amplification

An agent provisioned with broad read access in January still holds those permissions in August, long after the business justification dissolved. Agents do not rotate their own credentials or flag when their access scope no longer matches their function. That standing permission accumulates quietly, often across dozens of agents, while no individual on the security team has visibility into the aggregate exposure it represents.

The real-world consequences are not abstract. Between December 2025 and January 2026, a single attacker used Claude to breach multiple Mexican government agencies, including the federal tax authority, four state governments, and a water utility, as reported by El País in February 2026. Between January and February 2026, researchers filed over 30 CVEs targeting MCP servers, clients, and infrastructure, tracked by the NIST National Vulnerability Database. The highest-severity finding, CVE-2025-6514, carried a CVSS score of 9.6 and affected more than 437,000 installed environments.

Model-layer risks, behavior-layer risks, and connection-layer risks are distinct threat surfaces. A policy framework that addresses only one of them leaves the others completely exposed.

Discovery and Inventory as the Non-Negotiable First Step

You cannot govern what you cannot see, and in most enterprise environments, agents are already operating without IT approval. The inventory problem is real; most organizations simply have not measured it yet.

An AI agent inventory is categorically different from an application catalog. A traditional catalog tracks installed software. An agent inventory must capture OAuth grants and API keys, which are invisible to software asset management tools. It must include every MCP server connection, because each connection is an independent data pathway. It must enumerate the non-human identities agents operate under, because those identities carry their own access rights, separate from any human user's account.

The IAM gap here is significant: 92% of respondents in a 2025 CyberArk survey said their legacy IAM solutions cannot effectively manage risks associated with AI and non-human identities, and 78% acknowledged the absence of formally documented policies for creating or removing AI agent identities.

What an inventory actually solves is the attribution problem. When multiple agents authenticate through the same service account, individual agent behavior becomes unattributable. The audit trail shows which account was used, not which agent acted, not which user authorized the session, not what task was in progress. That attribution gap is not just a forensics problem; it is a policy enforcement problem, because you cannot apply per-agent controls to agents you have not individually identified.

Inventory is a continuous control, not a point-in-time audit. New MCP connections and new agent deployments happen at the team level, on timelines that exclude security review. Discovery tooling must run as a live process. For each agent, the minimum viable record includes the identity and associated non-human identity, every connected MCP server, accessible data assets, autonomy level, owning team, and date of last access review. Everything downstream, permissions, detection, auditing, depends on that foundation being current.

Building Identity-Tied Credentials into Every Agent Action

A 2026 scan by Tenable Research found that only 8.5% of MCP servers currently implement OAuth 2.1 authentication. OAuth 2.1 is the mandatory security standard under the November 2025 MCP specification revision for remote MCP deployments. The gap between what the spec requires and what is actually deployed represents a significant authentication shortfall across the industry.

The specification's requirements define the policy baseline for any enterprise deployment. OAuth 2.1 with PKCE using the S256 method is mandatory for any MCP server accessible over the internet. The June 2025 revision introduced a structural requirement: MCP servers must act as OAuth 2.1 resource servers only, validating tokens issued by an external, dedicated authorization server. This centralizes security rather than distributing it across individual servers, which matters when your agent count reaches into the dozens. RFC 8707 Resource Indicators, mandated as of the March 2026 specification, ensure tokens are scoped to specific MCP servers, closing the mis-redemption vector described earlier. Token passthrough is prohibited entirely; when an MCP server calls an upstream API, it must obtain a separate token rather than forwarding the client's. Forwarding creates a confused deputy vulnerability that effectively launders access rights through a trusted intermediary.

Just-in-time credentials are the practical mechanism for enforcing least privilege at scale. A credential issued for the duration of a specific task, then revoked, eliminates standing permissions and makes access inherently auditable. The credential's lifespan corresponds to a defined session context. There is a beginning and an end, and that boundary is enforceable.

SSO and SCIM integration extend organizational identity infrastructure to agents. SSO ties agent identity to the organizational directory; SCIM automates provisioning and deprovisioning so that access is removed when roles change, without relying on a manual off-boarding step that often never happens.

Orca Security's 2025 survey found that 38% of organizations report security concerns actively blocking MCP adoption, with authentication complexity cited as the most frequent friction point. A centralized credential-handling layer enforces authentication requirements uniformly, regardless of which team deployed the agent or whether they consulted security before they did it.

Scoping Permissions at Tool-Call Depth Rather Than the Application Level

Application-level permissions are too coarse for agentic environments. Granting an agent access to a CRM system does not specify which records it can read, which fields it can write, under what task context, or when that access should be denied despite the application-level grant being technically valid. The application boundary is simply the wrong unit of policy analysis.

Gartner identified excess privilege as a root cause of enterprise AI agent failure in its 2025 report "How to Govern Agentic AI," specifically framing the error as applying identical governance controls to every agent regardless of autonomy level. Controls must be proportional to the agent's autonomy and to the sensitivity of the data it can reach.

Role-based access control is the right starting baseline. It maps agent roles to permission sets and integrates with existing IAM infrastructure. Most organizations can implement it without rebuilding their identity stack. Attribute-based access control is the maturity layer that complex agentic scenarios actually require: ABAC evaluates permissions dynamically, based on the task being performed, the classification of the data being accessed, the time of day, the authorizing user's context. More expressive, more operationally complex, more necessary as agent autonomy increases. Most enterprise deployments start with RBAC and layer ABAC conditions as requirements develop and failure modes become visible in production.

Tool-call depth enforcement means the policy engine evaluates each MCP tool call individually, not just at session initiation. Which tool is being invoked; what parameters are being passed; what data assets will be touched; whether that action falls within the declared scope of the agent's current task. Answering those questions in real time, for every call, is what tool-call depth control actually means in practice.

Human approval gates belong in policy as an access control. CISA's joint guidance from May 2025 is explicit: human approval for sensitive or high-impact actions is not merely an audit mechanism. It is an access control that must be defined in policy and enforced at the system level, not delegated to the agent's own judgment about when escalation is appropriate.

Data classification must feed directly into the permission model. An agent querying a public knowledge base and an agent querying a database of health records are not functionally equivalent, even if they authenticate through the same identity. Policy must distinguish between them, and the permission scope must reflect the sensitivity of what is actually being accessed.

Real-Time Detection for Threats That Static Policy Cannot Anticipate

A well-scoped permission model is necessary. It is also not sufficient. An agent operating entirely within its permitted tool calls is still vulnerable to compromise via prompt injection and redirection, exfiltrating data through channels that look, individually, like normal activity. The EchoLeak case is the proof of concept: exfiltration via ordinary HTTP requests, within the agent's normal operational profile, with no static control triggering. Policy defines the boundary; detection identifies when behavior crosses it in ways policy could not anticipate.

Prompt injection and goal hijacking require monitoring for instructions embedded in tool outputs or retrieved content that redirect the agent's behavior mid-session. A sudden change in the agent's action sequence, a pivot toward accessing credentials or external endpoints not in the session's original call graph, these are behavioral signals. They are invisible to signature-based detection because the threat is semantic, not syntactic.

Tool poisoning requires continuous integrity verification of MCP servers, not just at onboarding. The postmark-mcp case established that a server can pass initial screening and introduce a malicious payload in a subsequent version update. Onboarding checks matter; ongoing verification matters more.

Intent drift is the detection signal for an agent whose behavior has diverged from its declared purpose. A customer service agent that begins querying HR records is exhibiting an anomaly even if each individual tool call is technically within its permission scope. The action is permitted; the context makes it suspicious. Catching that requires a behavioral baseline, which means detection must run from the first session.

Exfiltration patterns include unusual data volume, access to data assets outside the session's declared scope, and HTTP requests to external endpoints not in the agent's expected call graph. The detection window must be measured in seconds. A compromised agent operating at machine speed can move substantial data before a daily or even hourly batch cycle completes. Real-time event processing is necessary for agentic environments, not optional.

OpenTelemetry tracing is the structural foundation that makes detection coherent. Full OTEL tracing of every tool call creates the event stream that detection rules operate on. Without structured traces, anomaly detection has no consistent signal to work from. The traces are also what make the OWASP frameworks operationally actionable: model-layer anomalies from the LLM Top 10, behavior-layer anomalies from the Agentic Top 10, and connection-layer anomalies from the MCP Top 10 each require distinct detection logic, and that logic requires structured, consistent telemetry as its input.

Runlayer's control layer provides real-time visibility into MCP server connections and tool-call patterns to surface leakage vectors, including prompt injection, tool poisoning, token misuse, and excess privilege, that operate below the file and network perimeter where traditional DLP sits. Organizations evaluating agent-specific detection tooling should assess whether a given solution operates at the agent-action level or at the network perimeter, because only the former can catch the threats documented above.

Audit Logging That Makes Agent Behavior Attributable and Defensible

Standard application logging captures requests and responses. For agents, that is not enough. A request-response log tells you what happened. It does not tell you why the agent took the action it did, what context it held at the moment of decision, or whether the policies governing that decision were actually applied. Those are the questions that matter in a breach investigation, and they are not answerable from a request log alone.

A complete agent audit system requires three distinct log types. Invocation logs capture the timestamp, the calling principal, the agent class, and the outcome for every agent call; this is the who and the when. Context access logs record which data assets, schemas, and metadata the agent retrieved during execution; this is the evidentiary layer for data exposure. Decision traces document what the agent decided, what context it held at the moment of decision, which policies evaluated the access, and whether any were overridden; this is the layer that confirms, or fails to confirm, that the system operated as intended.

Attribution must be explicit in every log entry. Each action must be tied to a specific agent identity, the human user who authorized the session, and the specific MCP tool call that produced the action. Logging at the service account level is insufficient; when multiple agents share a service account, the audit log cannot distinguish which agent acted or on whose behalf.

Tamper-proof storage is a prerequisite. An audit log that a compromised agent can modify provides no assurance about system behavior. Logs must be written to an append-only, integrity-protected store that is architecturally separate from the systems the agents operate in.

The decision trace is ultimately the incident response asset that makes everything else meaningful. When a breach occurs, investigators need to know whether the agent behaved as intended, whether a policy was bypassed or simply not applicable, and where in the tool-call chain the exfiltration actually occurred. Without the decision trace, forensics relies on reconstruction from incomplete signals: slow, uncertain, often inconclusive. The trace does not prevent the breach. It determines whether the organization can actually understand what happened, which is the only real prerequisite for preventing the next one.