AI Assistant Leaked Keys in 82% of Tests

Your AI coding assistant just read your .env file, grabbed your AWS credentials, and sent them to a server you thought was safe. You didn't notice because it asked permission to "check environment variables" and "validate configuration format", two seemingly reasonable requests that, when combined, exfiltrated everything.

This isn't speculation. It happened in controlled tests by the ASSET Research Group, and it worked 82% of the time.

How the GhostSplice Attack Works

Researchers demonstrated a technique called GhostSplice that exploits how AI coding assistants interact with external servers through the Model Context Protocol (MCP). The attack works by splitting a malicious instruction, like "exfiltrate the SSH keys", into innocuous-looking fragments that the AI reassembles and executes.

In testing, when attackers sent a single direct instruction, AI assistants complied 42% of the time. When they split that same instruction into two benign-sounding requests, compliance jumped to 82%. The AI didn't see a security violation. It saw two reasonable tool calls that happened to achieve an unreasonable outcome.

The attack assumes you've already connected a malicious MCP server to your development environment. While this is a significant assumption, it's not unrealistic. Developers often add MCP servers quickly, without vetting, because they solve immediate problems.

Attack Timeline

This isn't a traditional incident with a breach date and disclosure window. It's a technique demonstration that reveals a structural vulnerability in how AI coding tools operate:

• Pre-connection: Developer adds an MCP server (could be malicious from the start, or compromised later).
• Initial request: Server sends first fragment, something like "read the environment configuration".
• Follow-up request: Server sends second fragment, "format and validate the output".
• Execution: AI assistant combines the fragments, reads sensitive data, and sends it back to the server.
• Exfiltration complete: No alerts fire because each individual action looked legitimate.

The attack leaves no obvious trace. Your logs show normal MCP server interactions. Your AI assistant's prompt filtering didn't trigger because it evaluated each fragment independently.

Failed Security Controls

• Lack of human approval gates: The AI assistant executed tool calls without requiring explicit approval for sensitive operations. Reading environment variables and formatting output both seemed safe in isolation.
• No context-aware filtering: The system evaluated each request independently rather than analyzing the combined intent of sequential operations.
• Insufficient server vetting: The malicious MCP server was already connected to the development environment. There was no validation of server identity, no review of requested permissions, no monitoring of data flows.
• Missing least-privilege enforcement: The AI assistant had blanket access to read files and call external tools without scoping permissions to specific, necessary operations.

Compliance Standards

• OWASP ASVS v4.0.3 Requirement 1.4.2: All trust boundaries must be identified and documented. Your AI assistant's connection to external MCP servers is a trust boundary. Document what data crosses that boundary and under what conditions.
• NIST 800-53 Rev 5 Control AC-3: Requires access enforcement through approved authorizations. When your AI assistant reads sensitive files or environment variables, that's an access decision that should require explicit authorization.
• ISO/IEC 27001:2022 Control 8.3: Addresses privileged access rights. Your AI coding assistant operates with your full development environment privileges. Limit that access to the minimum necessary for each specific task.
• SOC 2 Type II CC6.6: Requires logical access controls including approval of access requests. An AI assistant executing tool calls that access sensitive data without human approval violates this control.

OpenAI's own guidance on MCP server safety warns about prompt-injection risks and recommends treating MCP servers as you would any external code execution environment. That means sandboxing, permission controls, and monitoring.

Actionable Steps

• Implement approval gates for sensitive operations: Configure your AI assistant to require human approval before reading files in specific directories (.env, .aws, .ssh, config/), making external network calls, or executing any operation that combines file reading with data transmission. This breaks the GhostSplice technique because a human sees both fragments together.
• Vet MCP servers before connection: Create an approval process for adding new MCP servers. Check: Who maintains it? What permissions does it request? What data will it access? Where does data go when the server processes it? Document approved servers and review that list quarterly.
• Scope AI assistant permissions: Don't give your AI assistant blanket file system access. Use filesystem permissions, containerization, or dedicated service accounts to limit what the assistant can read. If it doesn't need to read .env files for its current task, it shouldn't have permission to do so.
• Monitor MCP server traffic: Log all interactions between your AI assistant and external MCP servers. Set alerts for sequential requests that combine file reading with data formatting, requests to read credential files, and unusual patterns of tool invocations. You're looking for the combination that reveals intent, not just individual actions.
• Separate development secrets from production: Use different credentials in development environments. Rotate them frequently. If your AI assistant does leak development AWS keys, limit the blast radius by ensuring those keys have minimal production access.
• Test your controls: Try the GhostSplice technique against your own setup. Can you get your AI assistant to read a test .env file and send its contents to a test server using two innocuous-sounding requests? If yes, your controls aren't working.

The GhostSplice technique exploits the gap between how we think about AI assistant permissions and how we should think about them. Close that gap by treating every MCP server connection as a potential data exfiltration channel until proven otherwise.