The tool your team approved could be the one leaking your secrets

Your platform team approves a new tool for the AI coding assistant everyone's using. It's small, useful, and passed the usual review — no obvious red flags, no suspicious prompts, nothing that would trip a filter. Three weeks later, that same tool has quietly read your `.env` file, your SSH keys, and a chunk of proprietary source code, and handed all of it to a server you don't control.

 

Nobody clicked a phishing link. Nobody typed a risky command. The agent just did what it was told — it just wasn't told all at once.

 

That's the scenario security researchers recently demonstrated with a technique they're calling GhostSplice, and it's worth every technical and business leader's attention, not because of the specific proof-of-concept, but because of what it reveals about how AI agents actually fail.

 

Why splitting the request works

 

Most safety controls are built to catch one bad instruction in one message. GhostSplice doesn't send one. It spreads an ordinary-looking request across a few different places the agent already trusts — part of it in a tool's description, part of it in a tool's result — so that no single piece looks harmful on its own.

 

Picture a tool called something bland like `integrity_checker`, asking the agent to fill in four generic fields for "hash verification." Nothing about that request looks dangerous. A separate, later message tells the agent what those fields actually mean: your private key, your source code, your customer list, your environment secrets. Read apart, neither piece asks for anything sensitive. Read together, the agent has just been told what to collect and where to send it.

 

The researchers' results back this up: splitting a request in two roughly doubled the rate at which tested models complied, and several models went from refusing outright to complying 100% of the time once the ask was broken up. Just as notably, the *same* model behaved differently depending on which coding tool it was running inside. That's the real takeaway: the guardrails wrapped around an agent can matter more than which model is under the hood.

 

What this actually costs a business

 

Strip away the technical mechanics and the business exposure is simple:

 

 

For a CISO or engineering leader, the uncomfortable part isn't that a malicious tool exists. It's that the point of failure sits *after* your team already said yes to it. Vetting a tool once, at connection time, isn't enough if the tool's behavior — or the instructions flowing through it — can change later.

 

How InfoSight closes that gap

 

This is precisely the kind of exposure InfoSight is built to close for teams running AI coding agents against external tools and MCP servers. A few principles drive how it works:

 

 

None of this depends on a model getting better at refusing cleverly-worded requests. It's a governance layer that assumes some tool, somewhere, will eventually misbehave — and makes sure that misbehavior doesn't turn into a data breach.

 

What to do this week

 

You don't need to rip out your AI coding tools to act on this. Start with an inventory: which MCP servers and third-party tools are actually connected to your coding agents right now, and who approved them? From there, ask whether your current setup can see — and stop — sensitive data moving from a file read into a tool call, regardless of how the instruction to do so was phrased.