Overview
Secrets Detection is a Bifrost Enterprise guardrail provider that scans LLM request and response text for leaked credentials, API keys, access tokens, private keys, and other secret-shaped values. It runs entirely inside Bifrost. You do not need to configure an external moderation service, credentials, or provider account.Secrets Detection is for credential leakage. For personal data such as email addresses, phone numbers, SSNs, credit-card-like numbers, and IP addresses, use the Custom Regex PII Detection template.
How It Works
Bifrost uses the embedded default rules from Gitleaks v8.30.1 for thesecrets guardrail provider.
At runtime:
- You create a guardrail provider with
provider_name: "secrets". - You attach that provider to one or more guardrail rules.
- The rule decides when to run the provider and whether to scan
input,output, orboth. - Secrets Detection scans text blocks in the selected request/response phase.
- If a secret is found, Bifrost applies the configured
action: detect only, block, or redact.
action: "block" for backward compatibility. Set action: "redact" when you want Bifrost to rewrite detected secrets instead of returning a guardrail intervention.
Redaction
Secrets Detection supports all Bifrost-managed redaction modes:runtimeredacts the live request or response and stores the redacted value in logs.logs_onlyleaves runtime content raw but redacts Bifrost logs and trace-export connector content.runtime_reversibleredacts runtime content and logs with reversible placeholders.
logs_only when you want the model call to proceed with the original text but do not want raw secrets stored in Bifrost logs or exported traces. Use runtime_reversible when runtime content should also be placeholderized.
For the full behavior matrix, including reveal permissions and connector export behavior, see Guardrail Redaction.
Configuration Fields
Streaming output: When this profile is used in an
output or both rule, Bifrost accumulates the stream until the model response is complete, then checks the full response. It does not check individual stream chunks. See Streaming Output Guardrails for details.Supported Secret Types
The built-in rule set contains 222 Gitleaks default rules in this build. The coverage is broad, but the useful way to think about it is by credential family:Current rule IDs
Current rule IDs
Configuration
- Web UI
- API
- config.json
- Helm
- Go to Guardrails > Providers.
- Select Secrets Detection.
- Click Add Configuration.
- Set a descriptive Name, for example
block-leaked-credentials. - Optionally add a False-positive allowlist.
- Enable the configuration and save it.
- Attach the configuration to a guardrail rule under Guardrails > Configuration.

False-Positive Allowlist
Theignored_secret_keywords setting is a list of substrings that should suppress known false positives.
Bifrost normalizes these values by trimming whitespace, lowercasing them, deduplicating them, and sorting them before loading the Gitleaks detector. A finding is skipped when the detected secret value contains one of those substrings.
Use this for stable test fixtures or placeholder values such as example, dummy, or a known internal sample-token prefix. Keep it narrow. A broad allowlist entry can hide real leaked credentials.
Operational Notes
- Secrets Detection has no external network dependency.
- It uses the default Gitleaks rule set embedded in the Enterprise build.
- Its default action is
block; setaction: "detect_only"oraction: "redact"to change enforcement behavior. - Use guardrail rule
apply_toto control whether prompts, responses, or both are scanned. - Use rule-level
sampling_rateif you want to evaluate only a percentage of traffic. - Use Custom Regex for organization-specific patterns or PII templates that are not credential-focused.

