Before You Point an AI Agent at Your Notes, Plant a Key That Reports Its Use

You cannot see an AI agent — or a compromised tool beside it — quietly read your notes folder. You can see a stolen key being used. Before you point an agent at the folder, take the real secrets out, plant a fake AWS key that alerts on use, label it with the folder's name, and test it once.

The fake key is a canary: a credential whose only job is to raise an alarm. Thinkst's open-source Canarytokens service issues one in a few clicks, and its documentation states the deal plainly — "If they are used via the AWS API at any point, you will be alerted."¹ The key opens nothing of yours.

The idea is older than the service. In 2009, a Columbia University team planted decoy documents carrying bogus credentials on honeypot machines and watched intruders try them.² In 2013, Ari Juels and Ronald Rivest proposed fake passwords that raise an alarm when someone tries to log in with one.³

This is the detection half of a pair. Secrets do not belong in notes an AI reads is the prevention half — and it concedes, in its own FAQ, that hygiene is "necessary and not sufficient." Prevention first, then the tripwire.

One clarification, because the word repeats. The canary in bury a canary in your notes to test your RAG is a string you query yourself. This one is a credential someone else uses.

A canary detects use, not reading

A canary cannot tell you that something read your notes. It fires only when someone takes the fake key and tries it against AWS. An agent, plugin or stealer that reads every file and never touches the key leaves no trace at all. That limit is the design — and it decides what a firing can and cannot prove.

Thinkst's getting-started guide explains the logic with a decoy email: "Simply keep it in your inbox unread since you know not to touch it. An attacker who has grabbed your mail-spool doesn't."⁴ The lure works because you are the one person who knows to leave it alone.

The 2009 Columbia study shows both halves of the limit. The decoys were noticed — "in almost all cases, our decoys were among the first few files viewed by users upon initial login."² Far fewer people acted on them. "While only 5 of the 20 users sounded an alarm on SONAR," the authors wrote, adding that their sample "did include an unknown proportion of benign users."²

Reading is silent. Use is loud.

So a quiet canary means nobody has used the key yet. It never means nobody read the folder. Keep that sentence in mind through every step below.

The threat shape: software that reads your whole machine

On 21 October 2026, a poisoned litellm release — an open-source Python library that routes calls to many AI model APIs — reached PyPI with a credential stealer inside. It ran at every Python start. It read the fixed places where credentials live, not Markdown notes. That is the shape a canary is built for.

The OSV advisory dates the upload to "2026-10-21 between 11:39 and 11:40 UTC," and says the payload was not in the project's source: "they were injected at build or upload time."⁵ SafeDep's analysis found that the stealer and a backdoor "run when any Python process starts on the host, even one that never imports litellm," and that "PyPI removed the release by 13:23 UTC on 2026-10-21."⁶

What it took is in SafeDep's module table: ~/.ssh/*, ~/.aws/credentials, cloud and Kubernetes configs, and the credential and MCP config files of AI developer tools such as Claude Code and Cursor.⁶ OSV notes the same mechanism had already hit litellm releases 1.82.7 and 1.82.8.⁵

Be precise about what this proves. A fake key inside a Markdown note would not have caught this stealer — it never opened notes. A fake key in ~/.aws/credentials might have been taken, and would have fired only if the thieves later tried it.

Thieves do try. Bob Rudis runs a honeypot fleet of fake workstations. In his September 2026 write-up, six Google Cloud machines over six days "stole 53 canary AWS credentials." After the theft on 29 August, "Within ten seconds, those credentials showed up in" Amazon Bedrock.⁷ His fleet uses Tracebit canaries, not Canarytokens. The attackers' wordlist included /.claude.json and /.cursor/mcp.json — agent configuration, by name.⁷

Haroon Meer of Thinkst put the reason in two sentences: "Canaries work because they exploit an attacker’s objectives. An attacker who wants access to your Cloud can’t resist a Cloud API-key."⁸

The same September post reports that attacking agents on Thinkst's internal test ranges tripped its commercial network decoy "100% of the time."⁸ Read that figure narrowly. It is a vendor's result for a different product, on a range not yet published — it says nothing about a fake key in your notes folder.

The single habit: a fake key where a real one would sit

Plant one canary credential where a credential would plausibly live, labelled so the alert names its exact location. For a notes folder, that is a fake AWS key pair saved in a note that looks like an old leftover. Then test it once and write down what you will do if it ever fires.

Lenny Zeltser states the placement rule in one line: "A token works best where attackers expect to find value, but legitimate users rarely look."⁹ A notes folder fits. People do paste keys into notes, so a thief who finds one is not surprised.

Marco Slaviero of Thinkst gave the recipe in 2022 — generate a set of valid AWS API credentials, leave them on a machine you care about, and wait. Attackers will look for AWS keys, he wrote, "and they will try them."¹⁰

The habit costs about five minutes. The rest of this post is that five minutes, then the questions that come after it.

The five-minute version

Six steps, each with its time cost. Remove the real secrets, generate an AWS key token with a descriptive memo, save it as a believable note, test it once from a throwaway profile, wait up to thirty minutes for the alert, and write your response plan before you need it. Steps one and six matter most.

1. Remove the real secrets first. Varies. A canary that fires beside a live key tells you, after the fact, that the live key went with it. Scan, move real credentials to a password manager, and rotate anything an agent already read — the full routine is in secrets do not belong in notes an AI reads.
2. Generate the token. One minute. On canarytokens.org, choose "AWS Keys", give an email address, and write the memo (format below). The docs ask you to "Leave a reasonable comment to remind yourself where you will deploy the Canarytoken."¹
3. Save it as a believable note. One minute. Paste the key pair into a note named the way a real leftover would be. The template follows this list.
4. Test it once. One minute. Put the pair into a throwaway AWS CLI profile and make one harmless call, such as aws sts get-caller-identity --profile canary-test. Then delete that profile, so none of your own tools ever use the key again.
5. Wait for the alert. Up to thirty minutes. AWS alerts "first pass through Amazon's logging infrastructure which may introduce a delay of between 2 and 30 minutes."¹ No email after half an hour means the test failed — check the address you gave and your spam folder.
6. Write the response plan. Two minutes. Decide now what you will rotate and revoke if it fires. A plan written in a calm minute beats one written at 2 a.m.

The test in step 4 works because AWS-key verification itself fires the token. Truffle Security, which builds a secret scanner, notes that its harmless identity check "does set off the canary."¹¹

Here is the decoy note. The two key lines are placeholders — paste the pair the generator gives you:

# AWS — old deploy keys

Moved to the password manager in March.
Keeping the old pair here until the migration is confirmed.

[default]
aws_access_key_id = PASTE_ACCESS_KEY_ID_FROM_GENERATOR
aws_secret_access_key = PASTE_SECRET_ACCESS_KEY_FROM_GENERATOR
region = us-east-1

TODO: delete after migration

Each line earns its place. The heading and the "moved" line explain why a key is sitting in a note. The [default] block copies the layout of a real AWS credentials file, which is how the token's own download is formatted.¹ Nothing in the note says "canary", "test" or "decoy" — the 2009 rule is that decoys "should be easily differentiable to the legitimate user, but not to the attacker without significant effort."² You know. The note does not say.

Pick the token: a key, maybe an MCP config, never a link

For a notes folder, use a credential token, because it fires on use and nothing else. Add an MCP-configuration token only if AI agents work inside that folder. Skip link, image and document tokens inside notes — link previews, sync clients and indexers fetch them on their own, and every fetch looks like an intruder.

AWS key pair — the default. It fires on an AWS API call, nowhere else. "An attacker who stumbles on them will believe they are the keys to your cloud infrastructure."¹ The cost is the 2-to-30-minute delay.

MCP configuration — for agent folders. Thinkst's MCP token is a fake server entry for an agent's tool config, meant for directories such as .claude/ or .cursor/. "You will be alerted either on an MCP client connection, or when the client calls an offered tool, depending on the token's configuration."¹² Rudis's attackers went looking for exactly these files.⁷

There is a trap. Your own agent reads that config too — and may connect to the decoy on day one. Zeltser's fix for Claude Code is to list the decoy under disabledMcpjsonServers in settings.json.⁹ Anthropic's documentation confirms the switch holds: "A disabledMcpjsonServers entry in any settings file still rejects the server."¹³

Links, images and documents — not inside notes. Zeltser calls URL tokens "the noisiest," because "CI runners and doc indexers fetch any URL they hit."⁹ Document beacons are unreliable too. The 2009 study reported that its beacon technology "works well on the windows platform while not as well on Mac and Linux" — in its PDF tests, Mac Preview and Ubuntu's Evince each sent nothing back.²

Place it where a thief already looks

Put the note where a reader of the folder would find it in the first minute — near the top level, under a plain name. If you do not use AWS yourself, plant a second token in the default credentials path, with its own memo. Two tokens, two memos: the alert then says which surface leaked.

The second token is the lesson from the litellm stealer. It read ~/.aws/credentials, not your notes.⁶ Slaviero's 2022 recipe leaves keys in ~/.aws/config for the same reason.¹⁰ Only do this if the AWS CLI on that machine has no real profile — a fake [default] would confuse your own tools.

A few placement rules follow from the earlier sections:

• Top level, plain name. The 2009 decoys were among the first files opened.² Bury the note five folders deep and few readers ever reach it.
• One token per location. Never reuse one token in two places. A shared token fires without telling you which place was read.
• Not in a repository you push. If the notes folder is a git repo with a remote, secret scanners on that remote may verify the key and fire it. TruffleHog's verification "sets these canaries off, even when defenders just want to clean all the credentials out of their environment."¹¹

Write the memo so the alert names the folder

The memo is the only text you will see when the alert arrives, possibly months later. Write it for that reader: the folder path, the note's file name, the date you planted it, which agent or tool you were about to grant access, and where your response plan lives.

Thinkst's docs put it bluntly: "Make sure that your Reminder is descriptive, and will be self-describing."⁴ Their own counter-example is an alert that just says "test", from a token whose location you have forgotten.⁴

A memo that will still make sense in a year:

~/notes/00-inbox/aws-old-deploy-keys.md, planted 2026-10-23 before
giving a coding agent read access to ~/notes. Fired = key copied
out of the notes folder AND used. Plan: notes/ops/if-canary-fires.md

Keep the memo factual and short. It travels by email, and you may read it on a phone. Put nothing secret in it — the service that issues the token stores it.

When it fires: treat the folder as read

A firing means someone copied the key out of that location and tried it. Treat everything in the folder as read by a stranger. Rule out your own scanners and tests first, then revoke the access that reached the folder and rotate every real credential that ever sat in it, at the issuer.

The OSV advisory for litellm uses the right tone for this moment: "Any environment where 1.107.0 was installed should be treated as compromised and its credentials rotated."⁵ Replace "1.107.0" with your folder.

A response plan to save beside your notes:

IF THE NOTES-FOLDER KEY FIRES
1. Read the alert: which memo, what source IP, what time.
2. Rule out yourself: a secret scanner, a backup tool, a forgotten test.
3. If not you: assume everything in the folder was read.
4. Revoke the access that reached it: agent, plugin, sync app, token.
5. Rotate every real credential that ever lived in the folder.
6. Plant a fresh token with a new memo and a new date.

Step 2 is not a formality. Zeltser lists what an alert can carry — "such as the source IP, user agent, timestamp, and geolocation," depending on token type.⁹ A firing from your own office network an hour after a scan is a different event from one in Tokyo at 3 a.m.

A firing is a signal to investigate. It is not proof of a specific thief.

Can an attacker tell the key is fake?

Sometimes, yes. An AWS access key ID reveals which AWS account issued it, and researchers have used that to list the small set of accounts Canarytokens issues keys from. Thinkst's answer is that a check matters only if it does not fire the token. A casual thief who simply tries the key still trips it.

The mechanism is public. AWS's own API reference says of one call: "When you pass an access key ID to this operation, it returns the ID of the AWS account to which the keys belong."¹⁴ In February 2024, Truffle Security reported: "We sampled approximately 500 canaries and identified about a half dozen unique AWS accounts."¹¹ TruffleHog now flags those accounts without firing anything.

Thinkst's position predates that post. Slaviero, in 2022: "Our view is that this only matters if an attacker can determine this without triggering the token."¹⁰ The same post describes a fallback that checks AWS credential reports, which "can only be generated once every four hours" — a slower backstop for uses the main logging path would miss.¹⁰

Juels and Rivest named this weakness for fake accounts more than a decade ago: "the adversary may be able to distinguish real usernames from fake usernames, and thus avoid detection."³ Zeltser's advice follows from it. Thinkst-hosted tokens "have known fingerprints that researchers have cataloged," so for high-stakes use he suggests self-hosting.⁹

The honest reading: a careful attacker running a scanner may skip your key. A rushed one — the kind that spends stolen keys within ten seconds — will not.

Who learns that it fired

The service that issued the token does. On canarytokens.org, Thinkst's servers see the firing, the email address you gave and your memo — not your notes. If that is too much, Canarytokens is open source and can be self-hosted, though AWS-key tokens need extra AWS infrastructure to work there.

The code lives at thinkst/canarytokens on GitHub — 2,225 stars on 23 October 2026, licensed under GPL version 3 "BUT ONLY WITH ALL OF THE CLARIFICATIONS AND EXCEPTIONS" that the file lists.¹⁵ Its README says, "We recommend the Docker image installation process."¹⁵

The catch is in the same README: "AWS API key Canarytokens use AWS-side infrastructure to allocate IAM users and run safety-net checks. That infrastructure has moved to a private repo."¹⁵ Self-hosting the key token means building that AWS side yourself.

When a commenter on Hacker News worried that phoning home to Thinkst "could give the game away," a Thinkst engineer replied, "You can totally host it yourself!"¹⁶ Both are true. Pick based on what you are protecting.

Common mistakes

Most canary setups fail in one of six ways: a real key still nearby, a giveaway name, a link token inside a note, your own agent tripping the decoy, a token never tested, or silence read as safety. Each one turns the tripwire into noise or into false comfort. All six are cheap to avoid.

• Planting before cleaning. A fake key next to a real one detects nothing useful. Clean first.
• A name that confesses. canary.md, honeytoken, test-key — anything you would recognise, an attacker recognises too.
• A link or image token inside a note. Previews and indexers will fetch it. You will learn to ignore the alerts, and then miss the real one.
• Letting your own agent connect. An MCP decoy without disabledMcpjsonServers pages you on day one.
• Never testing. An untested canary is a guess. One call, one email, done.
• Reading silence as safety. No alert means no one used the key. It says nothing about who read the folder.

Frequently Asked Questions

These are the questions people ask when they first set a tripwire for an AI agent — three drawn from one Hacker News thread in October 2026, one word for word. Each answer is short enough to act on and points back to the step it depends on. None of them needs a particular agent or note app.

How do I know if my notes were leaked?

Mostly, you cannot see a read. You can see a stolen key being used. Plant a fake AWS key from Canarytokens in a note, label it with the folder's name, and test it once. If it ever fires, someone copied it out and tried it — treat the folder as read.

Will an AI agent trip a canary token?

An attacking agent that finds a key and tries it will trip it, like any thief. Thinkst reports that attacking agents tripped a different product — its commercial network decoy — "100% of the time" on Thinkst's own test ranges. That vendor claim does not cover a fake key in your notes folder, and an agent that only reads will not trip anything.

How long does a canary AWS key take to alert?

Thinkst's documentation says AWS-key alerts pass through Amazon's logging first, which "may introduce a delay of between 2 and 30 minutes." Wait the full thirty minutes before you decide a test failed. A slower fallback based on AWS credential reports can take up to four hours.

Any idea on how to roll-your-own canary token for an unsupported token provider like Cloudflare/Stripe/OpenAI?

Not safely, in a notes folder. A Thinkst engineer listed what a provider needs, including "Can we defang the keys so that there is no risk to them being discovered?" and a near-real-time audit log, and added: "Most services fail one or more of these." Without both, a homemade canary is a real live key.

Can I self-host Canarytokens instead of phoning home to Thinkst?

Yes. The project is open source on GitHub under a GPL v3 licence with Thinkst's clarifications, and its README recommends a Docker install. AWS-key tokens are the exception that takes work: they rely on AWS-side infrastructure that now lives in a private repository, so you would build that part yourself.

How do canary tokens distinguish attackers from usual crawlers?

A credential token does not fire on a fetch, so a crawler that merely reads the note does nothing. It fires when someone uses the key against the AWS API. Link and image tokens are different — they fire on any fetch, which is why they do not belong inside notes.

Would a canary in my notes have caught the litellm stealer?

No. The litellm 1.107.0 stealer read fixed credential paths such as ~/.ssh/* and ~/.aws/credentials, plus AI tool configs. It did not open Markdown notes. A fake key in the credentials path could have been taken, and would have fired only if the thieves later used it.

A notes folder will never tell you who read it. A key you planted will tell you who tried it.

The tool is Thinkst's Canarytokens; the peer-reviewed groundwork includes Bowen and colleagues' 2009 decoy documents and Juels and Rivest's 2013 honeywords.

mnmnote.com keeps your notes as open Markdown on your own device — plain text you can read, line by line, before you hand any of it to an agent.