Skip to main content
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.