Secret Redaction Kinds
The secret kinds Fuse detects and redacts, how each is matched, and how redaction interacts with token counting and the cache.
Secret redaction always runs on source returned by current fuse context, fuse review, and fuse reduce commands and their MCP equivalents. Fuse reduces content, replaces detected values with [REDACTED:<kind>], and then counts tokens. Detection is best-effort: unrecognized secrets can pass through, while hashes and base64 blobs can trigger the entropy heuristic.
This page is for engineers who need to know the secret kinds Fuse detects, agents reading redacted content, and maintainers verifying the detection rules.
Purpose and Scope
This page documents the secret kinds, how each is matched, and the controls and side effects of redaction. It does not cover the threat model or operational guidance for handling secrets, which the Secret Redaction guide covers, nor the full option set, which Options lists.
Current and Legacy Controls
Current semantic-context and reduction commands expose no switch to disable redaction and no redaction-report option.
Two flags remain on the legacy directory-fusion pipeline:
--no-redactdisables redaction entirely. Content passes through unchanged.--redact-reportappends a count summary to the output, reporting how many matches of each kind were redacted.
Redaction state is part of that pipeline's reduction-cache key. Redacted and unredacted legacy runs do not share cache entries.
The Kinds
Each kind below is detected by a dedicated rule, except high-entropy, which is a heuristic that catches secrets the named rules miss.
| Kind | Detected by |
|---|---|
| aws-access-key | An AKIA-prefixed key followed by 16 uppercase or digit characters. |
| aws-secret-key | An aws_secret_access_key assignment whose value is 40 characters from the base64 alphabet. |
| jwt | Three base64url segments separated by dots, the first beginning eyJ. |
| pem-private-key | A whole PEM private key block, the BEGIN line through the matching END line including the base64 body, covering the RSA, EC, DSA, OPENSSH, ENCRYPTED, PGP, and plain private key variants. The entire block is removed, not only its header. |
| github-token | A GitHub token: the ghp_, gho_, ghu_, ghs_, or ghr_ prefix followed by 36 or more alphanumerics, or a fine-grained github_pat_ token. |
| google-api-key | A Google API key: the fixed AIza prefix followed by 35 url-safe base64 characters. |
| slack-token | A Slack token: an xoxb, xoxa, xoxp, xoxr, or xoxs prefix followed by the dash-delimited body. |
| stripe-key | A Stripe live secret or restricted key (sk_live_ or rk_live_ followed by 16 or more alphanumerics). |
| connection-string | A quoted literal holding at least two semicolon-delimited key=value pairs, one of whose keys is a connection keyword (Server, Data Source, Host, Initial Catalog, Database, User ID, Uid, Password, Pwd, Integrated Security, Trusted_Connection, Port, AccountEndpoint, AccountKey). The multi-pair literal requirement avoids redacting ordinary code assignments such as Server = GetServer();. |
| api-token | An api_key, api_token, secret_key, or access_token assignment whose value is 16 or more characters. |
| high-entropy | A quoted literal of at least 32 characters whose Shannon entropy is at least 4.5 and which contains mixed case, a digit, and a symbol. |
The high-entropy rule is the one most likely to produce false positives, because it matches on statistical shape rather than a known format. It is also the rule that catches credentials the named patterns do not recognize.
The Marker
A redacted match is replaced with [REDACTED:<kind>], where <kind> is the value from the table above. For example, a detected JWT becomes [REDACTED:jwt]. For the high-entropy kind, the surrounding quotes are preserved and only the literal content is replaced, so "a1B2c3...!" becomes "[REDACTED:high-entropy]". The marker keeps the structure of the code readable while removing the value, so a reader can see that a secret was present and what kind it was.
Code-Literal versus Config Breakdown
The legacy redaction report distinguishes matches inside C# string literals from matches in configuration values. A non-zero code-literal-modifications line means redaction changed a code literal. This is a diagnostic classification, not a secret kind, and is excluded from the secret total. Current semantic-context commands do not emit this report.
What This Does Not Cover
This page does not give guidance on responding to a detected secret, rotating credentials, or treating redaction as a security boundary; the Secret Redaction guide covers operational use. For the flags named here, see Options.
Next
Read the Secret Redaction guide for operational guidance, or Options for the flags that control redaction.