Finding leaked secrets with Safeguard and Claude: what works today

To find leaked secrets with Safeguard, scan locally with the CLI and review results in the Secrets dashboard. Safeguard's MCP docs do not name a secrets tool, so do not expect Claude to run a scan on its own. Use Claude, through the MCP connector, to ask about findings your workspace already holds.

What does Safeguard's secrets scanning cover?

According to its documentation, it scans source code (current HEAD and Git history), container image layers, packaged artifacts, CI build logs, vendor SBOMs and model weights. Detection works in three layers: issuer-specific patterns for more than 200 providers such as AWS, GitHub, Slack, Stripe and OpenAI; generic patterns for private keys, JWTs, bearer tokens, OAuth refresh tokens and connection strings; and entropy checks for high-entropy strings, with classification to reduce noise from hashes and UUIDs.

For issuer-specific patterns it can make a low-privilege call to the issuer, such as sts:GetCallerIdentity for AWS, to check whether the credential is live. Unconfirmed ones are marked "unverified." Verification can be switched off per issuer, which matters in air-gapped setups.

Severity follows verification: critical for a verified high-privilege credential, high for a verified lower-privilege one, medium for an unverified match for a known issuer, and low for generic or entropy findings.

Open the secrets scanning demo

How do you run it locally?

The documented local command is safeguard detect --detect secrets. The CLI installs from https://cli.safeguard.sh, and the local runner keeps source on your machine and uploads only SBOM and findings files.

Two documented gaps: there is no CLI command yet to install a Git hook, although the IDE extension blocks pushes of secrets, and there is no CLI command to list, revoke or rotate findings. Do those in the Secrets dashboard.

Where does Claude fit?

Safeguard's hosted MCP server connects to Claude at https://mcp.safeguard.sh/mcp/anthropic, with OAuth sign in. A new workspace starts with six read-only tools: list products, list projects, get a project, list vulnerabilities, get one vulnerability and list findings. The gating page says safeguard_list_findings covers findings in an SBOM or project, and that no secrets tool is named. Whether secrets findings appear through that tool is not stated, so test it in your own workspace before relying on it.

Administrators can turn on more tools under Feature Flags, and the page suggests searching by keyword such as "secrets." That is the way to find out what exists in your tenant.

So today the honest split is:

• Detect: the CLI, the local runner, the IDE extension and the platform scans.
• Triage and fix: the Secrets dashboard, where revocation and rotation live.
• Ask questions: Claude over MCP, within the tools your admin enabled.

What should you do when a secret is found?

The docs describe a remediation playbook for verified findings: revoke the credential through the issuer's API, rotate it through a secret manager or a pull request, optionally rewrite Git history, and notify owners, with each step able to require approval. Whatever tool you use, the order matters. Revoke first. Rewriting history without revoking leaves a live credential in every clone.

Allowlisting exists for known false positives at three scopes: inline comments, path globs in .safeguard/secrets-allow.yaml, and issuer-based rules. Allowlist changes are recorded in the audit trail.

What to do

1. Install the CLI and run safeguard detect --detect secrets on one repository.
2. Treat any verified finding as an incident: revoke, then rotate.
3. Review unverified findings and allowlist only with a recorded reason.
4. Connect Claude over MCP and ask what it can see for your projects.
5. Ask your admin to search Feature Flags for secrets tools.

Quick check

Sources

• Safeguard docs, Secrets scanning
• Safeguard docs, MCP server
• Safeguard docs, Tool availability and gating
• Safeguard docs, Local runner

Last reviewed: 18 October 2026.