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 does not come from the command itself, it comes from 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.txtThe 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.
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.
Three leak channels, and their fix
| Channel | What leaks | Fix |
|---|---|---|
| A secret pasted into a conversation | Stays in the service's logs and in any automatic review of the history | Never paste a secret in the clear, not even for a quick question |
| A command that lists variables | A filter that is too broad displays a neighbouring secret in the clear | Filter on the expected names, never on a single letter or a short pattern |
| A query on a configuration table | A whole column comes back, secret included, for an unrelated query | Select only the useful columns, never the whole table |
To check a configuration variable named NOM_SERVEUR before a technical intervention, an administrator runs a command that displays every environment variable whose name contains the letter e.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that the filter used, the letter e, is broad enough to return any variable whose name contains that letter, secret or not.
What this does not establish: It does not establish the exact list of variables actually displayed by this command on this particular machine.
The three most common miscalibrations
- Too broad This command must have displayed every secret stored on this machine, whatever its name.
- Too narrow This situation shows nothing more than a command run before a technical intervention.
- Off target It shows that the technical intervention concerned the server named in NOM_SERVEUR.
- A secret pasted into a conversation stays afterwards in the service's logs and in any automatic review of the history, even months later.
- Least privilege limits a tool's or an agent's access to the strict minimum its task needs, never a broader access for convenience.
- The risk in a configuration command rarely comes from its intent, it almost always comes from the width of its filter.
- Filtering on the expected names, never on a single letter or an overly short pattern, prevents a neighbouring secret from being displayed by accident.
Today, pick a configuration command you use regularly on your machine, a variable listing, an export, or a query on a table, and run it while paying close attention to what it actually displays on screen rather than what it is supposed to do. If a field you were not looking for also appears, tighten the filter before running it again.