When Evidence Sanitizer replaces a detected credential or secret, it writes a deterministic marker of the formDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/facunemi/evidence-sanitizer/llms.txt
Use this file to discover all available pages before exploring further.
<REDACTED:rule.id> in place of the raw value. The marker preserves just enough context for a reviewer to understand what class of secret was present — for example, <REDACTED:authorization.bearer> clearly signals a Bearer token was redacted from an Authorization header — without exposing the value itself. Markers are fixed strings assigned per rule family; the same rule always produces the same marker, regardless of how long or complex the original value was.
Marker Reference
The table below lists every rule ID, its output marker, and the HTTP construct it applies to. Note that theauthorization.other and proxy_authorization.other rule IDs both produce a *.credentials marker (not a *.other marker) — this is intentional so the marker communicates “credential section redacted” rather than exposing the scheme name.
| Rule ID | Marker | Applies to |
|---|---|---|
authorization.bearer | <REDACTED:authorization.bearer> | Authorization: Bearer credential |
authorization.basic | <REDACTED:authorization.basic> | Authorization: Basic credential |
authorization.other | <REDACTED:authorization.credentials> | Other syntactically valid Authorization schemes |
proxy_authorization.bearer | <REDACTED:proxy_authorization.bearer> | Proxy-Authorization: Bearer credential |
proxy_authorization.basic | <REDACTED:proxy_authorization.basic> | Proxy-Authorization: Basic credential |
proxy_authorization.other | <REDACTED:proxy_authorization.credentials> | Other syntactically valid Proxy-Authorization schemes |
cookie.value | <REDACTED:cookie.value> | Individual Cookie values in safely parsed headers |
cookie.header | <REDACTED:cookie.header> | Whole Cookie header when safe parsing fails |
header.secret | <REDACTED:header.secret> | Selected sensitive API/authentication header values |
query.secret | <REDACTED:query.secret> | Selected sensitive URL query parameter values |
json.value | <REDACTED:json.value> | String values of approved sensitive JSON field names |
form.value | <REDACTED:form.value> | Raw values of approved sensitive form-urlencoded field names |
Idempotence Policy
Each rule family has an approved set of markers. When the sanitizer examines a credential or value section and finds that it is already exactly equal to an approved marker for that rule family, no finding is produced and the count for that rule is not incremented. The marker is preserved as-is. For Authorization headers, the approved markers are:header.secret, query.secret, json.value, and form.value, the single approved marker for that family is the marker itself.
This means running sanitize twice on the same input always produces byte-identical output. See Idempotence for a worked example and a discussion of edge cases.
Wrong-Context Markers
The idempotence skip applies only when the marker is appropriate for the current rule context. If an Authorization-family marker appears inside aProxy-Authorization header, it is treated as a raw credential value and re-redacted to the correct proxy marker.
For example:
<REDACTED:authorization.bearer> is not in the approved proxy marker set, so the proxy finder treats it as a raw token and replaces it:
proxy_authorization.bearer counts always reflect actual proxy credentials, not Authorization markers that migrated into a proxy header.
The same principle applies in the other direction: a proxy marker inside an Authorization header is treated as raw and re-redacted to the appropriate authorization marker.
Markers Embedded in Larger Values
The idempotence skip fires only when the entire credential section or value field equals the approved marker exactly. A marker that appears as a substring of a larger raw value is treated as raw text and the whole section is redacted. For example, the following is not considered already sanitized:<REDACTED:authorization.bearer>.extra does not equal the approved marker exactly, so the bearer finder produces a finding and the output becomes:
Idempotence Example
Sanitize a file once to produceoutput1.txt, then sanitize output1.txt to produce output2.txt:
evidence.sanitized.txt and evidence.sanitized2.txt are byte-identical. The second run produces zero rule counts because all markers are recognized as already-approved values for their respective families.