A new security audit has found that roughly one in eight credential slots inside publicly posted Model Context Protocol (MCP) configuration files on GitHub contain a hardcoded secret, and nearly a quarter of those secrets never expire and carry broad access rights. The research, published by Hush Security on October 8, 2026, scanned approximately 82,000 public MCP files spanning more than a dozen coding-agent ecosystems, and it lands just weeks after separate studies from GitGuardian and Flare quantified the same problem from different angles. Together, the three reports describe a credential-exposure surface that barely existed two years ago and now sits at the center of enterprise AI agent deployments.
The timing matters. MCP, the open protocol Anthropic introduced to let AI agents call out to databases, cloud accounts, ticketing systems, and internal tools, has become the default wiring standard for agentic coding assistants in 2026. That popularity is exactly why its configuration files are now a target: each one effectively maps an organization’s internal attack surface, and a growing share of those maps come bundled with the keys needed to walk straight through it.
What Hush Security Found in 82,000 Public MCP Files
Hush Security’s analysis, first reported by TechTarget on October 8, 2026, examined roughly 82,000 MCP configuration files that developers had pushed to public GitHub repositories. These files tell an AI coding agent which external tools it can reach — a Postgres database, a Slack workspace, an AWS account, a Jira board — and how to authenticate against each one. Hush measured what it called credential slots: fields in the configuration meant to hold an API key, token, or password.
Twelve percent of those slots contained a hardcoded credential literal rather than a reference to an environment variable or a secrets manager. That is the one-in-eight figure driving most of the coverage this week. The more alarming number sits one layer deeper: of the credentials that were hardcoded, 24% were both non-expiring and broad in scope, meaning an attacker who finds one doesn’t just get temporary access to a single service, they get standing access to whatever that credential can touch, indefinitely, until someone notices and manually revokes it.
The exposed material spanned Anthropic API keys, OpenAI API keys, generic cloud API keys, plaintext passwords, OAuth access tokens, and credentials tied to database systems and internal enterprise workspaces. Hush’s researchers covered files tied to more than a dozen distinct coding-agent tools, suggesting the problem isn’t confined to one vendor’s ecosystem — it’s a pattern that follows the MCP format itself wherever developers adopt it.
Why Model Context Protocol Became AI’s Credential Weak Point
Model Context Protocol is an open specification, originally released by Anthropic, for connecting large language models to external tools and data sources in a standardized way. Instead of every AI vendor building bespoke integrations for every database or API, MCP gives agents a common interface: a server exposes a set of callable tools, and the agent’s host application (an editor, a chat client, an autonomous coding tool) connects to it over a defined protocol.
That standardization is precisely what made MCP spread so fast through coding assistants like Cursor, Claude Code, GitHub Copilot, and dozens of smaller agent frameworks in 2026. It’s also what turned MCP configuration files into a single, predictable place to look for secrets. A traditional secret leak might expose one API key buried in a commit history. An MCP configuration file, by design, lists every tool an agent can reach in one place — and if the credentials for those tools are hardcoded rather than templated, the file becomes a ready-made directory of an organization’s internal access points.
Below is a simplified, non-sensitive illustration of the pattern researchers describe — an MCP client configuration where a credential has been pasted directly into the file instead of referenced through an environment variable or vault lookup:
{
"mcpServers": {
"internal-database": {
"command": "npx",
"args": ["-y", "@example/mcp-postgres"],
"env": {
"DATABASE_URL": "postgres://admin:REDACTED_PLAINTEXT@db.internal:5432/prod"
}
}
}
}Security teams generally recommend replacing the literal value with a reference the runtime resolves from a vault or environment store at launch time, so the file itself never carries a usable secret even if it ends up in a public repository.
Inside the Numbers: Non-Expiring and Broad-Scope Secrets
The detail that separates this research from a routine secret-scanning report is the combination of two risk factors in the same credential. A token that expires in an hour is a nuisance if leaked; a token that never expires and can reach multiple services is a standing liability. Hush’s finding that 24% of hardcoded MCP credentials carry both properties means that out of every 100 hardcoded secrets its scanners found, roughly 24 would still work for an attacker months or years after the file was first indexed by a search engine or scraped by a bot.
This is a different failure mode from the classic leaked-AWS-key story that security teams have dealt with since the early 2010s. Cloud providers built automated detection for exposed cloud credentials years ago; GitHub and AWS both run scanners that can revoke an obviously exposed AWS key within minutes. MCP configuration files are newer, more varied in format, and not yet uniformly covered by those automated revocation systems, which is part of why the exposure window runs so much longer.
GitGuardian’s Parallel Findings: 24,008 Secrets, 2,117 Valid
Hush Security’s report didn’t arrive in isolation. GitGuardian’s State of Secrets Sprawl 2026 report, covering the same underlying trend from a different dataset, identified 24,008 unique secrets specifically inside public MCP-related configuration files on GitHub. Of those, GitGuardian confirmed 2,117 as valid, meaning they successfully authenticated against a live service when tested.
GitGuardian’s broader 2026 dataset also found that secrets tied to AI services grew 81.5% year over year, making AI-service credentials the fastest-growing category of leaked secrets the company tracks across the entire GitHub public corpus. The firm separately found a 3.2% leak rate in commits assisted by Claude Code specifically, a data point that ties the credential-sprawl problem directly to the growth of AI-assisted coding workflows rather than treating it as a generic DevOps hygiene issue.
Flare’s October Audit Adds a Third Data Point
A third report, published by threat-intelligence firm Flare on October 7, 2026, examined a smaller, deduplicated corpus and arrived at a more conservative but still significant count: 2,327 MCP-configuration records, 12,446 unique records after broader deduplication and filtering, and 438 distinct credentials — reduced to 218 once Flare excluded one large concentrated harvesting operation from its totals. Of that set, 96 records contained a live, extractable secret.
Flare framed the risk in terms of what an MCP file reveals even when the secret value itself has been externalized correctly. An MCP configuration still lists the environment variable names an agent expects, such as a database URL or an API token, and that naming convention alone maps out which services an organization connects its AI agents to. In other words, even clean MCP files that avoid hardcoded secrets still leak a blueprint of an organization’s tool chain to anyone who can read the file.
Each of these three datasets uses a different sampling method and a different definition of secret, record, and credential, so the raw numbers should not be added together. What they agree on is the direction: MCP configuration files are a measurable, growing, and currently under-defended source of credential exposure.
Three Studies, One Problem: How the Numbers Compare
| Research Firm | Publication Date | Dataset Analyzed | Key Exposure Figure | Risk Detail |
|---|---|---|---|---|
| Hush Security | Oct. 8, 2026 | ~82,000 public MCP configuration files, 12+ agent ecosystems | 12% of credential slots hardcoded | 24% of hardcoded secrets non-expiring and broad-scope |
| GitGuardian | State of Secrets Sprawl 2026 | Public MCP-related configuration files on GitHub | 24,008 unique secrets found | 2,117 confirmed valid; AI-service secrets up 81.5% YoY |
| Flare | Oct. 7, 2026 | 2,327 MCP-configuration records; 12,446 deduplicated records | 438 distinct credentials (218 excluding one harvesting cluster) | 96 records held a live, extractable secret |
Which Credentials Were Exposed: Anthropic, OpenAI, and Beyond
Hush’s researchers specifically called out Anthropic API keys and OpenAI API keys among the hardcoded secrets they recovered from public repositories, alongside generic cloud API keys, plaintext passwords, OAuth access tokens, and credentials granting access to internal databases and enterprise workspaces. That mix matters because an exposed Anthropic or OpenAI key doesn’t just expose a chat interface — it can rack up usage charges on a company’s AI budget, and if the key is scoped broadly enough, it can expose whatever data the organization has fed into that provider’s API through retrieval or fine-tuning pipelines.
Database and workspace credentials carry a more direct risk. An exposed Postgres connection string or an internal Slack or Jira token found inside a public MCP file can give an outside party read or write access to production data without needing to find any other vulnerability first. Because MCP configuration files are typically created by individual developers configuring their own coding assistant, rather than reviewed through the same change-control process as application code, they tend to slip past the security reviews that would normally catch a hardcoded secret in a pull request.
How an Exposed MCP File Becomes an Attack Path
The attack chain researchers describe is straightforward once a file is public. An attacker, or an automated scraper, since this kind of searching is easy to script, pulls MCP configuration files from GitHub using pattern matching on known filenames and directory structures. Any hardcoded credential is tested against its corresponding service. If valid, the attacker now has whatever access that credential was scoped to grant, and per Hush’s data, there’s close to a one-in-four chance that access doesn’t expire on its own.
Flare’s point about tool topology adds a second stage even when the secret itself is missing. A clean MCP file that references, say, a STRIPE_SECRET_KEY or an INTERNAL_CRM_TOKEN environment variable without exposing the value still tells an attacker which systems the organization has wired its AI agents into. That narrows reconnaissance considerably: instead of guessing what an organization runs, an attacker can read the agent’s own configuration to find out, then target credential theft or phishing specifically at the people and systems named in that file.
The LLM-Jacking Connection: Stolen AI Compute as a Business
The MCP credential problem overlaps with a related trend that CERT-EU flagged in its September 2026 Cyber Brief, published October 2, 2026: LLM-jacking. Google’s Threat Intelligence Group reported a rise in criminal activity where attackers steal or resell access to premium AI tools and hijack cloud servers to run unauthorized AI workloads on someone else’s bill. A hardcoded, non-expiring OpenAI or Anthropic key pulled from a public MCP file is exactly the raw material that kind of operation needs — it converts a credential leak directly into resellable AI compute access, giving leaked AI keys a cash value on top of whatever direct access they grant.
That dual value, direct system access plus resellable AI usage, is part of why AI-service secrets have become the fastest-growing leaked-secret category GitGuardian tracks. A stolen database password only helps an attacker who wants that specific database. A stolen AI API key helps anyone who wants cheap AI compute, which is a much larger buyer pool.
Anthropic, GitHub, and the Silence Problem
Neither Anthropic, the creator of MCP, nor GitHub, the platform hosting the exposed files, has issued a public statement specifically addressing the Hush Security findings as of this writing. That silence is notable given that Anthropic’s own API keys appeared among the exposed credentials in Hush’s dataset. GitHub already runs automated secret-scanning for well-known credential formats like AWS and Stripe keys, and it’s not yet clear whether that scanning has been extended to catch the variety of MCP-specific credential patterns researchers are now finding by hand.
Separately, MCP has already drawn at least two CVE-tracked vulnerabilities this cycle: CVE-2025-59536 and CVE-2026-21852, both tied to Check Point Research’s work on Claude Code project files, involving a consent-bypass issue and credential exfiltration through the ANTHROPIC_BASE_URL setting. A separate MCP flaw, tracked as CVE-2026-59822 in LiteLLM, was added to CISA’s Known Exploited Vulnerabilities catalog earlier this year, underlining how quickly MCP-adjacent flaws have moved from disclosure to active exploitation. Those CVEs addressed a different mechanism, a flaw in how Claude Code handled project configuration, rather than the credential-sprawl pattern Hush, GitGuardian, and Flare are describing, but they point to the same underlying theme: MCP’s rapid adoption outpaced the security tooling built around it.
MCP Security Incident Timeline: 2025-2026
| Date | Event | Source |
|---|---|---|
| 2025 | CVE-2025-59536 — Claude Code project-file consent bypass identified | Check Point Research |
| 2026 | CVE-2026-21852 — Credential exfiltration via ANTHROPIC_BASE_URL in Claude Code projects | Check Point Research |
| Sept. 2026 | GitGuardian’s State of Secrets Sprawl 2026 logs 24,008 secrets in public MCP configuration files | GitGuardian |
| Oct. 2, 2026 | CERT-EU Cyber Brief flags rising LLM-jacking of stolen AI API access and hijacked cloud servers | CERT-EU / Google Threat Intelligence Group |
| Oct. 7, 2026 | Flare publishes audit of 2,327 MCP-configuration records, 96 with live extractable secrets | Flare |
| Oct. 8, 2026 | Hush Security reports 1-in-8 hardcoded credential slots across ~82,000 public MCP files | Hush Security / TechTarget |
Market Impact: AI Agent Security Funding and Vendor Response
The MCP credential-exposure pattern lands in a market that has already been pricing in agent-security risk. AI agent security startups including Zenity, HiddenLayer, and Straiker have drawn tens of millions of dollars in funding over the past year to build monitoring and governance tooling specifically for agentic AI deployments, reflecting investor confidence that the problem these reports describe is structural rather than a one-off embarrassment. Secret-scanning vendors such as GitGuardian have moved quickly to extend existing git-history and endpoint scanning products to specifically flag MCP configuration patterns, treating it as a new product category rather than a footnote inside existing secrets-management tooling.
For enterprises, the practical impact shows up in procurement and audit requirements. Security teams evaluating AI coding assistants are increasingly asking vendors how MCP credentials are stored, whether the tool defaults to environment-variable references instead of literals, and whether any built-in scanning catches hardcoded secrets before a developer commits a configuration file. That shifts MCP security from a developer-hygiene question into a vendor-selection criterion, which is exactly the kind of shift that tends to move budget.
Historical Context: From .env Files to Agent Tool Chains
Hardcoded secrets in source code are not a new problem. Tools like TruffleHog and GitGuardian itself have spent close to a decade scanning public and private repositories for exposed API keys, database passwords, and tokens, building the methodology, distinguishing a secret-shaped string from one that’s actually live, that newer MCP-focused research now borrows directly. What’s changed is the surface area and the stakes per leak.
A leaked key in a traditional .env file typically unlocks one service. A leaked MCP configuration can unlock an entire agent’s reach: every database, every API, every internal tool that agent was wired to use, often because multiple services were grouped into a single configuration file for a developer’s convenience. The Vulnerable MCP Project, a community effort tracking MCP-specific flaws, has already cataloged more than 50 known vulnerabilities across the ecosystem, with 13 rated critical, a fast accumulation for a protocol that only became widely adopted in the past two years. That pace echoes, and arguably exceeds, the early days of cloud API key sprawl that drove AWS and GitHub to build automated credential-revocation systems roughly a decade ago.
Competitive Landscape: Tools Built for the Agent-Credential Era
No single product category owns MCP credential security yet, which is itself part of the story. Established secret-scanning platforms are extending into the space, dedicated AI-agent security startups are building governance layers specifically for agentic tool use, and cloud providers are left deciding whether to extend existing automated-revocation programs to cover MCP-specific credential formats. The table below groups the main approaches currently being marketed against this problem, based on each category’s public positioning rather than a single vendor’s claims.
| Approach | Example Vendors / Projects | What It Covers | Primary Gap |
|---|---|---|---|
| Git secret scanning | GitGuardian, TruffleHog, GitHub native scanning | Detects hardcoded secrets in commits, history, and configuration files | Historically tuned for known key formats; MCP-specific patterns still maturing |
| AI agent governance | Zenity, HiddenLayer, Straiker | Monitors agent behavior, permissions, and tool-call patterns at runtime | Runtime visibility, not necessarily pre-commit credential hygiene |
| Secrets management / vaulting | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault | Centralizes credential storage so MCP files reference, not contain, secrets | Requires developers to adopt the pattern consistently; no enforcement on its own |
| Community vulnerability tracking | The Vulnerable MCP Project, OWASP AISVS | Catalogs known MCP-specific CVEs and architectural weaknesses | Reference material, not an automated defense layer |
None of these approaches, on its own, fully closes the gap Hush, GitGuardian, and Flare describe. Git scanning catches a secret after it’s already been pushed; vaulting only works if developers consistently use it; agent governance tools watch behavior at runtime rather than preventing a bad configuration from existing in the first place. The realistic near-term fix looks like a combination: pre-commit scanning tuned specifically for MCP file formats, paired with vault-backed credential references as the default template developers start from.
What Comes Next: 5 Predictions for MCP Security in 2027
Based on how fast the MCP ecosystem has grown and how these three reports have landed within weeks of each other, a few trends look likely to play out over the next year.
- GitHub extends native secret scanning to MCP-specific formats. Given that AWS and Stripe key leaks already trigger automated GitHub alerts, MCP configuration patterns are a logical next addition, especially after this week’s coverage.
- Anthropic ships MCP tooling defaults that discourage hardcoded secrets. Expect official MCP server templates and SDKs to push environment-variable references and vault integration as the default scaffold rather than an opt-in best practice.
- Secret-scanning vendors roll out dedicated MCP products. GitGuardian’s existing move into this space suggests competitors will follow with purpose-built MCP configuration scanners rather than treating it as a subset of generic secret detection.
- AI agent security funding keeps climbing. With Zenity, HiddenLayer, and Straiker already drawing significant capital, expect additional funding rounds specifically framed around agent credential and tool-access governance through 2027.
- Enterprise AI procurement adds MCP-specific security questionnaires. Expect security reviews for new AI coding tools to formally ask how MCP credentials are stored and scanned, turning this research into a checklist item rather than a one-time news cycle.
What Developers and Security Teams Should Do Now
The most immediate, practical response doesn’t require waiting on a vendor fix. Teams running MCP servers should audit their own configuration files for hardcoded values today, replace any literal credential with a reference to an environment variable or vault secret, and rotate any credential that may have ever touched a public repository, even briefly. Because Hush’s data shows nearly a quarter of hardcoded MCP secrets are both non-expiring and broad-scope, the safest assumption for any credential that was ever exposed, even for a few minutes before a commit was reverted, is that it should be treated as compromised and rotated rather than left in place.
For organizations adopting AI coding agents at scale, this is also a good moment to formalize a review step for any new MCP server integration before it goes into a shared or public repository, similar to the code-review gates most teams already apply to application secrets. The pattern researchers describe isn’t exotic: it’s the same hardcoded-secret problem that has existed since the first .env file was accidentally committed, just with a wider blast radius because of what AI agents are now allowed to touch.
Frequently Asked Questions
What is Model Context Protocol (MCP)?
MCP is an open standard, originally released by Anthropic, that lets AI agents and coding assistants connect to external tools, databases, and services through a common interface rather than custom-built integrations for each one.
What did Hush Security actually find?
Hush analyzed about 82,000 public MCP configuration files on GitHub and found that 12% of credential slots contained a hardcoded secret, with 24% of those hardcoded secrets being both non-expiring and broad in access scope.
How is this different from GitGuardian’s and Flare’s reports?
All three studied the same underlying problem using different datasets and methods. GitGuardian found 24,008 unique secrets in public MCP files with 2,117 confirmed valid; Flare found 438 distinct credentials (218 after excluding one harvesting cluster) across a smaller deduplicated set, with 96 live extractable secrets.
What kinds of credentials were exposed?
Researchers found Anthropic API keys, OpenAI API keys, generic cloud API keys, plaintext passwords, OAuth access tokens, and credentials tied to databases and internal enterprise workspaces.
Has Anthropic or GitHub responded?
As of this writing, neither Anthropic nor GitHub has issued a public statement specifically addressing the Hush Security findings, even though Anthropic’s own API keys appeared among the exposed credentials.
Is this connected to “LLM-jacking”?
Yes. CERT-EU’s October 2026 Cyber Brief flagged a rise in LLM-jacking, where criminals steal or resell AI API access and hijack cloud servers to run unauthorized AI workloads. Leaked, non-expiring AI API keys from MCP files are a direct input into that activity.
What should developers do if they’ve published an MCP config file publicly?
Rotate any credential that ever appeared in the file, even if it was quickly removed or the repository was made private afterward, and replace hardcoded values with references to environment variables or a secrets manager.
Are there known CVEs tied to MCP security?
Yes. CVE-2025-59536 and CVE-2026-21852, both identified by Check Point Research, cover a consent-bypass issue and credential exfiltration through Claude Code’s project configuration handling. The Vulnerable MCP Project has cataloged more than 50 MCP-related vulnerabilities in total, with 13 rated critical.
