secretguard-mcp
This server provides a single tool scan_for_secrets to detect hardcoded secrets in a code string before it is written or committed.
Scan code for secrets: Pass a
codestring and optionalfilename; it scans locally with no network calls, API keys, or external dependencies.Detect many secret types: AWS keys, Stripe, GitHub tokens, Google API keys/OAuth secrets, Slack tokens/webhooks, Shopify, Telegram, DigitalOcean, Hugging Face, Notion, Mailchimp, Postman, Linear, Readme, Clojars, Pulumi, OpenAI, Anthropic, npm, SendGrid, Twilio, Azure Storage account keys, database connection strings with embedded passwords, private key blocks (PEM), JWTs, and generic high-entropy credentials assigned to secret/token/password/key-like variable names.
Return structured, redacted findings: Each finding includes filename, line number, rule ID, description, confidence level (
highorgeneric), and a redacted line—never the raw secret value.Provide a summary indicating whether any secrets were found.
Run securely: All processing is local and in-memory before redaction, over stdio, requiring no API key or network access.
Integrate with AI coding agents: Designed for proactive use by Claude Code, Cursor, Windsurf, etc., to catch secrets before code is written to disk or committed.
Detects hardcoded GitHub tokens (e.g. ghp_, gho_, github_pat_) in code to prevent accidental exposure.
Detects hardcoded Google API keys (e.g. AIza...) in code to prevent accidental exposure.
Detects hardcoded Slack tokens (e.g. xox[baprs]-...) in code to prevent accidental exposure.
Detects hardcoded Stripe live keys (sk_live_, rk_live_) in code to prevent accidental exposure.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@secretguard-mcpScan this code for hardcoded secrets before committing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
secretguard-mcp
An MCP (Model Context Protocol) server that scans a code string for
hardcoded secrets — AWS keys, Stripe keys, GitHub tokens, Google API keys and
OAuth client secrets, Slack tokens and incoming webhook URLs, Shopify access
tokens, Telegram bot tokens, DigitalOcean tokens, Hugging Face tokens,
Notion API tokens, Mailchimp API keys, Postman API tokens, Linear API keys,
Readme API keys, Clojars API tokens, Pulumi API tokens, OpenAI keys, Anthropic keys, npm access tokens, SendGrid keys, Twilio API keys, Azure
Storage account keys, database connection strings with embedded passwords,
private key blocks, JWTs, and generic high-entropy credentials — so an AI coding
agent (Claude Code, Cursor, Windsurf, ...) can catch a
secret before it writes the file or makes the commit, instead of finding
out at CI/PR-review time. It exposes exactly one tool, scan_for_secrets,
runs entirely locally over stdio, needs no API key, and never returns a raw
secret value — every finding comes back redacted.
Why this exists
secret-scan-action
already catches these secrets in CI, on every PR. That's necessary but late
— by the time it runs, the secret has already been written, committed, and
pushed. This project reuses that same detection engine (same rules, same
entropy check, same redaction) but puts it in front of the agent as a tool
call, so the check can happen at generation time, before the secret ever
touches disk or history.
Related MCP server: classifinder-mcp
What it does
On a scan_for_secrets call:
Splits the input
codestring into lines.Runs the same two-tier ruleset
secret-scan-actionuses:Pattern rules (high confidence) — distinctive formats that are near-certain secrets when matched: AWS access key IDs (
AKIA...) and contextual secret keys, Stripe live keys (sk_live_,rk_live_), GitHub tokens (ghp_,gho_,github_pat_, ...), Google API keys (AIza...), Google OAuth client secrets (GOCSPX-...), Slack tokens (xox[baprs]-...), Slack incoming webhook URLs (hooks.slack.com/services/...), Shopify access tokens (shpat_...,shpca_...,shpss_...,shppa_...,shpua_...), Telegram bot tokens (<bot_id>:A..., 35-char secret), DigitalOcean tokens (dop_v1_...,doo_v1_...,dor_v1_..., 64-char hex), Hugging Face tokens (hf_...,api_org_..., 34-char alpha), Notion API tokens (ntn_..., 11 digits + 35 alphanumeric), OpenAI keys (sk-...,sk-proj-...,sk-svcacct-...), Anthropic keys (sk-ant-...), npm access tokens (npm_...), SendGrid keys (SG....), Twilio API keys (SK...), Azure Storage account keys (contextualAccountKey=...), private key blocks (-----BEGIN ... PRIVATE KEY-----), and JWTs. One pattern rule — database connection strings with an embedded password (postgres://,mysql://,mongodb(+srv)://,redis(s)://,amqp(s)://) — is deliberately not near-certain even after excluding known placeholder passwords (user,password,changeit, ...) and${...}-style env-var references, since a real value there could still be a low-stakes tutorial example rather than a live credential; it's returned at generic confidence, same as the entropy rule below. Another pattern rule — Mailchimp API keys (a 32-char hex value followed by a-usNNdatacenter suffix) — is also generic confidence: it only fires when amailchimp-prefixed variable/key name immediately precedes the value, but that keyword gate still doesn't rule out an unrelated hex value that happens to end in the same suffix shape. Postman API tokens (PMAK-..., 24-char hex +-+ 34-char hex), Linear API keys (lin_api_..., 40-char alphanumeric), Readme API keys (rdme_..., 70-char lowercase alphanumeric), Clojars API tokens (CLOJARS_..., case-insensitive, 60-char alphanumeric), and Pulumi API tokens (pul-..., 40-char lowercase hex) are high confidence — a fixed prefix and exact length, same as the other provider-token rules.Generic entropy rule — a value assigned to a variable named like
secret,token,password/credential, or a*keycompound commonly used for real secret material (apiKey,sessionKey,signingKey,clientKey,webhookKey, ...) whose value also has high Shannon entropy (looks random, not like a placeholder or an env-var reference). Deliberately does not match a bare*Key— that would also catchpartitionKey,cacheKey,queryKey, and similar non-secret identifiers common in ordinary code.
Returns every finding's
filename,line,ruleId,description,confidence("high"|"generic"), and a redacted line — the raw secret value never leaves the process. If nothing is found, it returns a plain "No secrets detected." result.
Example output
Calling scan_for_secrets with:
{
"code": "const key = \"AKIAIOSFODNN7EXAMPLE\";\nconst greeting = \"hello\";",
"filename": "src/config.ts"
}returns:
{
"findings": [
{
"filename": "src/config.ts",
"line": 1,
"ruleId": "aws-access-key-id",
"description": "AWS Access Key ID",
"confidence": "high",
"redactedLine": "const key = \"AKIA************MPLE\";"
}
],
"summary": "Found 1 potential secret (1 high-confidence, 0 needs-review).\n\n- [high] src/config.ts:1 — AWS Access Key ID (aws-access-key-id)\n const key = \"AKIA************MPLE\";"
}(The AWS key above is AWS's own public documentation placeholder, not a live
credential.) A clean scan — e.g. { "code": "const greeting = \"hello world\";" } — returns { "findings": [], "summary": "No secrets detected." }.
Setup
Not yet published to the npm registry — install directly from GitHub via
npx. npm install from a git source runs this package's prepare script
automatically, which builds dist/ on the fly, so no separate build step is
needed.
Claude Code
Add to your project's .mcp.json (or run claude mcp add):
{
"mcpServers": {
"secretguard": {
"command": "npx",
"args": ["-y", "github:vladimirbakalov/secretguard-mcp"]
}
}
}Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"secretguard": {
"command": "npx",
"args": ["-y", "github:vladimirbakalov/secretguard-mcp"]
}
}
}No API key, no account, no config options — restart Claude Code / Claude
Desktop and scan_for_secrets is available. The tool description tells the
agent to call it before writing code that could contain a credential, and
again before a commit or PR — most of the time you won't need to ask for it
explicitly.
Cursor / Windsurf
Both read the same command/args shape from their own MCP settings UI or
config file — point them at npx -y github:vladimirbakalov/secretguard-mcp
the same way.
Once this package is published to npm, the args above can drop to
["-y", "secretguard-mcp"] instead — that's a follow-up, not a blocker.
One-click install (.mcpb)
A prebuilt MCP Bundle is
attached to the
v0.1.4-mcpb release —
download secretguard-mcp-0.1.4.mcpb and open it in Claude Desktop (or any
other MCPB-compatible client) for a one-click local install, no npx/Node
setup required on the client side. Rebuild it yourself with
npm run package:mcpb (see scripts/build-mcpb.sh).
This same .mcpb release asset is what server.json at the repo root points
at for the official MCP Registry —
secretguard-mcp is published and listed there as
io.github.vladimirbakalov/secretguard-mcp,
so MCP clients that browse the official registry can discover and install it
directly, in addition to the npx/.mcpb paths above. Publishing runs
unattended in CI (.github/workflows/publish-mcp.yml) via mcp-publisher login github-oidc on every v*-mcpb tag push — no interactive login step.
Security notes
The raw secret value matched by a rule is held in memory only for the duration of a single
scan_for_secretscall and is redacted (redactLine/redactSecret) before the tool result is built — it never appears in the returnedcontent,structuredContent, or any log line.The server does no network calls of any kind. It reads stdin, writes stdout (MCP stdio transport), and does nothing else.
Generic-tier findings are ambiguous by nature (config placeholders, hashes, and UUIDs can trip the entropy check) — that's expected. Treat
confidence: "generic"as "worth a second look," not "confirmed."
Development
npm install
npm run typecheck # tsc --noEmit
npm test # vitest run
npm run build # tsc -p tsconfig.build.json -> dist/dist/ is not committed — it's built from src/ via the prepare script,
which runs both on a git-based npx/npm install and before any future
npm publish.
Scope (v1)
One tool, one job: scan a code string, return redacted findings. No allowlist file, no AI triage step, no config options, no persistent state. If this needs any of that later, it'll get added once real usage shows it's needed — not before.
Relationship to secret-scan-action
secretguard-mcp and
secret-scan-action
share the same detection engine (rules.ts, redact.ts, and the core of
scan.ts) but are independent, separately distributed packages: one is a
GitHub Action that scans PR diffs in CI, the other is an MCP server that
scans arbitrary code strings locally, before a commit exists. Fixing a
false positive/negative in the ruleset means updating both.
License
MIT.
Available Tools
1 toolscan_for_secretsScan for secretsARead-only
Scans a code string for hardcoded secrets (AWS keys, Stripe keys, GitHub tokens, Google API keys, Slack tokens, private key blocks, JWTs, and generic high-entropy credentials assigned to secret/token/password/key-like variable names) BEFORE that code is written to a file or committed. Call this proactively whenever you are about to write, edit, or commit code that could plausibly contain a credential — config files, env handling, API client setup, tests with fixture values, or any snippet you're not 100% sure is clean — and again right before creating a commit or PR. Every reported line is redacted; the raw secret value is never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to scan, as plain text (one file's contents, or any snippet). | |
| filename | No | Optional filename to attribute findings to (for display only). Defaults to "input". |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| findings | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description reveals a critical behavioral trait: 'Every reported line is redacted; the raw secret value is never returned.' This is exactly the kind of context that helps an agent trust the tool and understand its constraints during use. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first the core action and scope, then explicit use cases, then a security-relevant behavioral note. It is one long paragraph but every sentence earns its place, containing no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need to explain return values. It fully covers what the tool does, when to invoke it, and a key behavioral guarantee (redaction). The annotations and schema complement the description to make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already thoroughly describes both parameters. The description adds no new param-level semantics, though it does reinforce the purpose of 'filename' as display-only in the narrative. Baseline is 3 due to high schema coverage; description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Scans') and a detailed resource: a code string for hardcoded secrets, enumerating many secret types (AWS keys, Stripe keys, GitHub tokens, etc.). This goes far beyond a vague purpose and leaves no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Call this proactively whenever you are about to write, edit, or commit code that could plausibly contain a credential' and 'again right before creating a commit or PR.' Specific scenarios (config files, env handling, API client setup, tests) are listed. It also implies using it as a safety net for uncertain code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Only one tool exists, so there is no possibility of confusion between tools. The purpose is unambiguous.
The tool name 'scan_for_secrets' follows a clear verb_noun pattern, consistent with common MCP naming conventions. With a single tool, there is no inconsistency.
A single tool is minimal for a focused secret-scanner server, but feels thin compared to typical MCP servers that offer a broader range of operations. The count is borderline.
The tool covers the core functionality of scanning for secrets in code snippets, and no obvious additional operations are needed for this narrow domain. The tool description explicitly addresses proactive scanning before commits, making it self-contained.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Deterministic trust gate for AI output: leaked-secret, prompt-injection & PII in one call.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceScans code for exposed secrets, API keys, tokens, and credentials across 69 patterns covering cloud services, AI platforms, payment providers, authentication services, and databases.MIT

classifinder-mcpofficial
AlicenseAqualityBmaintenanceEnables AI agents to scan text for leaked secrets and prompt injection markers, and redact them before reaching an LLM.21MIT- AlicenseNot gradedqualityAmaintenanceScans text and files for common secrets (AWS, GitHub, etc.) and redacts them to prevent credential leakage in AI-assisted development. Runs entirely locally with no telemetry.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to scan source code for secrets like API keys and passwords locally without network requests.2Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vladimirbakalov/secretguard-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server