There is no Gitleaks-backed secrets provider. Earlier revisions of this page
described one, with a curated rule pack and a secrets_detection provider type;
it does not exist in the gateway. Secret detection is done with the regex
provider type, which does work, and this page shows how.
Why this matters in both directions
Credentials move through an LLM gateway two ways. A developer pastes a .env
file into a prompt asking why a service will not start, and the key is now in a
third-party provider’s logs. Or a model, having been shown a credential earlier
in a conversation or in retrieved context, repeats it in an answer.
A regex guardrail with apply_to: "both" covers both directions with the same
rule.
A working configuration
Paste it into the providers array of the guardrails plugin config, or build the
same thing on the Guardrails → Providers page in the console.
What each pattern catches
Things to know before turning this on
Patterns are RE2. No backtracking, no lookahead, no backreferences. That is
why a pattern cannot hang the gateway, and it is also why some expressions
written for PCRE will be rejected. A rejected pattern is refused at save time
with the reason and its position in the list.
Blocking is the only outcome. There is no redaction: a request containing a
key is refused, not stripped of it. There is also no log-only mode, so a new
pattern cannot be piloted without enforcing it — introduce patterns a few at a
time.
False positives block real work. eyJ… matches any base64 JSON object, not
only a JWT, and a long sk- prefixed identifier that is not a key will match
too. Start with the vendor-prefixed patterns, which are specific, and add the
generic ones once you have seen the traffic.
Responses are scanned only if you ask. apply_to defaults to input. The
configuration above sets both explicitly.
Streaming is scanned as it arrives, not only at the end, so the stream is cut
at the first chunk that completes a match. Chunks already sent cannot be
recalled — see the warning in Guardrails.
Coverage limits
The gaps that matter for credentials specifically:
- File uploads and batch payloads are not scanned. Uploading a file
containing keys goes through unexamined, and that is the highest-volume way to
move credentials through a gateway.
- Non-JSON passthrough bodies are not scanned.
- MCP tool arguments and results are not scanned.
The full list is in Known gaps in coverage.
See also
- Guardrails — the policy model, coverage, and what is
not implemented.
- Custom Regex — the same provider type
applied to organisation-specific policy.
