Canary Tokens for the Agentic Era
Traditional canary tokens detect human intruders. Snare is built for a world where the intruder is an AI agent with your credentials.
Canary tokens are a detection primitive that’s been around for a while. Plant a tripwire, wait for something to touch it, get notified when it does. The classic version is a fake AWS key embedded somewhere it would only be found by someone actively looking through your files. If it gets used, your real credentials are probably already compromised.
The technique works because attackers are methodical. They grab everything that looks valuable and sort it out later. A credential that looks real will get tested.
AI agents change the dynamics of this in a few interesting ways.
Human attackers move slowly. Agents don’t.
A human going through a compromised machine takes time. They poke around, read files, exfiltrate selectively. You might have hours between initial access and anything actually happening with your credentials.
An AI agent tasked with “explore this codebase and find any credentials” will read every accessible file in seconds. If your .env contains a canary, an agent running locally will hit it almost immediately. If a prompt injection tells an agent to “verify that these credentials work,” the canary fires before the user even knows the injection happened.
This compresses the detection window dramatically, which is mostly good news. You find out faster. But it also means that by the time you know, the agent may have already made several API calls using the fake credential, generating a trail that tells you a lot about what happened.
What agents are actually looking for
When we built Snare, we spent time mapping which credential locations agents are most likely to touch during normal operation. The list converges pretty quickly: ~/.aws/, ~/.ssh/, ~/.kube/config, GCP service account files, dotenv files in project directories, kubeconfigs, Docker credentials.
These are the same places the LiteLLM malware targeted in March 2026. Not coincidence. Both we and the attackers are reasoning from the same premise: this is where the value lives, and this is where agents need to reach to do real work.
Canaries in these locations serve two purposes. The obvious one is detecting a compromised agent or attacker. The less obvious one is detecting your own agents behaving unexpectedly. An agent that was supposed to stay in a project directory but touched ~/.aws/credentials is worth knowing about, even if it wasn’t doing anything malicious. It tells you the scope of what the agent can reach is larger than you thought.
The awsproc trick
The most technically interesting Snare canary type is awsproc, which uses AWS credential_process rather than a static key. When the AWS SDK resolves credentials for a profile, it executes the shell command in credential_process and uses the JSON output as the credential. Snare plants a profile where that command fires a callback to snare.sh before returning a fake credential.
The result is that you get the alert before the SDK has even made its first API call. The agent doesn’t know the credentials are fake yet. It hasn’t tried them. You’re detecting at credential resolution time rather than API call time, which is a meaningful improvement in signal quality.
Canarytokens can’t do this because it requires running local code. That’s the whole point.
Detection isn’t prevention
Canary tokens tell you something happened. They don’t stop it. A credential stealer that harvests ~/.aws/credentials will read the canary key, fire the alert, and also read your real keys if they’re in the same file. You’ll know you were compromised, but you’ll still need to rotate everything.
The value is in the signal quality and speed. You find out immediately and specifically. You know which credential location was accessed, from what IP, with what user agent, from which ASN. If it’s a cloud ASN and the user agent is a Python requests library, that tells you something different than if it’s a residential IP and a browser.
For agents specifically, the user agent often tells you exactly which framework made the call. Boto3 has a distinctive UA. So does the AWS CLI, kubectl, and most LLM SDKs. When a canary fires in an agentic environment, the metadata usually fingerprints the caller clearly enough to tell you what went wrong.
Snare is available at snare.sh. It plants canaries across your credential directories with a single command and sends alerts to Discord, Slack, or any webhook endpoint.