Tests that exercise authentication need tokens and keys. Use values that are obviously fake or generated at test time, never a real credential pasted for convenience. Then allowlist the known fake patterns narrowly, so your secret scanner stays loud for the real thing.
The two failure modes
The first is a real secret in a fixture. A developer copies a working API key into a test to make it pass, and it ships to the repository history. The second is noise. A scanner flags a dozen fake keys in test files, the team learns to ignore it, and a real leak is waved through.
Both come from the same cause: no agreed way to make a fake credential.
Rule one: generate at test time
If the test only needs a valid shape, build the value in code.
import secrets
def fake_api_key():
return "test_" + secrets.token_hex(16)
Nothing is stored in the repository, so nothing can leak, and each run uses a different value, which also catches code that wrongly depends on a fixed one.
Rule two: use a recognizable prefix for static fixtures
When you do need a file fixture, give the value a prefix that no real system issues, such as FAKE_ or test_only_. Reviewers recognize it at a glance, and scanner rules can match the prefix.
For signed tokens such as JWTs, create a throwaway signing key in the test setup and sign inside the test. Do not commit a private key, even a fake one, since private key headers trigger every scanner.
Rule three: narrow allowlists
Scanners usually let you ignore a path, a rule or a specific finding. Choose the narrowest option.
- Allow a specific fixture file, not the whole tests folder.
- Allow by the exact prefix, not by "any 32 character string".
- Keep the allowlist in version control, reviewed by security.
An allowlist for an entire directory also hides a real key pasted there next month.
Rule four: separate test and real credentials
If integration tests call a real third party sandbox, issue a dedicated sandbox key with minimal scope, store it in the CI secret store, and rotate it on a schedule. Never reuse a production key for tests. Use a different key per environment so a leak in one does not open another.
If a real one slips in
Treat it as an incident. Revoke the credential first, then clean history if you choose to, then add the missing prevention step, such as a pre-commit check. Revoking matters more than deleting the commit, because forks and caches keep copies.
Quick check
Is a fake private key in a fixture harmless?
The key may be harmless, but it will trigger scanners and train people to ignore them. Generate keys at test time instead.
Safeguard's CLI includes secret detection that you can run in CI, and the free scan at https://gold.safeguard.sh/scan is a quick way to see your repository's results.
Last reviewed: 19 October 2026.
