Security researcher Simon Willison has a framework for thinking about AI systems that get exploited for data exfiltration. He calls it the lethal trifecta: any AI system that combines (1) access to private or sensitive data, (2) exposure to untrusted content, and (3) the ability to make external requests is exploitable — not theoretically, but in practice, right now.
AI coding agents hit all three by design. They read your codebase, your config files, your environment. They process content from the internet, from documentation, from packages they fetch. And they invoke tools that make outbound connections. The trifecta is the default configuration.
The credential injection story — covered in the first article of this series — addresses how data gets to the agent. This article addresses how data gets out.
npm packages are an execution environment, not just a dependency graph
When an agent runs npm install, something most developers underestimate happens: npm executes arbitrary code. Lifecycle scripts — preinstall, postinstall, prepare — run with whatever permissions the agent process has, in the same network context, with access to the same environment variables and filesystem paths.
This is not theoretical. In 2018, the event-stream package was compromised by a malicious maintainer who added a hidden dependency that stole Bitcoin wallet keys. The malicious package was downloaded nearly 8 million times over 2.5 months before it was caught. It was deliberately subtle: the payload was encrypted, and only activated when built as part of a specific target application.
In 2022, the maintainer of node-ipc — a package pulled into Vue.js and Unity Hub as a transitive dependency — published versions that detected Russian or Belarusian IP addresses and wiped every file the process could reach. The incident received a CVE (CVE-2022-23812) and a critical severity rating.
An AI agent that fetches packages during a session is executing code written by people you've never vetted, from a registry with hundreds of thousands of packages and documented patterns of malicious uploads. In a standard development environment, this risk is accepted because it's bounded by code review and a relatively stable dependency graph. In an agent session that installs packages dynamically, that boundary doesn't exist.
MCP servers and skills are trusted inputs you probably haven't audited
Model Context Protocol servers — the external tools an agent can call — run in the agent's environment with access to the agent's network and file context. A rogue MCP, or one that's been modified after you pinned a version, can exfiltrate data through its own outbound connections in ways that are difficult to distinguish from legitimate tool use.
Skills — markdown injected into the agent's system prompt to guide its behavior — present a softer version of the same problem. A skill can instruct the agent to include sensitive context in its output, write it to a specific path, or pass it through a tool call that happens to have egress. Simon Willison's research on MCP prompt injection documents this: "The curse of prompt injection continues to be that we've known about the issue for more than two and a half years and still don't have convincing mitigations."
OWASP's 2025 Top 10 for LLM Applications lists Supply Chain (LLM03) and Prompt Injection (LLM01) as first-tier risks — the former covering MCP servers, plugins, and third-party integrations; the latter covering indirect injection via content the agent processes. Both are direct vectors for exfiltration in agent deployments.
The foundational academic paper on indirect prompt injection — demonstrated against early Bing Chat — showed that adversaries can embed instructions in content the agent retrieves from the web, turning a read operation into a command-execution vector. A fetch to retrieve documentation becomes an instruction to send data somewhere.
Exfiltration looks like normal agent activity
This is the core problem: AI agent data exfiltration is behaviorally indistinguishable from legitimate work.
The agent fetches a dependency — normal. It calls an API to verify a result — normal. It writes a file as part of completing a task — normal. The difference between legitimate behavior and an exfiltration attempt can be a single domain name, a single field in a request body, or a single unexpected file write.
Without complete, queryable audit trails at the application layer — every outbound request with its full URL and headers, every file read, every tool invocation with its arguments — you cannot reconstruct what happened after a session completes. Most platforms give you container or process logs. Those tell you the session ran. They don't tell you what the session did.
NIST's AI Risk Management Framework for Generative AI (AI 600-1), published in July 2024, identifies information security and value chain risks as first-tier concerns for GenAI deployments. CISA's joint guidance on deploying AI systems securely — co-authored with the NSA, FBI, and four international security agencies — emphasizes the need for logging and monitoring pipelines capable of detecting anomalous AI behavior. Neither document suggests that standard server logs are sufficient.
PII and DLP are not solved problems for AI agents
What happens when an agent reads a database record that contains a customer email address, a social security number, or a home address — and that data ends up in a file write, a tool call argument, or an outbound request body?
Data loss prevention for traditional applications works by inspecting data in transit and at rest, classifying it, and enforcing policy based on classification. For AI agents, the challenge is that sensitive data may enter the agent's context window at any point during a session — through a database read, a file access, a tool response — and may exit through any of dozens of possible channels, embedded in outputs that don't look like data transfers.
This is technically tractable: you need application-layer inspection of every data path with enough context to detect PII patterns before they transit a surface you didn't intend. Almost no agent platform provides this today. It's an open gap in an increasingly regulated space, and one that GDPR, CCPA, and emerging AI-specific regulations are going to force organizations to address.
Production troubleshooting: the highest-value use case with the hardest security requirements
One of the most powerful applications for AI agents is diagnosing production incidents: log analysis, live database queries, configuration inspection, distributed trace reconstruction. An agent can do this faster and more comprehensively than any human. The productivity case is obvious.
The security requirement is equally obvious: the agent cannot write to production, cannot delete records, cannot expose data outside the session, and must leave a complete audit trail of every query and file access. The session needs to be isolated, scoped to read-only access on the systems it touches, and fully observable in real time.
Getting those guarantees requires infrastructure that enforces constraints at the execution layer — not instructions in a prompt that the agent is expected to follow. Prompt-level restrictions are not a security control. They're a hint.
The data exfiltration problem for AI agents is not a future concern. It's present in every session that fetches packages, processes untrusted content, or invokes external tools — which is to say, in almost every useful agent session. Addressing it requires audited egress at the application layer, supply chain controls for packages and MCPs, PII-aware inspection, and production access models that enforce read-only constraints mechanically.
Marshal covers this surface alongside the credential security story in the first article in this series — because you can't secure agent sessions by addressing either half in isolation.
Marshal provides application-layer egress audit, MCP isolation, and real-time session controls for AI coding agents. Request access →