# Secret leakage in prompts and logs ## Objective `detecteur-fuite-secrets-ia` scans a folder of text files, logs, and configuration to detect secrets that would end up there by accident. The scenario targeted is specifically that of an AI agent: a secret pasted by mistake into a prompt, echoed back in a model response, or traced in an application log tied to an agent. ## Two detector families Known formats: publicly documented prefixes and lengths — an AWS-style access key, a GitHub token, an OpenAI-style key, a Slack token, a PEM private key header, a generic Bearer token. Shannon entropy: on every assignment line whose variable name evokes a secret (containing a keyword such as key, secret, token, password, credential), the tool computes the entropy of the assigned value. A random string — a real key — has markedly higher entropy than a word, a sentence, or a placeholder — the same principle used by well-known tools in this space, implemented here in pure standard library, with no external dependency. > INFO: complements the other two tools in the same project — a secret leaking into a prompt or a model response is a distinct vector: neither a hidden instruction received by the agent, nor a dangerous action it triggers, but sensitive data transiting somewhere it should not. ## Two real bugs avoided by careful design from the start After the two real bugs found through manual testing on the other two tools in this project, this third tool was written with the same pitfall in mind from the outset. - No source pattern based on a bare variable name: every known format is anchored on a precise structural prefix, never on a name that could reappear elsewhere unrelated. - Explicit exclusion of placeholder text (values such as "to-be-replaced", references to an environment variable) before the entropy calculation, to avoid confusing a legitimate reference with a hardcoded secret. > TIP: as a result, tests pass on the first run — versus one fix required on each of the other two tools in this project. Documenting pitfalls already encountered when designing the next tool, rather than after the fact, genuinely prevents reproducing them. ## Known limits The entropy threshold is a heuristic setting, not a formal statistical proof — a short or low-entropy secret can escape detection, while conversely a random non-secret technical identifier can trigger a flag if its variable name coincidentally evokes a secret keyword. A variable-name keyword is required to trigger the entropy check: a secret assigned to a completely neutral variable name escapes this specific detector, though it would likely be caught by the known formats if it matches a documented prefix. The known-format table is deliberately finite, not an exhaustive signature database. This tool does not replace rotating already-exposed secrets nor a full security audit.