What does Safeguard do when it finds a leaked secret?

Safeguard scans source, Git history, container images and more for leaked credentials, tests whether a key is still live, and walks you through revoke, rotate, purge and notify. The mobile app is in early access beta, and the secrets documentation does not describe it, so use the CLI, IDE or web dashboard.

Why is the mobile app not the focus here?

We were asked to write about finding leaked secrets from the mobile app. We read the Safeguard documentation and the secrets scanning page. Neither mentions mobile. We know the iOS and Android app is an early access beta, and we will not describe features we cannot confirm.

So this post covers what the documentation does say. If mobile support for secrets is documented later, we will update it.

What does the secrets scanner look at?

The documentation lists these targets: source code at current HEAD, Git history, container images including all layers, packaged artifacts such as jars, wheels and gems, CI build log tails with redaction at the source, vendor SBOMs, and model weights.

Detection works in three layers. Issuer specific patterns cover over 200 cloud, SaaS and identity providers. Generic patterns cover private keys, JWTs, bearer tokens, OAuth refresh tokens and connection strings. Entropy and structural checks flag random looking strings while filtering out hashes and UUIDs.

How does it decide what is urgent?

For issuer specific patterns, Safeguard makes a low privilege call to the issuer to check whether the secret is live. The docs give sts:GetCallerIdentity for AWS and /user for GitHub as examples. Unverified findings are still raised and marked unverified. You can turn verification off per issuer, which suits air gapped or outbound restricted environments.

Severity follows from that. Critical means a verified, high privilege credential. High is verified with lower privilege. Medium is an unverified match for a known issuer, and Low is a generic or entropy based finding.

What is the remediation flow?

For verified findings, the playbook has four steps:

1. Revoke. Call the issuer's revoke API where supported.
2. Rotate. Open a pull request with a placeholder, or rotate through a secret manager.
3. Purge from history. Optional, using git-filter-repo or BFG. The docs warn about force push implications.
4. Notify. Alert the owner and dependent services.

Each step is gated, and you choose whether it runs headlessly or waits for approval. Do the revoke first, because a key in history stays valid until you cancel it.

How do you run it locally?

The docs give one local command: safeguard detect --detect secrets. The CLI documentation page itself says secrets are computed during a scan and a secret.json file is produced, and tells you to run safeguard --help for the full list, so confirm the command on your installed version.

The docs also state limits plainly. There is no CLI command yet for listing, revoking or rotating secret findings. You manage them in the dashboard. There is no CLI command for installing a Git hook either, although the IDE extension blocks secrets before push.

What to do

1. Run the local scan on a repository you care about and read the results.
2. Sort by verified findings first.
3. Revoke each verified credential at its issuer, then rotate.
4. Decide, with your team, whether history needs rewriting, and plan the force push.
5. Add an allowlist entry only with a written reason. The docs say allowlist changes are recorded in the audit trail.
6. Turn on blocking in the IDE extension so new leaks stop at the keyboard.
7. Review the Secrets dashboard weekly for leaked and still open items.

Quick check

Sources

• Safeguard docs, secrets scanning (fetched 18 October 2026)
• Safeguard CLI documentation
• Safeguard documentation home

Last reviewed: 18 October 2026.