Best tools for testing secret leakage in MCP servers

Quick answer

If I had to pick one tool for testing secret leakage in MCP servers, I would start with Promptfoo. It is the strongest default because it can attack the MCP workflow at runtime, check for system prompt leakage, probe unauthorized tool behavior, and test data exfiltration paths instead of only scanning source files. For most teams, though, one tool is not enough. The practical stack is Promptfoo for adversarial runtime testing, Agent Scan for local MCP inventory and poisoned server discovery, GitHub secret scanning for changed-code tripwires, TruffleHog for broad secret hunting across repos and filesystems, and MCP Inspector when you need hard proof of where the leak actually happened.

That layered answer is less tidy than naming a single winner. It is still the honest one. Secret leakage in MCP servers can happen through tool descriptions, tool return values, prompt templates, local startup commands, over-scoped tokens, or ordinary code/config mistakes. One scanner will not cover all of that.

If you want the short visual version first, this cover map lines up with the comparison table below.

What counts as secret leakage in MCP servers?

MCP changes the shape of secret leakage. In a normal app, you mostly worry about secrets committed to code, leaked in logs, or returned by an API that forgot to redact. In an MCP setup, the model becomes part of the leakage path.

That matters because the model can read more than the end user sees. It can read tool descriptions, prompt templates, fetched resources, and tool return values. If one of those surfaces carries a credential, or carries instructions that coerce the model into revealing a credential, you have a leak even if the original code path looked harmless.

The OWASP MCP Security Cheat Sheet is pretty blunt here. It calls out tool poisoning, shadowing, data exfiltration through legitimate channels, over-scoped tokens, and local-server sandbox escape as first-class MCP risks. The official MCP security best practices make the auth side just as clear. Token passthrough is explicitly forbidden because it weakens control boundaries and makes auditing much harder. If a stolen token can flow through the server as a proxy, "secret leakage" is no longer a narrow content problem. It becomes an action problem.

So when I say "test secret leakage in MCP servers," I mean at least five different things:

• secrets accidentally committed in MCP server code or config
• secrets exposed in tool output, logs, traces, or prompt templates
• secrets extracted by prompt injection or tool metadata poisoning
• secrets forwarded through over-scoped auth flows or token passthrough
• secrets moved out through normal-looking actions, like search queries, emails, tickets, or file writes

That wider definition changes which tools matter.

The best tools for testing secret leakage in MCP servers compared

| Tool | Best fit | What it proves well | Main weakness | | --- | --- | --- | --- | | Promptfoo | Best overall starting point | Runtime secret leakage, MCP-specific attacks, exfiltration paths, prompt and tool-output abuse | Not a repo-history scanner | | Agent Scan | Best for local MCP hygiene | Inventory, prompt injection, tool poisoning, toxic flows, risky local server configs | Scans can execute stdio server commands | | GitHub MCP secret scanning | Best pre-commit guardrail | Changed-file secret detection in live coding workflows | Findings are ephemeral and not a system of record | | TruffleHog | Best broad secret hunting | Repo history, filesystem, binary, archive, and verification-oriented secret scans | Not MCP-aware at the protocol layer | | MCP Inspector | Best for proof and triage | Tool schemas, prompt templates, resources, raw execution results, message flow | Not an adversarial harness by itself |

If you only have time for two tools, I would pick Promptfoo and TruffleHog. That pair gives you runtime abuse testing plus broad secret discovery. If your main risk is developer laptops full of local servers, swap TruffleHog for Agent Scan. If your main risk is CI and pre-commit drift, add GitHub secret scanning early.

Why Promptfoo is the best default for runtime leakage tests

Promptfoo gets the top spot because it starts where MCP leaks usually become real: during execution.

Its MCP plugin is built for MCP-specific attacks such as hidden function discovery, parameter injection, function output manipulation, system information leakage, and unauthorized tool invocation. The broader MCP security testing guide also shows a more realistic pattern for agent testing, where the agent actually calls MCP tools and processes their return values. That last part is important. Secret leakage in MCP setups often happens after the tool call, not before it.

Promptfoo is also one of the few tools in this space that makes exfiltration a first-class test objective instead of an afterthought. Its data exfiltration plugin is built to check whether the target can be tricked into sending sensitive data out through a reachable channel. Its PII plugin helps catch cross-session or direct exposure of sensitive values. For MCP systems, that means you can test questions like:

• Can a poisoned tool response make the agent send an API key to a web endpoint?
• Can a hidden prompt inside a resource trick the model into dumping system instructions?
• Can the agent leak another user's data or prior session details?
• Can a tool call return secrets that later get reflected back to the user?

That is why Promptfoo is better than a plain repo scanner for this specific article topic. Secret leakage in MCP servers is often not "secret exists in file." It is "secret crossed a boundary during tool use."

I would start with Promptfoo when:

1. The MCP workflow already runs in a stable dev or staging environment.
2. You want evidence that a leak can actually happen through the model-plus-tool path.
3. You need repeatable security tests that engineering can keep.
4. You care about action-level leakage, not just file-level exposure.

If you are already working on related attack paths, Best tools for testing prompt injection in MCP servers is the closest companion read.

Agent Scan is the best tool for local MCP inventory and poisoned-server discovery

Local MCP servers are messy. They accumulate fast, they run with real user privileges, and teams forget they are there.

That is why I like Agent Scan so much in this category. The Snyk project does not try to pretend every MCP risk is a model-eval problem. It starts with the machine. The repo says it auto-discovers MCP configurations and scans them for risks such as prompt injection, tool poisoning, tool shadowing, toxic flows, and credential handling issues.

For secret leakage, that matters in two ways.

First, it helps you find the MCP components that could leak secrets in the first place. A team cannot defend what it has not inventoried. If one engineer has a community filesystem server, another has a custom Slack bridge, and a third has a local GitHub helper that nobody reviewed, your leakage surface is already wider than your diagrams suggest.

Second, Agent Scan forces an uncomfortable but useful truth into the open: scanning MCP configs can itself execute commands. The repo warns that scanning stdio configurations starts the servers defined in those configs. That is not a side note. It is part of the threat model. If you are evaluating untrusted servers, the scan belongs in a disposable environment or sandbox.

I would use Agent Scan when:

• you need a real inventory of installed MCP servers
• local developer machines are part of the trust boundary
• you want to catch poisoned descriptions or shadowed tools early
• you suspect the problem is uncontrolled MCP sprawl rather than one specific app bug

This is also the tool I would add first if your organization is still early with MCP adoption. Runtime tests help later. Inventory discipline helps immediately.

GitHub MCP secret scanning is a useful pre-commit tripwire, not the whole answer

GitHub's new secret scanning flow through the GitHub MCP server is worth using, but only if you understand the boundary.

The upside is obvious. You can ask an MCP-compatible agent to scan recent changes for exposed secrets before you commit. GitHub documents the exact setup: enable the secret_protection toolset, expose run_secret_scanning, and use prompts like "Scan my current changes for exposed secrets and show me the files and lines I should update before I commit."

That is genuinely useful for MCP-heavy teams because MCP servers often get configured in a hurry. Headers, tokens, OAuth settings, local command args, and quick test fixtures are exactly the kinds of places where a credential sneaks into a diff.

The downside is just as important. GitHub says those findings are ephemeral. They show up in the current agent session and are not persisted as normal secret-scanning alerts. So this tool is a tripwire, not a source of record.

I would use GitHub MCP secret scanning for:

• scanning staged or recent changes before merge
• catching obvious credential leaks in code review loops
• helping agent-driven workflows stop before they commit something bad

I would not use it as the only evidence that your MCP server is safe. It does not test runtime exfiltration, poisoned tool output, or cross-server leakage behavior.

TruffleHog is still one of the best wide-net scanners for MCP server code and config

TruffleHog is not MCP-specific, and that is fine. It earns its place because it is good at the part many MCP-focused articles skip: broad secret hunting across the real places teams stash things.

The TruffleHog docs show support for scanning Git, local filesystems, archives, binaries, and other sources. They also stress verification. In practice, that makes TruffleHog a strong fit for MCP server estates because those estates tend to spread secrets across more than one surface:

• server source repos
• .env files in dev folders
• JSON config files for clients and servers
• shell history snippets copied into docs
• build artifacts or archived examples

That coverage is useful when you are trying to answer a simple question honestly: where could a credential already be sitting before the model ever touches it?

I would use TruffleHog when:

• you want to scan repo history, not just the current diff
• you need filesystem-level secret discovery on build hosts or dev machines
• you care about verified secrets rather than regex-only hits
• you are cleaning up an existing MCP environment, not just protecting a new one

If your use case is mostly "keep secrets out of Git," Gitleaks is still a valid option. I lean toward TruffleHog here because it gives you a wider hunting surface, which fits MCP environments better.

MCP Inspector is how you prove a leak instead of guessing

When a runtime test fails, the next problem is almost always attribution. Was the leak in the prompt template? In the tool description? In the resource payload? In the raw tool response? In the client's own assembly logic?

That is where MCP Inspector becomes more valuable than it looks.

Inspector lets you inspect tool schemas and descriptions, prompt templates and arguments, resource metadata, raw execution results, and message logs. For secret leakage triage, that is exactly what you need. It turns a vague suspicion into a traceable path.

I would use Inspector for three specific jobs:

1. Confirm whether the secret was already present in the server's exposed data surface.
2. Check whether tool metadata or prompt assembly widened the leak path.
3. Preserve evidence for a real fix, not a cosmetic patch.

This is also where the MCP security best practices matter again. If token passthrough is forbidden and yet a secret is moving through the server like a dumb pipe, Inspector gives you the fastest way to confirm the implementation boundary that broke.

If your next step is reporting and retest discipline, pair this with AI pentest report template for MCP servers. Evidence quality matters more than a dramatic finding title.

How I would build a practical secret-leakage testing stack for MCP

Most teams do not need ten tools. They need a stack that matches their actual failure modes.

Here is the practical version:

• Promptfoo for adversarial runtime testing. Use it to prove whether secrets can be extracted or exfiltrated through the agent workflow.
• Agent Scan for local MCP inventory and poisoned-server hygiene. Use it to understand what is actually installed and which servers deserve isolation.
• GitHub MCP secret scanning for changed-code tripwires. Use it before commits and pull requests.
• TruffleHog for broad discovery in repos, filesystems, and older history.
• MCP Inspector for proof, triage, and replayable evidence.

If you are buying or building a broader AI pentest workflow around this, the next internal reads are what MCP is, the vendor evaluation guide for MCP servers, the wider blog library, and the main product routes at download and compare.

One last point. Secret leakage testing is not complete just because a scanner found no keys in the repo. In MCP systems, the harder question is whether a secret that exists somewhere legitimate can be pulled across the wrong boundary by a model, a tool, or a poisoned server. That is the question your tooling stack should answer.

FAQ

What is the best tool for testing secret leakage in MCP servers?

For most teams, Promptfoo is the best first tool because it can test actual runtime leakage and exfiltration paths in MCP workflows rather than only searching files for hardcoded credentials.

Is secret scanning enough for MCP security?

No. Secret scanning helps with committed or stored credentials, but MCP secret leakage can also happen through tool return values, prompt templates, over-scoped auth, poisoned metadata, and model-mediated exfiltration.

When should I use Agent Scan instead of Promptfoo?

Use Agent Scan when the bigger problem is local MCP sprawl, unreviewed server installs, or poisoned server metadata. Use Promptfoo when you need adversarial proof that a running workflow can leak secrets.

What is the downside of GitHub MCP secret scanning?

It is good for pre-commit checks, but GitHub says the findings are session-only and do not persist as ordinary alerts. Treat it as a guardrail, not your long-term record.

Why keep TruffleHog in the stack if it is not MCP-specific?

Because many MCP leaks start with ordinary secret hygiene failures in repos, configs, archives, or local filesystems. A good wide-net scanner still pays for itself.

Bottom line

If I had to name one winner, I would name Promptfoo.

If I were building the real stack for an MCP-heavy team, I would run Promptfoo for runtime abuse testing, Agent Scan for local-server visibility, GitHub MCP secret scanning for short-loop code checks, TruffleHog for broad secret discovery, and MCP Inspector for proof. That mix covers the two questions that matter most: where your secrets already are, and whether an MCP workflow can move them somewhere they should never go.