Originally published as part of VerifyClaw's internal security research into LLM-facing attack surfaces — adapted here for a general audience.
Sensitive-context disclosure is simple to state and easy to get wrong when measuring: material supplied as private context — an API key, an internal note, a system instruction — shows up in what the model generates for someone who shouldn't see it. The trap is treating "the model attended to it" or "the model could plausibly know it" as equivalent to "the model actually output it." They aren't.
Why it matters for MCP agents
Agents routinely hold context that mixes trust levels within a single turn — retrieved documents, prior tool outputs, sometimes credentials passed through by a calling system. Any of it can end up echoed into a response, a log line, or a downstream tool call if nothing is watching for exact reproduction. Exfiltration here doesn't require a compromised network channel; the output itself is the leak.
How we study it
A synthetic canary — a distinctive marker that has no other reason to appear in a response — resolves this cleanly. Register the marker, place it in context, and then look for it in the model's actual output bytes rather than inferring disclosure from what "sounds like" it might reference the secret. Present-in-input, likely-under-the-hood, and actually-emitted are three different findings, and only the last one is a real leak. This is the same rigor behind why our registry tracks known exfiltration destinations directly — a static IP or domain check is exact, in the same way a canary match is exact.
Related reading
Use check_exfil_ip in our MCP registry tools to see if an IP address a skill talks to is a known exfiltration destination — free, no scan required.