Home / Security and data

Secrets: never let them pass through, never display them in the clear

A secret pasted into a conversation, even briefly, stays present afterwards in the logs and in any automatic review of the history, and a configuration command run for one precise purpose can display a neighbouring secret in the clear if its filter is too broad.

A secret pasted into a conversation never really disappears. It stays in the logs of the service that received the message, and any automatic review of that history, yours or a third-party tool's, can display it again months later. The simplest rule remains the first one: a password, an API key or an access token is never pasted into a conversation, not even for a quick question or a one-off fix.

Least privilege, before everything else

Least privilege is the principle of giving a tool, an agent or a person only the minimum access their current task needs, never a broader access for convenience. An agent tasked with renaming files in a folder has no need for any right over a neighbouring database, even if that database is technically reachable from the same machine. Restricting access from the start costs less than discovering, after the fact, everything a too-broad access allowed someone to read.

The filter that is too broad, a quiet leak channel

A command that lists variables or queries a configuration table for one precise purpose can display, next to the value being sought, everything sitting right beside it. The risk lies in the width of its filter. The example below creates its own demonstration data, without touching anything real on your machine:

echo "CLE_API=ax92kQ" > fixture.txt
echo "NOM_SERVEUR=serveur-principal" >> fixture.txt
grep NOM fixture.txt
grep -i "e" fixture.txt

The first command, filtered on NOM, returns only the expected line. The second, filtered on the single letter e, returns both lines, including the key. Nothing about the intent changed between the two commands, only the precision of the filter changed what was displayed on screen.

The bare command is a missing filter

A filter that is too broad is not the only trap: a command with no argument, such as env, printenv or set alone, prints every variable with its value, secrets included, and that output goes into the transcript. The typical case starts with a change of shell: a command written with quotation marks for one shell loses them on the way to another, which then runs a bare set. To check a variable, measure it instead of printing it:

CLE_API=ax92kQ sh -c 'echo "length: ${#CLE_API}"'

length: 6

The length is enough to know the variable is set, without its value appearing. In Claude Code, local transcripts now also record each request's system prompt, tools and parameters: treat a transcript as sensitive before sharing it. Automatic secret redaction covers more cases since October, but it applies to shared transcripts and debug logs, not as a general guarantee.

Filter on what is expected, never on a generic pattern

Before running a command that displays a configuration, the question to ask is not what the command does, it is what it actually displays on screen. Filtering on the expected names, or on a precise length, reduces this risk far better than a filter on a single letter or a pattern that is too short. This habit holds for a local command just as much as for a request handed to an agent: ask it to filter on precise names, never on a broad pattern that sweeps up a whole set of columns or variables. The next lesson covers what happens when a secret still ends up written into a repository tracked by a version control tool.