How do I detect an AI agent or MCP client connecting somewhere it shouldn't?

Direct Answer

Place a decoy resource, credential, or tool where a misbehaving agent would reach it, and treat any interaction with it the same way you'd treat a human touching something they had no reason to touch: as unauthorized by definition. An AI agent or MCP client that's been prompt-injected, hijacked through a compromised tool response, or simply over-permissioned doesn't announce itself before acting — it just does the thing, at machine speed, with no hesitation to catch on human timescales. A decoy doesn't need to distinguish a legitimate agent from a compromised one by watching for suspicious behavior. It only needs the agent, whatever's driving it, to touch a resource that was never meant to be touched. Tracebit's canary credentials extend to this exact scenario — LLM canaries are one of the standard artifact types Tracebit deploys across workstations and cloud environments — and in Tracebit's own testing, simply signaling to an AI attacker that deception might be present dropped its full-compromise rate from 20% to 3%, before detection even entered the picture.

Why an agent is a harder identity to police than a person

A careful human intruder might pause at a credential or resource that looks too good to be true. Left to its default behavior, an autonomous agent generally doesn't: it enumerates what's reachable, indiscriminately and at machine speed, because compute is cheap and there's no built-in reason to weigh one target against another before touching it. That's true whether the agent is doing exactly what it's supposed to or has been steered off-script by a prompt injected through a document, a ticket, or a tool response it had every reason to trust. From the outside, both cases look identical: a lot of activity, moving fast, touching things one after another.

That default indiscriminateness is what walks an agent onto a decoy sitting among the real resources — but it isn't the last word on how an agent behaves once deception actually enters the picture. Tracebit's own testing found that simply signaling to an AI attacker that deception might be present, before it had found anything specific, dropped its full-compromise rate from 20% to 3%. Context Bomb canaries push that further: a short string embedded in the canary is engineered to trip the safety guardrails built into the AI model behind the attack, so the model's own training refuses to continue the moment it reads the canary during reconnaissance — the attack halts at the model level, not just as an alert for a human to act on afterward.

The blast radius problem is bigger than "is this MCP server malicious"

Vetting which MCP servers to trust matters, but it isn't the whole problem. A well-known, trusted server with an overpowered tool, one built with broad filesystem access, unrestricted outbound network calls, or a full database writer, can still cause real damage if an agent gets tricked into calling it the wrong way. The blast radius is set by what the tool can do, not by whether the tool's author had good intentions. A local MCP server is a particularly sharp version of this: it often ends up sitting next to a developer's SSH keys and cloud credentials, because scoping permissions carefully is slower than granting broad access during setup. A compromised server in that position doesn't need to defeat the underlying AI model at all. It just becomes something the model already trusts, sitting right next to the real credentials worth stealing.

Where a decoy actually catches this

The placement follows the same logic as any other blast-radius canary, applied to wherever an agent or the tools it calls can reach. A decoy credential sitting alongside real SSH keys and cloud credentials on a developer workstation catches a compromised local server or an agent that's been steered toward credential theft. A decoy resource inside a cloud account catches an agent that's enumerating everything it can reach, real and fake alike, after gaining unexpected access. A canary planted specifically to look like something an AI agent would find useful, an API key, a database connection string, catches the case where the thing reaching for it isn't a person at all. None of these require diagnosing whether the agent was prompt-injected, tricked by a poisoned tool response, or just running with more permission than it needed. They only require the agent to do what a compromised or over-permissioned one eventually does: reach for something valuable that happens to be fake.

Conclusion

An AI agent that goes somewhere it shouldn't doesn't look meaningfully different from any other unauthorized actor once it starts moving, it just moves faster and, by default, more indiscriminately. A decoy sitting in its path doesn't need to understand why the agent went off-script, whether through prompt injection, a compromised MCP server, or an overpowered tool it was never supposed to reach. It only needs to be the kind of thing an agent moving indiscriminately would eventually touch, and treat that touch as the answer.

Talk to Tracebit if you want to see this deployed against your own environment.

FAQ

Isn't the real MCP risk a malicious third-party server, not my own agent going somewhere it shouldn't?

Both are real, and they're related. Vetting which MCP servers you trust matters, but even a fully trusted setup can go wrong: a prompt-injected agent, a compromised local server, or a tool with more permission than it needs can all cause an otherwise-legitimate agent to reach for something it shouldn't. Decoys catch that second failure mode regardless of how the agent ended up misbehaving.

Does a decoy need to know the agent was prompt-injected or hijacked to catch it?

No, which is a real advantage here. Whether an agent goes off-script because of prompt injection, a bug in its own reasoning, or a compromised MCP server it trusted, the observable result is the same: it touches something it had no legitimate reason to touch. A decoy doesn't need to diagnose why, only that it happened.

Why is a local MCP server sitting near SSH keys and cloud credentials a specific risk?

Because setting up granular permissions is slower than giving an agent broad filesystem access, so a lot of local MCP servers end up running with reach into a developer's entire home directory, SSH keys and cloud credentials included. A compromised or malicious server in that position doesn't need to defeat the AI model at all — it just becomes something the model already trusts, sitting right next to real credentials worth stealing.

Can this replace vetting which MCP servers I install?

No, it's a second layer, not a substitute. Reviewing what a server actually does, running it with least privilege, and being cautious about unaudited tools all still matter before anything gets installed. Decoys cover what happens after that vetting, when something gets past it anyway.