Canary tokens for AI agents: detecting exfiltration early

An agent with your credentials can copy them into a context window, into a transcript, or into a tool call — and you will not see any of it happen. By the time you notice a leaked API key, it has usually been in the wild for days. Exfiltration by AI agents is easy; detection is the hard part. Canary tokens are one of the few detection mechanisms that fit the problem.

What a canary token is

A canary token is a credential that looks real but is monitored. Its only purpose is to be stolen. The classic example is a unique URL: someone fetches it, and your server logs the request and fires an alert. Another is a fake API key for a service you monitor — the key is dead by design, but its first use tells you that an attacker recovered it.

The principle is borrowed from network intrusion detection: instead of trying to watch every path a secret could take, plant something that screams when it is touched. The token converts an invisible event — a secret copied — into a visible one: a request or a failed authentication that you control.

Why agents change the calculus

Canary tokens were already useful before agents, but agents make them more attractive for two reasons. First, agents assemble secrets in one place: a credential store, an environment, a config file — all reachable from a single prompt. An attacker who has taken over an agent session has a concentrated target. Second, agents leak into intermediate artifacts: session transcripts, tool logs, summaries, and provider-side request logs. A leaked credential is likely to be used by whoever finds it, which is exactly the event a canary is designed to catch.

How to deploy canaries for an agent setup

• Pick a type that fires. A URL-based canary fires on any fetch, which catches even lazy exfiltration. A credential-based canary fires on authentication attempts against an endpoint you control.
• Plant them where secrets live. A .env file, a README, a backup directory, and the credential store itself are all realistic locations. The point is that the canary sits next to the real secrets, so it is taken along with them.
• Document them internally. Keep a list of your own canaries so you do not trip the alerts yourself — and so a red team or an auditor can verify the coverage.
• Route alerts somewhere fast. The value of a canary decays with response time. An alert that lands in a monitored channel you actually read beats one that sits in a log file.

Know the limits

A canary does not detect the leak itself; it detects the use of the leaked value. There is a gap between the two, and during that gap an attacker can be working. Canaries are also a one-shot signal — once fired, the token is known and the attacker may adapt. Treat them as a detection layer that complements, not replaces, prevention: keep secrets out of agent context in the first place, scrub tool output, and keep an audit log of credential access so that when a canary fires you can reconstruct the path it took.

If you are already running a credential broker, canaries slot in without changes: plant them in the same store your agent reads from, and let the broker’s audit log tell you which process resolved which key. trustless keeps an append-only audit log of secret resolutions, documented under /docs/commands/, which pairs well with canary alerts when you need to trace an incident.

If one of your agent’s credentials appeared on a public paste site tomorrow, how long would it take you to find out — and could you trace how it got there?