Saturday Shortcuts: 3 Ways to Keep API Keys Out of Your AI Agent’s Logs (I Found One Written 134 Times)

This week I went looking for my own API keys in places they shouldn’t be. I checked my agents’ logs, their notes and their scratch files.

I found one, written into my logs 134 times.

Nobody hacked anything. The logs never left my server. But a log file is the thing you paste into a support ticket, zip up for a backup, or hand to a contractor. A key in a log is a key you’ve already half given away. Here are three quick ways to catch it.

1. Search for the key itself, not the word “key”

Most secret scanners look for patterns like api_key= or sk-. That’s useful, but it misses a key that doesn’t come with a label.

The quicker check is to look for the exact values. My agents already have every secret loaded in their environment. So I had one write a small script that takes each secret, searches every log, note and script file for that exact string, and prints only the name and the file, never the value.

The receipt:

• 31 secrets checked across 2,838 files (56.7 MB) in the project folder.
• 1,307 more files in the agents’ scratch folder: 0 hits.
• The agents’ notes, instruction files and scripts: 0 hits.
• 1 hit: my Telegram bot token, in 4 log files.

It took a few seconds. You can’t paste the results anywhere without thinking, because they only contain names.

2. Read the error lines, not the happy path

The leak wasn’t in any line I’d have thought to check. It was in the error handling.

My Telegram helper has one line that logs network errors, roughly "network error: {e}". That looks harmless. But when a request can’t connect, the error message includes the full URL it was trying to reach. And Telegram puts the bot token inside the URL.

So on any day Telegram couldn’t be reached, the token got written to the log. That happened on 8 days between June 18 and October 13, which works out to 134 lines. The daemon also copies its output to a second log file, so there are 268 copies in total. It never showed up on a normal day, and that’s why I never noticed it.

The shortcut: redact once, in one place. Add a filter to the logger that swaps any secret value for *** before the line is written. Then it doesn’t matter which error message carries the key. Or log the error type (“ConnectionError”) and leave out the full message.

3. List the keys that travel in URLs, and treat them as exposed

Some services put your key in a header, which stays out of sight. Others put it in the URL path or in a ?key= query string. URLs get copied everywhere: error messages, proxy logs, browser history, analytics.

Go through your stack once and mark which keys ride in the URL. Those go first on your watch list. When one turns up in a log:

1. Rotate it first. Cleaning the log doesn’t un-leak a key. (Here’s how I map every key before rotating it, so nothing breaks.)
2. Then fix the line that wrote it, or it’ll leak the new key the next time the network drops.
3. Then delete or scrub the old copies. Including the one you forgot about, like my second log file.

My agent didn’t rotate the token or edit the logs on its own. Rotating a live key is an operator call, so it filed the finding for me with the fix list attached. That’s the right split. The agent finds, the human decides.

Do this today

1. Run an exact-value search for each of your keys across your logs and notes. Print names only.
2. Check every error handler that prints a full exception or response. Those are where the surprises are.
3. Add one redaction filter at the logger, not in every call.
4. Mark your URL-borne keys and put them at the top of your rotation list.
5. Repeat monthly. It’s a few seconds of compute. Pair it with a 10-second key health check and you’ll know your keys are both alive and private.

The takeaway: keys don’t leak through the code you wrote carefully. They leak through the error message you never read. Search for the value, and redact at the logger.

Want the whole picture of how my agents are wired, keys included? Here’s what my agentic OS looks like after 139 days. If you’d like a second pair of eyes on your own setup before something leaks, book a strategy session.