You can ask the Safeguard web app chat at app.safeguard.sh about leaked secrets in your connected repositories, in plain language, instead of building a query by hand. The order of work matters more than the tool: rotate any exposed credential first, then clean history, then add checks that stop the next leak.
What can the chat do for secrets?
The Safeguard web app is chat first, and the platform can be driven from chat. Secrets scanning is a generally available capability. Safeguard describes it as pattern based detection across many credential issuers plus entropy checks, live verification for some credential types, history purge support, a pre-push hook and custom patterns.
The chat is the front door. You describe what you want to know and it works against what your account can see. I am not describing menus or buttons here, because the useful part is the question you ask and what you do with the answer. What appears depends on which repositories you have connected and how your tenant is configured.
What can you ask?
Questions that tend to work well are specific about scope and ask for a ranked answer.
- Which repositories have findings for exposed credentials, and which of them are still active?
- Show the verified findings first, and tell me which provider each belongs to.
- Where does the same secret appear more than once, including in older commits?
- Which findings are in repositories that are public or widely shared?
- What changed in secret findings since last week?
Ask for the repository, file, commit and date for each, so you can find the person who can rotate it.
What order should you work in?
GitHub's guidance on removing sensitive data from a repository gives the order. For a leaked password, token or credential, revoke or rotate it first. Once revoked it can no longer be used for access, which may solve the problem without rewriting history.
If you still need to rewrite history, GitHub notes side effects: commit hashes change, signatures are removed, open pull request diffs break, and anyone with an older clone can push the secret back. Forks keep the data until their owners remove it, and cached views may keep commits reachable until support clears them. So history cleanup is hygiene. Rotation is the fix.
Why does verification matter?
A pattern match is a guess. A finding the system can confirm as a live credential belongs at the top of the queue. Dead test keys and example strings can wait. Asking the chat to separate verified from unverified findings saves hours.
Try it yourself
Open the full demo at /demos/secrets-scanning.
What to do
- Connect the repositories you want checked, starting with the most shared ones.
- Ask for verified findings first, with provider, file, commit and date.
- Rotate each live credential through its provider, and confirm the old one is rejected.
- Check usage logs at the provider for the exposure window, to see whether the secret was used.
- Decide on history cleanup after rotation, using a documented tool and coordinating with everyone who has a clone.
- Turn on the pre-push check so the next secret is stopped on a developer machine.
- Move secrets to a manager and reference them by name in code and configuration.
- Ask the chat weekly what changed, and assign owners to anything new.
Quick check
Should I clean git history before rotating a leaked key?
No. Rotate or revoke first, as GitHub advises. History rewriting does not reach forks or other clones, so it cannot make an exposed credential safe.
Does the chat replace the pre-push check?
No. The chat helps you find and rank what already exists. The pre-push hook helps stop new secrets before they leave a machine.
Sources
Last reviewed: 18 October 2026.
