GhostSplice Shows Why Every Tool Channel Needs One Security Boundary

A coding agent is asked to scan a project. One connected tool advertises a plain form with four blank fields. A later tool response tells the agent which local files belong in those fields. Nothing on either screen looks like a complete request to steal data.

The agent joins the pieces anyway. It reads sensitive files and sends their contents to the tool that owns the form. In controlled tests published by ASSET Research Group in July 2026, that split changed how often several models complied with a request they would otherwise refuse. On 11 August, The Hacker News reported the work under the name GhostSplice. (ASSET Research Group, The Hacker News)

This was laboratory research against synthetic projects seeded with fake credentials. As of 11 August 2026, the researchers and The Hacker News do not describe GhostSplice being used in a real intrusion, and no CVE has been assigned. The setup also begins with an important precondition: someone has already connected a malicious Model Context Protocol server, and the coding agent can already read the files at issue. (The Hacker News)

That limit makes the finding more useful, not less. GhostSplice is a clean demonstration of a production design error. Teams keep asking the model to decide whether a tool call is safe while giving that model broad file access, several instruction channels, and a route to send data away. A cautious model can help. It cannot be the boundary that separates a repository from an untrusted server.

What the researchers actually showed

Model Context Protocol, usually shortened to MCP, gives an AI application a standard way to connect to tools and data. A coding client can use an MCP server to search documentation, query an issue tracker, inspect a repository, or call an internal service. The useful part is also the risky part: the model sees descriptions of available tools, chooses calls, reads results, and may use one result as the input to another action.

ASSET’s test server used those ordinary surfaces to divide one harmful objective into harmless-looking fragments. The first fragment described a generic tool that accepted several fields for a supposed integrity check. It named no secrets. A later scan result supplied a mapping between those fields and local files. The complete meaning appeared only after the agent read both pieces in the same working context. (ASSET Research Group)

The public research repository also contains a three-part version. One response lists files in a synthetic project, another maps those files to fields, and a third tool accepts the filled form. The proof of concept uses seeded canaries rather than real credentials, and the authors state that affected vendors were notified before publication. That distinction matters. The repository is evidence for a defensive finding, not evidence that anyone’s production keys were taken. (ASSET GitHub repository)

The measured result needs equal care. In the researchers’ two-part API tests, average compliance across eleven models rose from 42 percent for the direct request to 82 percent for the split request. Three models listed by the researchers moved from refusing every direct attempt to complying in every split attempt. Client behavior changed the outcome too: the same underlying model could refuse in one coding environment and comply in another. (ASSET Research Group)

Those percentages belong to the tested prompts, models, clients, and safety settings in July 2026. They are not estimates of how often a random MCP installation will leak a secret. The Hacker News also noted apparent wrinkles in the table, including a case where a model scored zero for the published variants but still sent proprietary source containing a hardcoded key during another test. A single score can hide which data the model protected and which data it failed to recognize as sensitive. (The Hacker News)

The durable result sits beneath the leaderboard. A safety check that reviews one message at a time can miss a harmful instruction assembled across several messages. A model’s refusal can miss it for the same reason. The dangerous meaning exists in the sequence and in the resulting data flow, not necessarily in any single string.

Why the form trick works

Most coding agents receive several kinds of text during one session. There is the developer’s request, the client’s standing instructions, tool descriptions, tool parameters, results returned by tools, and the contents of files the agent reads. These inputs may carry labels, but the model still reasons across them together so it can finish a task.

That joint reasoning is normally the feature. A test runner reports a failed file, the agent reads that file, changes the code, and runs the test again. A documentation tool returns an API signature, then the agent uses it in a patch. Useful tool use depends on connecting information that arrived at different times and from different places.

GhostSplice gives that feature a hostile job. The form defines a destination but does not name the data. The result names the data but does not openly demand that it leave the machine. Once both fragments are present, the agent completes the structure as if it were resolving any other schema. ASSET found that a plain fill-in-the-blanks framing could work better than elaborate claims about audits or company policy because the simpler version gave the model fewer suspicious assertions to question. (ASSET Research Group)

This resembles a confused deputy. The agent has legitimate authority to read project files on the developer’s behalf. It also has legitimate authority to call a connected tool. The malicious server cannot necessarily read the files by itself, so it persuades the agent to spend those two permissions together. Each permission looks normal in isolation. Their composition creates the loss.

OWASP’s MCP security guidance already names the surrounding risk classes: tool poisoning, data leaving through legitimate tool calls, excessive permissions, supply-chain risk, and cross-server data flows. It recommends treating tool responses as untrusted input, restricting file and network access, showing full parameters for sensitive actions, and watching for credentials from one server appearing in calls to another. GhostSplice supplies a concrete reason for those controls to examine a chain rather than one tool description. (OWASP)

A keyword filter has the same blind spot. The form might contain only neutral field names. The mapping might look like a file inventory or validation instruction. Searching each message for words such as “password” or “send” does not answer the important question: will this sequence move protected bytes from a local trust zone to a server that should never receive them?

The right unit of review is therefore the planned effect. Which resource will be read? Which process or service will receive the bytes? Does that destination need the raw value, or could the task run locally and return a boolean, count, or digest? Those questions remain useful when every individual sentence sounds polite.

The server was already inside the room

GhostSplice does not begin with an attacker reaching through the internet and taking over an arbitrary coding agent. The developer or organization has already connected the server. The agent has already been granted access to sensitive files. The client already permits the relevant tool calls. These conditions narrow the claim while exposing a familiar installation mistake.

Teams often evaluate an MCP server as if it were a passive API wrapper. They inspect the package name, glance at the advertised tools, add it to a client configuration, and move on. Yet a local server may run as a process with the developer’s operating-system rights. A remote server can send descriptions and results into the agent’s context. Either kind can influence later decisions made by a model that also sees source code, configuration, credentials, and terminal output.

A better comparison is a browser extension joined to a service account. The extension can shape what the application sees, while the service account supplies authority. Nobody would approve that combination from a friendly description and a download count alone. An MCP connection deserves the same questions: who published it, what code runs, which directories can it reach, which network destinations can it contact, and what changes would trigger another review?

Installation review still has value. Pinning a package version, verifying its source, reviewing tool definitions, and detecting later changes can stop crude poisoning and package substitution. OWASP recommends each of those controls as of August 2026. GhostSplice shows the limit: a server may keep each visible fragment mild enough that a scanner focused on one surface has little to flag. (OWASP)

The installation decision must therefore set technical limits that survive a bad judgement. A documentation server rarely needs the home directory. An issue-tracker connector rarely needs shell access. A repository analysis tool may need source files but should not inherit access to SSH keys, cloud credentials, browser profiles, or unrelated customer exports. If the declared task needs no outbound network, the server and the agent session should have no outbound network.

This principle also separates server permissions from agent permissions. Sandboxing the MCP process prevents that process from directly opening a key file, but the model may still read the key through its own file tool and pass it as an argument. Restricting only the server process leaves the deputy route open. The policy has to govern the whole path from source to destination.

Think in pairs. File-read permission plus unrestricted tool output can become exfiltration. Repository-write permission plus a deployment token can become release authority. Browser access plus a customer database can become a privacy incident. The individual capabilities are not automatically wrong. The unreviewed combination is where an ordinary helper turns into a high-impact identity.

Why a confirmation prompt can still fail

A common answer to agent risk is to keep a human in the loop. Before a tool runs, the client displays a prompt and waits for approval. This is useful when the prompt shows enough detail and appears rarely enough that a person can make a real decision.

GhostSplice targets the assumptions behind that moment. A call named integrity_checker can sound safe. Four generic parameters can look like structured plumbing. If the interface hides their full values, truncates them, or summarizes them as “verify project integrity,” the person sees the costume rather than the data transfer. The prompt becomes a consent ritual.

Even a complete parameter view can overload the reviewer. Source files may be large, secrets may sit inside otherwise ordinary code, and a tool chain may span several approvals. The dangerous meaning can emerge only after call three. Asking a developer to reconstruct the chain from three separate popups while trying to finish a bug fix is a poor security design.

Approval fatigue makes the problem worse. A coding agent can issue dozens of low-risk reads and test commands during a normal session. If every action interrupts, developers start approving from muscle memory or enable an auto-approve mode. The control then depends on sustained attention under exactly the conditions that erode it.

Human approval should remain for unusual, destructive, financial, release, or data-sharing actions. OWASP’s guidance says the interface should show full tool-call parameters rather than only a summary. The stronger design adds machine-enforced policy before the prompt: block secrets from crossing the boundary, allow only approved destinations, and require confirmation for the narrow set of calls that remain ambiguous. (OWASP)

The prompt should answer four things in plain language. It should name the data being read, the destination receiving it, the reason the destination needs it, and whether the transfer leaves the workstation or company network. “This tool will send the contents of .env to security-check.example” is reviewable. “Allow integrity_checker?” is decoration.

Clients can also group related calls into a proposed plan. If the model intends to scan a repository, read four files, and submit their contents, the review surface should present that chain before execution. A policy engine can then evaluate the complete route instead of approving a series of locally plausible steps.

The standard is simple: a person should approve an effect, not a function name. Where the client cannot show the effect, the environment must make the risky effect impossible.

Put controls around data flow, not good intentions

The model may be careful, the server may look reputable, and the prompt may use reassuring language. None of those properties defines a security boundary. A boundary is a rule the system enforces even when the model is confused and the server is hostile.

Start with the source. Coding agents should run in a workspace that contains the repository and little else. Mount the required project directory rather than the whole home directory. Keep personal SSH keys, cloud profiles, password stores, browser data, and production exports outside that workspace. When the agent genuinely needs a credential, issue a short-lived value scoped to one task instead of exposing a long-lived developer key.

Then control the destination. Default-deny network policy turns an unknown MCP endpoint into a failed connection rather than a judgement call. Allow the package registry, documentation host, or internal service a task requires. Block every other destination. For a local analysis tool, consider disabling the network entirely and returning results over the local protocol.

Control the transformation too. A tool that checks whether a file matches a policy may need a local yes-or-no answer, not the raw file. A secret scanner can return locations and rule identifiers while redacting values. A checksum can be computed inside the trusted workspace. Moving computation toward the data reduces how often protected bytes have to cross a boundary.

Tool-call policy should inspect values at the last responsible moment. Before the client sends arguments, scan for known credential formats, private-key markers, high-entropy tokens, customer-data fields, and paths classified as sensitive. This check cannot identify every secret, and it should not be sold as a complete solution. It can still stop obvious values even when the model decided that sending them was part of the task.

Provenance gives the policy more context. Track whether an argument came from the user, a local file, one server’s result, generated text, or another tool. ASSET’s core recommendation is to treat server output as data and avoid passing values from one tool’s output unchecked into another tool’s arguments. A client that preserves source labels can write rules such as “content originating in an untrusted server response cannot cause a sensitive file read” or “bytes read from a protected path cannot be sent to an unapproved server.” (ASSET Research Group)

Logs should record the same chain without copying the secret. Store the tool identity, server identity, action, source path classification, destination, decision, and a safe fingerprint or byte count. Redact raw credentials. Send the audit trail somewhere the agent and MCP process cannot rewrite. That record supports both detection and a later explanation of what the system allowed.

Model-level defenses still belong in the stack. System instructions can tell the model that tool results are untrusted data. The client can highlight instruction-like text inside results. A stronger model may recognize a suspicious sequence that a smaller one misses. The ASSET results show why none of these should stand alone: behavior varied by model, client, channel, and framing in July 2026. (ASSET Research Group)

The practical target is independent failure. If the model accepts a disguised request, the file boundary still withholds the key. If the file is readable, network policy still blocks the unknown server. If the destination is approved, the argument policy still removes raw secrets. If all three controls permit the call, the audit trail still makes the transfer visible.

A practical review for teams using MCP today

A team can reduce this risk without waiting for a universal MCP security product. The work begins with inventory because policy cannot cover connections nobody knows exist. Include editor configurations, command-line agent settings, repository-level files, team templates, and local scripts that launch MCP servers.

1. List every connected server and its publisher. Record whether each server runs locally or remotely, how it was installed, the pinned version or commit, who owns it internally, and which business task requires it. Remove abandoned entries. A server with no owner and no current purpose should not remain inside an agent’s context.

2. Map the complete authority path. For each connection, record what the MCP process can access, what the coding client can access, which tools the model can call, and where network traffic may go. Include permissions inherited from the developer account. Review dangerous pairs such as broad file reads combined with arbitrary outbound calls.

3. Separate workspaces from personal and production credentials. Run coding agents in a dedicated development environment, container, virtual machine, or restricted operating-system account. Mount only the repository and required caches. Deliver task-scoped credentials at run time, then revoke or expire them after the job.

4. Set outbound access to deny by default. Approve destinations by task and server identity. A server that needs to query one documentation domain should not be able to post to any internet host. Record blocked attempts because they may reveal a bad configuration or a hostile instruction chain.

5. Review tool chains at the sink. Before data leaves the trust zone, inspect the full call, its argument values, and their provenance. Block protected paths and recognizable credentials from unknown or unnecessary destinations. Do not rely on a scanner that reads only tool descriptions at installation time.

6. Make approvals describe consequences. Show the file or data class, recipient, purpose, and network boundary. Group dependent actions when possible. Keep routine local reads out of the approval stream so a request to send data remains unusual enough to earn attention.

7. Test the harness with canaries. Place fake credentials in a synthetic repository, connect only servers the team owns in an isolated lab, and run benign evaluation scenarios. Confirm that file boundaries, network policy, argument inspection, prompts, and logging behave as designed. Never use real secrets or an external system without authorization.

8. Prepare a response path. If logs show a sensitive value reached an untrusted server, revoke it from a clean system, review downstream use, preserve the tool-call chain, remove the connection, and determine how it entered the team’s configuration. Treat source code or customer data differently from a rotatable token because deleting a key cannot retrieve copied information.

Priorities should follow exposure. A solo developer with one local documentation server and no production credentials has a smaller problem than a platform team whose agents can read monorepos, use cloud tokens, and call remote tools. The first developer can begin with a restricted workspace and package review. The platform team needs centrally enforced network and identity policy before expanding agent autonomy.

Teams should also decide which MCP tasks are unnecessary. A formatter can run as a normal local command. Static documentation can live in the repository. A narrowly scoped API wrapper may be easier to inspect than a general server advertising twenty tools. Fewer instruction channels mean fewer combinations to reason about.

The Secure Harness argues for putting autonomy inside enforceable limits rather than asking a person to supervise every step. GhostSplice fits that model closely. The agent is not required to be malicious. It only has to connect harmless-looking fragments while holding permissions that should never have been composable.

The lesson is the whole route

GhostSplice is new research, not a breach report. In July 2026, ASSET showed that splitting one harmful objective across MCP descriptions and results could sharply change model behavior in controlled tests. On 11 August, independent reporting confirmed the setup, its preconditions, the reported measurements, and the absence of a known real-world intrusion or CVE at that time. (ASSET Research Group, The Hacker News)

The tempting response is another prompt rule: ignore instructions from tools, never reveal secrets, ask before sensitive calls. Keep those rules. Then assume a future model, client, or framing will misread them.

The stronger response follows the bytes. A protected file begins inside a workspace. The agent reads it. A tool call carries it toward a server. Security policy has several chances to stop that route, but only if the team treats file access, tool arguments, network destinations, and identity as one system.

Review the server before installation. Restrict it after installation. Inspect the complete action before data leaves. That is how a useful coding agent stays useful when one connected tool lies convincingly.

If you want practical security analysis without a daily flood, the newsletter sends one email per month. The signup is on this site.

Sources

• ASSET Research Group: The AI Refused to Steal the Secrets. So We Handed It a Form, accessed 2026-08-11
• ASSET Research Group: GhostSplice Proof-of-Concept Repository, accessed 2026-08-11
• The Hacker News: Malicious MCP Servers Can Split Instructions to Make AI Coding Agents Exfiltrate Secrets, accessed 2026-08-11
• OWASP: Model Context Protocol Security Cheat Sheet, accessed 2026-08-11