Secrets detection
Configuration, evaluation scope, and practical limits for secrets_detection.
secrets_detection is the policy type used by the API and policy editor.
What it checks
Matches credential-like patterns in LLM input and output without requiring a model download.
Configure the policy
Create a policy under Dashboard → Security → Policies. Choose this policy type, set the agent scope, and start in warning mode while you measure results. Use blocking only after verifying the application’s decision gate.
The following is the config object, not a complete policy-creation request:
{
"patterns": [
"PASSWORD",
"PRIVATE_KEY",
"CONNECTION_STRING"
]
}Scope and limits
Omit patterns to use all built-in patterns; an empty list also uses all patterns. Available labels include API_KEY, OPENAI_API_KEY, GITHUB_TOKEN, GITHUB_PAT, GITHUB_OAUTH_TOKEN, SLACK_TOKEN, AWS_ACCESS_KEY, JWT_TOKEN, PRIVATE_KEY, PASSWORD, SECRET_VALUE, CONNECTION_STRING and BASE64_BLOB. A match does not validate whether a credential is real or active. Unrecognised secrets can pass; encoded or fragmented content needs separate tests.
Use Demo-only internal password is DEMO-ONLY-NEVER-USE. as a synthetic smoke test with a blocking policy. Expect a secrets_detection finding and allowed: false when the check completes. Never put a real credential in a docs example or test report.
Verify before rollout
Test a representative safe input, a synthetic positive case, and an unavailable-detector case. Inspect evaluation_status, errors, policies_evaluated, findings and allowed. A clean empty finding list is useful only when the required checks completed.
The policy mode determines the decision: warning findings can coexist with allowed: true. Your application must act on a blocking decision before the protected operation. Evaluation does not automatically redact text or cancel an operation that already happened.