MCP Config Files Are Full of API Keys. 24,000 of Them Are Already on GitHub.

GitGuardian's State of Secrets Sprawl 2026 report published a number that should get the attention of any engineering leader who has been rolling out AI tools to their team: 24,008 secrets found in MCP configuration files on public GitHub — in a single year, in a category of file that did not exist the year before. AI-assisted commits leaked secrets at a rate of 3.2%, more than double the 1.5% baseline for non-AI commits. The attack surface that MCP created appeared, grew, and became a meaningful source of credential exposure in under twelve months.

This is not a hypothetical risk. It is a measurable consequence of how MCP setup currently works: per-developer, credential-bearing config files that live on local machines and frequently end up somewhere they were not intended to go.

How MCP configs become credential stores

To configure an MCP server, a developer edits a local configuration file — typically something like ~/.claude/settings.json, ~/.cursor/config.json, or a project-local .claude/settings.json. The configuration tells the AI client which MCP servers to run and what environment variables to pass to them. Those environment variables almost always include API keys.

A typical per-developer MCP config (~/.claude/settings.json or similar):
{
  "mcpServers": {
    "context-plus": {
      "command": "npx",
      "args": ["context-plus-mcp"],
      "env": {
        "GITHUB_TOKEN": "ghp_...",
        "OPENAI_API_KEY": "sk-...",
        "ANTHROPIC_API_KEY": "sk-ant-..."
      }
    },
    "jira": {
      "command": "npx",
      "args": ["@some-org/jira-mcp"],
      "env": {
        "JIRA_TOKEN": "ATATT...",
        "JIRA_EMAIL": "engineer@company.com"
      }
    }
  }
}

That config file now contains a GitHub personal access token, an OpenAI key, an Anthropic key, and a Jira service account token. It lives on the developer's machine in a dotfile location. Most developers do not think of it as a secrets file — it reads as a tool configuration. But it is functionally identical to a .env file at the root of a project, with the same risk profile if it ends up somewhere public.

The paths from config to exposure

The most common path is also the most mundane. Developers frequently track their dotfiles in a git repository so they can sync their development environment across machines. Many of those repositories are public — developers share their dotfile configs as a form of community contribution. The MCP config file gets included in the dotfiles repo, and the API keys go with it.

How secrets from MCP configs end up on GitHub:
  -> Developer adds MCP config with API keys to local dotfiles repo
  -> Dotfiles repo is public (common: developers share their configs)
  -> CI/CD pipeline bakes config file into a container image
  -> Config file committed to a shared repo by mistake
  -> Developer copies their full config to a work machine via git clone
  -> Config file included in a Docker build context by mistake
  -> Secret scanner not configured for new config file format

A less common but higher-severity path involves build pipelines. Docker builds that inadvertently include the user's home directory, or build steps that copy config files to inspect their contents, can embed credentials in container images. Container images published to Docker Hub or a company registry then become credential extraction targets.

There is also the churn problem. When a developer leaves the company, their MCP config — with credentials for systems they should no longer have access to — lives on their personal machine until that machine is wiped. If the developer copied their dotfiles to a public repo, the credentials are already out. If the company relied on per-developer API keys rather than scoped service credentials, rotating them requires knowing which keys were compromised.

Why per-developer MCP setup creates credential sprawl

The fundamental problem is that per-developer MCP setup distributes credentials across N machines, N config files, and N developers, each with their own habits around secret management. Some developers will use secret managers or environment variable injection. Others will paste the key directly into the config file. The policy cannot be enforced at the tooling level because the tooling does not have a way to distinguish between a key fetched from a vault and a key pasted from an email.

At ten developers, this is manageable with good onboarding instructions. At fifty developers, with different tenure levels, different operating systems, and different levels of security hygiene, the per-developer credential model is a credential audit problem waiting for a trigger.

The GitGuardian finding that AI-assisted commits leak secrets at more than twice the baseline rate is consistent with this. AI-assisted development tends to move faster, with less deliberate review of each file touched. When a commit includes an AI-generated change to a config file, the probability that the developer reviewed every value in that file before pushing is lower than for manually written code.

The specific risk surface for codebase MCPs

Codebase MCPs like Context+ require credentials that are particularly sensitive. A GitHub token with repo scope gives the holder read access to every private repository the user has access to. An Anthropic API key gives the holder the ability to run inference charged to the organization's billing account. A Jira token gives access to the organization's entire work history.

These are not low-value credentials. They are the keys to the company's source code, its AI spend, and its project management history. Distributing them across every developer's local config file — where they may end up in dotfiles repos, build caches, or shared development environments — is not a risk calibrated to the sensitivity of what those credentials provide.

Security teams reviewing AI tool rollouts are increasingly asking about this. The question is not whether MCP is safe in principle. The question is whether the per-developer credential model creates an audit surface that the organization cannot monitor or enforce policy on.

What a centralized managed endpoint changes

The alternative model is a centrally managed MCP endpoint where the credentials are held by the platform, not by individual developers. Developers authenticate to the platform using single sign-on or a scoped developer token. The platform uses its own service credentials to connect to GitHub, Jira, and other services. No raw API key lives on a developer's machine.

What changes with a managed MCP endpoint:
  -> One OAuth connection per organization (not per developer)
  -> No API keys in local config files
  -> Secrets live in the managed platform's vault, not on developer machines
  -> Rotating credentials requires one change, not fifteen developer configs
  -> Revocation is instant — remove access from one place
  -> No secret scanner policy needed for MCP config files

This is the model Kognita uses. Developers add a single MCP endpoint string to their editor config. That string does not contain credentials — it connects to Kognita's managed endpoint, which handles authentication via the organization's connected integrations. The GitHub OAuth connection, the Jira integration, and the model API access all live in Kognita's infrastructure, with a single audit surface rather than one per developer.

When a developer leaves the team, their access is revoked in one place. When a credential needs to be rotated, it is rotated once. When the security team asks "what API keys does your AI tooling have access to?", the answer is a list of org-level integrations rather than a request for every developer to audit their local dotfiles.

This is not just about hygiene — it is about auditability

SOC 2 and similar compliance frameworks are starting to ask about AI tool access governance. The audit question is not just "are your credentials secure?" It is "can you demonstrate that only authorized people had access to sensitive systems, and can you show the access log?" Per-developer MCP configs, scattered across personal machines and dotfiles repositories, cannot produce that log.

A managed MCP endpoint produces centralized access logs by default. Every query goes through the platform. The platform knows who asked, what they asked, and what was returned. That log exists not because someone remembered to turn on audit mode — it exists because all access flows through one controlled system.

Final take

The 24,008 secrets in MCP configs on GitHub are not the result of careless developers. They are the result of a tooling model that asks developers to manage credentials in a new class of config file that most secret scanning policies were not written to cover. When tooling creates new credential surfaces, secrets appear in those surfaces. That is predictable, and it happened.

The fix is not better secret hygiene training. The fix is a tooling architecture that does not distribute credentials across developer machines in the first place. Managed MCP endpoints exist specifically to provide this: the capability of a rich context layer without requiring every developer to hold and manage the credentials that power it.

AI tool credentials are too sensitive to live in dotfiles. The credential model for codebase MCPs needs to move from per-developer config files to centrally managed service connections, where access can be audited, scoped, and revoked from a single place.