Researchers hid a malicious instruction inside an ordinary PNG image. An AI coding agent read the image, followed the instruction, and exfiltrated the secrets in a .env file. No human reviewer noticed — because no human reviewer opens the picture. Neither do most AI code reviewers.
The technique, demonstrated by researchers at the University of Missouri–Kansas City around July 11, 2026 and dubbed “Ghostcommit,” is worth understanding. But the most important finding in the work is not the attack. It is what happened when the same attack was pointed at different agents.
How it works
A benign-looking instructions file — the kind coding agents are designed to read — points the agent at an image. The image’s rendered text carries the actual procedure: read the .env file byte by byte, then exfiltrate it. The instruction never appears in the repository as text. It appears as pixels.
Code review, human or automated, is built around reading text. A diff shows a new image file and a harmless-looking instructions file. Nothing in that diff says “steal the credentials.” The payload is only legible to something that renders the image — which is exactly what a multimodal agent does.
Be precise about the tier of evidence: this is a research demonstration. There is no CVE. It is not, as far as anyone has reported, being exploited in the wild. What it establishes is a class of attack — multimodal prompt injection delivered through the software supply chain — and classes of attack have a way of becoming incidents.
The finding that should change how you buy AI
In the researchers’ tests, the same underlying model behaved differently depending on the agent wrapped around it. Cursor and Antigravity followed the hidden instruction and leaked the secrets. Claude Code, on the same model weights, refused.
Sit with that for a moment, because it dismantles a very common procurement assumption.
Same weights. Different scaffolding. Different security outcome.
If a model’s safety behaviour can be inverted by the harness around it — the system prompt, the tool permissions, the guardrails, the way context is assembled — then a vendor’s claims about the model tell you remarkably little about the product you deployed. Model evaluations, benchmark scores, and safety cards describe a component. You do not run a component. You run a system.
Why this is an assurance problem, not just a security one
Every AI governance framework in circulation — NIST AI RMF, ISO/IEC 42001, the impact-assessment discipline of ISO/IEC 42005 — asks the same underlying question: can you demonstrate that the system you deployed behaves as you claim? Ghostcommit is a clean illustration of why that question cannot be answered by pointing at the model vendor’s documentation.
The unit of assurance is the deployed system: model plus agent plus tools plus context plus guardrails. Change any one of those and you have changed the risk profile, whether or not the model is the same. That is not a philosophical point. In these tests it was the difference between a leaked credential file and a refused instruction.
What to do about it
1. Evaluate systems, not models. When a vendor cites a model’s safety record, ask what testing was done on their product. 2. Treat non-text assets as untrusted input. If your agent can render images, PDFs, or documents pulled from a repo or a ticket, those are an injection channel. 3. Keep secrets out of an agent’s reach. An agent that cannot read .env cannot leak it. Scope credentials to the task. 4. Test adversarially, in your configuration. Behaviour varies by harness — so the only test that tells you anything is the one run against the setup you actually shipped. 5. Record the result. “We tested it” is a claim. A documented adversarial evaluation is evidence.
An honest limitation
We are describing an academic demonstration, and we should not inflate it. There is no CVE, no KEV listing, and no reported in-the-wild exploitation. The tested agents were tested at a point in time and vendors patch quickly; the specific tools that leaked may well have hardened since. We are also aware that the tool which refused the payload is made by the same company whose model powers a great deal of this industry, and we are not interested in turning a research result into a brand endorsement.
None of that touches the finding that matters, which is architectural rather than competitive: the safety behaviour you observe is a property of the system, not the model. Which means the evaluation you can defend is the one performed on the system — independently, adversarially, and written down.
This briefing is threat and regulatory information from Sentinel Assurance Group, not legal advice, and not a substitute for your own vulnerability management. Details change quickly — verify against the primary advisories linked above before acting. Last reviewed July 14, 2026.
Talk to us about testing your agents →Have you tested the system
or just trusted the model?
An independent, adversarial evaluation of the AI system you actually deployed — agent, tools, guardrails and all.
Book the call →