Comparison
How does Agent Blast Radius compare to gitleaks, TruffleHog and GitGuardian?
Gitleaks, TruffleHog, ggshield and detect-secrets scan git history, repositories and CI pipelines for hardcoded secrets in code. Agent Blast Radius scans something different: the local machine an AI agent is about to run on — credential files, MCP configs, shell history counts — not your codebase. They answer different questions and are complementary: run a code scanner in CI, and a machine scan before letting an agent loose.
Updated · Kloudle
What do gitleaks, TruffleHog, ggshield and detect-secrets actually scan?
Gitleaks describes itself as "a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it via stdin"; it scans patches from git log -p plus files and directories, using regex and entropy patterns.
TruffleHog's open-source CLI covers a wider surface: git repos, S3 buckets, GCS, Docker images, Jenkins, CircleCI, TravisCI, filesystems and more, classifying over 800 secret types (its separate enterprise product adds continuous monitoring of Slack, Jira, Confluence and similar SaaS tools). ggshield, GitGuardian's CLI, scans local files, repositories, CI pipelines and Docker images, calling GitGuardian's API to do the detection. detect-secrets takes a different approach: it builds a baseline file of currently known secrets and then diffs new commits against it, typically wired in as a pre-commit hook so new hardcoded secrets are blocked before they're committed.
What does Agent Blast Radius scan instead?
Blast doesn't look at your source code for hardcoded secrets in general. It scans the local machine an AI agent would run on: AWS/GCP/Azure credential files and caches, kubeconfig and Docker auth files, developer-tool configs (GitHub CLI, npm, SSH, Terraform, Vercel and others), MCP configuration files, process environment variables, and project files under common code directories for things like .env and private key headers. It also counts — never reads — secret-bearing shell history lines. The scan is local, offline and read-only.
How does live verification differ between these tools and blast's paid verify?
TruffleHog's documentation states that "for every secret TruffleHog can classify, it can also log in to confirm if that secret is live or not" — for example, its AWS detector performs a GetCallerIdentity call directly against AWS to check a credential, rather than sending the secret to a third party for checking. detect-secrets also supports optional verification that "increases scanning precision" through network calls, which can be disabled.
Agent Blast Radius's optional paid blast verify only covers two classes: AWS credential profiles (via a local aws sts get-caller-identity call) and OpenAI/Anthropic API keys found in the environment (a local model-list call). It doesn't attempt to verify GitHub, npm, GCP, Azure or other credential types. The abr.kloudle.dev service that coordinates payment for each check receives only a class count, such as aws-sts-identity:2 — never the credential value, profile name, or any other scan output.
What's the privacy model for each tool?
Gitleaks and detect-secrets run entirely locally with no network calls required for basic detection. ggshield is built around GitGuardian's cloud API: per its docs, "your files and secrets won't be stored" during a scan, and only metadata such as call time and request size is retained. TruffleHog's verification calls go to the credential's own provider, not to TruffleHog's servers, for the open-source CLI's basic scan-and-verify flow.
Agent Blast Radius's base scan is local and offline by design; nothing leaves the machine. The only exception is the paid verify add-on, which sends class counts to the service to coordinate the x402 payment, and nothing else.
Which should I use, and when?
These tools aren't substitutes for each other because they look at different places. Use a code-focused scanner (gitleaks, TruffleHog, ggshield, or detect-secrets) in CI and pre-commit to stop secrets from entering your repositories. Use Agent Blast Radius before pointing an AI coding agent at your workstation, since a clean repository doesn't mean a clean machine — credentials can sit in config files, caches and shell history that none of those code scanners ever look at.
| Tool | Primary scan surface | Live verification | Where it runs |
|---|---|---|---|
| gitleaks | Git history, repos, files, stdin | No — pattern and entropy matching only | Fully local |
| TruffleHog | Git repos, S3, GCS, Docker, CI and more (OSS CLI); Slack/Jira/etc. in its enterprise product | Yes — calls the credential's own provider API from wherever it runs | Runs locally or in CI |
| ggshield (GitGuardian) | Local files, repos, CI, Docker images | Not documented for the CLI's scan-and-report flow | Calls GitGuardian's cloud API per scan |
| detect-secrets | Staged and tracked files vs. a baseline | Optional, can be disabled | Fully local |
| Agent Blast Radius | The local machine an agent can reach: credential files, MCP configs, shell history counts | Paid add-on: AWS profiles and OpenAI/Anthropic keys only, local checks | Fully local; paid verify sends only class counts |
Check your own machine
See what an agent running as you can reach. Offline, read-only, never prints values:
npx -y @kloudle/agent-blast-radius@0.3.0Inside your agent: install guides for Claude Code, Codex, Cursor, Claude Desktop and more. Which keys are live? npx -y @kloudle/agent-blast-radius@0.3.0 verify (paid per check).
Frequently asked
Should I replace gitleaks or TruffleHog with Agent Blast Radius?
No. They check different things — gitleaks and TruffleHog look for secrets inside your code and its history; blast looks at the machine an agent would run on. Running both covers more ground than either alone.
Does TruffleHog's verification send my secret to TruffleHog's servers?
Per TruffleHog's documentation, verification works by calling the credential's own provider API (for example AWS's GetCallerIdentity) from wherever the scan runs, rather than sending the secret value to a third party for checking.
Does ggshield store the secrets it finds?
No. GitGuardian's documentation states that ggshield does not store your files or secrets when scanning; it retains only metadata such as call time and request size.
Can I use blast and a code scanner together?
Yes, and that's the intended use: run gitleaks, TruffleHog, ggshield or detect-secrets against your repositories and CI, and run blast against the machine where an agent is about to operate.
Sources
- gitleaks — GitHub
- trufflehog — GitHub
- ggshield getting started — GitGuardian
- detect-secrets — GitHub