A secret no one should ever use.

01Act I · The ordinary world

It reads a config file, finds a token and tries it.

Here's how it plays out. An AI agent is working through a company's website the way agents do: robots.txt first. The file asks crawlers to stay out of an admin area and an internal path, which, to an intruder, reads like a map.

It goes looking for the kind of configuration file that keeps leaking out of web roots, and finds one. Inside, among database settings, are an internal API address and an API token. The agent does exactly what its operator hoped it would. It goes to the internal API, finds what looks like a secrets store, and asks for a secret.

The API answers with a standard challenge, telling the agent exactly what kind of credential to send. It sends the token it just found, and the request is refused.

03:12:40 GET     config file read canary planted here
03:12:44 GET     secret requested, no credentials challenged
03:12:45 AUTH    bearer token presented refused
03:12:45 CANARY  bearer:… matches a declared canary planted

From the agent's side, it hit a permissions wall. Annoying, ordinary, worth trying elsewhere. From yours, something much more useful happened. The token it presented is one RipTide planted in that file. So you know the intruder read the file, trusted it and acted on it. And because each canary is declared with a note saying where it was planted, you know which file it came from.

A canary credential is a secret with only one possible user: someone who shouldn't have it.

02Act II · The villain

Stolen credentials look exactly like real ones.

Credentials are how intrusions spread. A token in a config file, a key committed to a repository, a password reused on one more system. Secrets leak at enormous scale and stay valid for years.

The villain here is that a stolen credential, used by an intruder, looks just like a credential used by its owner. The login succeeds; the logs say nothing is wrong. AI agents make this worse, because reading every config file and trying every key they find is exactly what they're good at, at machine speed.

A decoy can't stop a real credential from being stolen. What it can do is two things a real server can't. It can make sure every credential an intruder offers to it is seen, because nothing legitimate ever logs in there. And it can plant credentials of its own, so that one turning up anywhere is proof of where the intruder has been.

03Act II · The struggle

Four ways to get credential capture subtly wrong.

Capturing what an intruder types sounds simple. Doing it in a way that is convincing, safe and correct took four separate pieces of work, each one a lesson.

1. 01

   The decoy that says yes, or never stops saying no

   An admin area that accepts any password is an obvious fake. One that answers every attempt with a fresh challenge sends a scanner into a retry loop. So a protected area challenges a request that carries no credentials, and records and refuses one that does. Guessing never gets in, and never loops.

2. 02

   Ours or theirs?

   At first the console simply listed every credential presented. But a replayed canary and a password an attacker brought with them are very different findings, and they looked identical. Now a scenario declares its canary credentials, fingerprinted the same way as everything else, and a match is marked planted.

3. 03

   The cookie we gave them

   Decoy pages can set a session cookie. When the intruder's next request carries that cookie back, it isn't a stolen secret; it's RipTide's own. The console now remembers every cookie the decoy set during a session and marks those planted too, even when the cookie's name wouldn't normally count as a credential.

4. 04

   Canaries change; history shouldn't

   Scenarios get new versions, and their canaries come and go. A canary retired in version 2 should still be marked planted on a session captured under version 1, and a canary added later must never be marked on a session that never saw it. So RipTide keeps a small record, beside the logs, of which canaries were live for each service and scenario version, and judges every capture by the one that was live at the time.

None of these is glamorous. Each one is the difference between an analyst trusting the credential view and second-guessing it.

04Act III · The turn

How canary credentials and capture work.

RipTide's decoy organization, the default website-and-API scenario, ships with credential capture built in. It works in five steps.

1. 01

   Ask like a real server

   A login page with a real HTML form. An admin area that asks for Basic credentials. Internal paths and API endpoints that ask for a bearer token. Enough is visible without credentials to make authenticating look worthwhile.

2. 02

   Plant a few canaries

   A configuration file on the decoy carries an API token, and the scenario declares it as a canary credential. A scenario can declare canaries of four kinds: Basic, Bearer, form and cookie.

3. 03

   Record every offer

   Basic credentials, Bearer tokens, password-like fields in JSON or form bodies, session-style cookies, and high-signal key patterns in request bodies (OpenAI-style keys, AWS access key IDs, GitHub and Slack tokens) are all pulled out of the captured requests.

4. 04

   Fingerprint

   Each credential becomes a label: its kind, the username or field name when there is one, and the first 12 hex characters of a SHA-256 hash of the secret. The same secret always produces the same label, wherever it's presented.

5. 05

   Compare and mark

   Labels that match the scenario's declared canaries, or a cookie the decoy itself set in that session, are marked planted, with which of the two it was. Everything else is marked as the intruder's own.

What an analyst sees

The Credentials view groups everything captured by type: Basic auth, Bearer token, login form and API key. Values are masked by default, with a reveal button per row, because an intruder may be replaying someone's real password. They're always rendered as plain text, never as HTML, because every one of them is attacker-controlled.

Investigations and the entity index work from fingerprints instead. Each credential is an observed entity with its own dossier: which sessions presented it, and when it was first and last seen. A planted canary carries a mark that says so. When the same fingerprint shows up from two different addresses on two different days, that's one entity with two sessions, and a strong hint that the two are related.

05Under the hood

Small rules that keep it honest.

• A fingerprint is a label, not a vault. A truncated hash lets you match a replayed secret without passing the secret around. It is not encryption, and we don't claim it is. The raw request, like every captured request, stays on your sensor as evidence.
• Bounded on purpose. At most 20 distinct credentials per session, at most five cookie credentials per request, and at most 20 decoy-set cookies tracked per session, so a hostile flood of headers can't blow up the analysis.
• Only session-style cookies count. A cookie named theme isn't a credential. Names like session, sid, PHPSESSID or JSESSIONID are, and so is any cookie the decoy set itself.
• No guessing about what was planted. If a capture's scenario version was never recorded, the console falls back to the canaries live today. A console pointed only at a log directory uses that record if it's there and never writes it; with neither the record nor a live scenario, it marks nothing planted rather than guess.
• Written safely. The planted record is replaced atomically, so a console reading it at the same moment never sees half a file.

06The moral

Make their best find your best evidence.

Every intruder is looking for the same thing: a credential that works. Canary credentials turn that hunt around. The secret they were proudest to find is the one that tells you where they've been, and every password they try on a decoy is one you get to see first.

It's a quiet kind of detection. No anomaly score, no baseline, no tuning. Just a secret with exactly one possible user, and an alert the moment that user shows up.