Why public MCP configurations create an AI governance risk

MCP credential leaks are becoming an AI governance problem

A public Model Context Protocol configuration can expose a secret along with instructions for using it. MCP configurations tell AI coding agents which enterprise tools they can reach and how to authenticate, so a usable credential can give an agent an identity with access to corporate applications, services and data. Hush Security's findings on public GitHub configurations establish the secrets-management problem. MCP adds an AI governance consequence because software can exercise those credentials autonomously.

That consequence follows from MCP's role as an open standard designed to make it easier for language models to query external databases and developer environments. MCP is rapidly becoming a standard way for AI coding agents to connect with enterprise tools and data, so its configuration files increasingly define both the connections and the authentication needed to use them. A publicly exposed configuration can thus provide useful attack material by showing how an AI tool connects to other systems.

That combination has prompted urgent warnings from security specialists. "CISOs should be very worried," said Keith Guttridge, an analyst at Gartner. Matthew Smith, a virtual CISO and management consultant specializing in cybersecurity risk management and AI, told TechTarget that the threat "is real, being exploited today, and should be a top concern for CISOs with development in their pipeline." Smith's consulting work gives him a commercial interest in organizational demand for cybersecurity and AI risk guidance, so his warning should be read with that incentive in view.

The public-config data establishes substantial secrets exposure

The immediate exposure is visible in Hush Security's review of around 82,000 public MCP configuration files on GitHub across more than a dozen coding agents. The researchers inspected credential slots, the parts of those configurations used to supply authentication information to connected services. They found that 12% contained a hardcoded credential literal, meaning an actual secret such as an API key, password or access token had been written directly into the configuration.

That share matters because anyone with internet access can find a configuration published in a public GitHub repository. A literal secret in the configuration can potentially be reused against its associated service, application or data. The exposed credentials included Anthropic and OpenAI API keys, showing that credentials for AI services themselves are part of the problem.

The impact can grow when an exposed credential combines long life with extensive permissions. Among the hardcoded credentials Hush Security found, 24% were both non-expiring and broad-scope. Those properties can provide extensive access to assets including databases and workspaces indefinitely unless another action invalidates the credential. Hush Security has a commercial interest in enterprise security, which is relevant context for its interpretation of the risk while leaving the reported measurements clear.

Those measurements establish credential exposure in public MCP configurations and describe important properties of the exposed secrets. Machine identity becomes relevant when an agent operates with one of those credentials. At that point, the security question expands from whether a secret is public to what software can do with the identity that secret enables.

MCP can turn a leaked secret into an autonomous identity

That shift can happen through a short exploitation path because a public MCP configuration already contains information an agent needs to connect. An attacker can find a configuration containing a usable hardcoded credential, copy the relevant configuration and credential information into an AI agent, and potentially reach the applications, services or data associated with that identity. Guttridge described the required effort in direct terms: "That is all it takes. No need to have any technical understanding at all."

That ease of reuse becomes more consequential when the credential has extensive permissions and remains valid indefinitely. An exposed broad-scope, non-expiring credential can continue providing substantial access until somebody invalidates it. MCP adds autonomous operation to that access because software can act with the identity without requiring a person to perform each operation.

Hush Security captured that distinction directly: "Worse, it grants that access to an agent, not a person." The researchers continued: "An MCP server acts under this identity autonomously: no human in the loop, no joiner-mover-leaver process to revoke it, often no record of who created it." Joiner-mover-leaver processes govern access as employees enter an organization, change roles and leave, so an agent outside those processes can retain an identity without the normal organizational events that trigger access changes.

That autonomy makes machine identity part of the AI governance problem. An MCP server can operate under the credential's permissions while normal signals tied to a human account may be absent. Security teams consequently need to know which agents possess identities, what those identities can reach and how their access will be terminated.

The same identity can also expose two kinds of organizational asset: information and spending capacity. Smith warned that attackers could use exposed MCP credentials to steal private information and generate large AI-token charges for the organization that owns the key. An AI service credential can thus create direct spending exposure when an attacker uses the organization's paid consumption capacity.

That spending risk explains why Smith said attackers specifically seek AI keys to supply their token usage. Reuse of an exposed Anthropic or OpenAI API key can impose serious costs on the victim organization because consumption is billed to the legitimate holder. For security and engineering leaders, credential scope consequently includes both the systems an identity can access and the resources it can spend.

Git history can preserve credential exposure

Once a team discovers a hardcoded MCP credential, editing the current configuration leaves an important part of the response unfinished. Hush Security found that secrets deleted from current configurations could remain in earlier versions stored in Git history. The visible file may be clean while an older revision still exposes a working credential to someone who retrieves it.

That persistence makes provider-side invalidation necessary because removing the literal changes only the current configuration. Historical copies can remain usable while the credential itself remains valid. Hush Security's conclusion is explicit: "The only thing that actually ends the exposure is rotating the credential at the provider." Rotation ends the usefulness of the exposed value wherever a copy survives.

After rotation, teams can change the configuration pattern that created the exposure. Hush Security identified safer approaches including $ expansion, which supplies a credential through a variable, as well as client-native prompts, secret managers and placeholders. These patterns keep the actual credential value out of the committed configuration, reducing the chance that Git history becomes a durable record of an active secret.

Govern the MCP connections that exist

Safer credential handling still leaves the wider governance problem because MCP adoption can extend beyond officially approved AI deployments. Guttridge said organizations with AI agents, including sanctioned and unsanctioned ones, are likely already using MCP to connect those agents with enterprise systems. He called MCP a "'now' problem" and warned: "If you haven't started governing MCP, you are already playing catch-up."

That existing adoption makes discovery the next control problem. Brandon Dixon, CTO and cofounder of AI cybersecurity company Ent, frames the CISO's task in two parts: secure the organization's internal AI software-development processes and find which privileged resources users are connecting to AI models through MCP servers. Ent has a commercial interest in demand for AI cybersecurity, so its recommendations come from a company that can benefit as organizations invest in this area.

Dixon connects that discovery problem directly to unsanctioned adoption. "This is an immediate call to action," he said. "AI is being used inside the organization whether the CISO has approved the software or not." An inventory of approved AI software can therefore leave MCP clients, servers and privileged connections outside the organization's known environment.

Once teams find those connections, the configuration itself provides the first operational checkpoint. Security teams can review MCP server configurations for hardcoded variables and verify that credential slots use patterns such as environment-variable expansion, client-native prompts, secret managers or placeholders. That review addresses authentication material where agents are configured to reach other systems and can reveal credentials that require provider-side rotation.

Identified connections then need deliberate access management. Recommended approaches include managing MCP server access through an AI or MCP gateway, or using an MCP aggregator. These control points can bring individual client-server relationships under a common access-management process instead of leaving each connection to separate configuration decisions.

Central controls still need detection coverage because users or development teams may create connections without registering them. Organizations should assess whether their existing network detection and response platforms and endpoint management systems can detect unapproved use of MCP clients and servers. Given the exposure and the likelihood of existing sanctioned and unsanctioned adoption, the recommendation is for CISOs to assess their MCP exposure "this week."

That assessment also covers the protocol version running in deployed systems. Developers should use the latest MCP version, specifically the 2026-07-28 Model Context Protocol specification, which adds security controls. Using that specification applies the newer security provisions at the protocol level alongside credential rotation, connection discovery and access management.

Key takeaways for decision-makers

• Treat MCP credential leaks as an AI governance risk: Public MCP configurations can expose credentials that give AI agents autonomous access to enterprise systems, data and spending capacity. CISOs need visibility into which agents hold machine identities and what those identities can access.
• Prioritize long-lived, broad-scope credentials: Hush Security found hardcoded credentials in 12% of roughly 82,000 public MCP configurations, with 24% of those credentials both non-expiring and broad-scope. Security teams can prioritize these exposures for immediate investigation and remediation.
• Govern agent identities and permissions: MCP can let software exercise exposed credentials autonomously, extending the risk beyond the initial secret leak. Security teams need controls for agent identity ownership, permissions, monitoring and revocation.
• Rotate exposed credentials at the provider: Removing a hardcoded secret from the current configuration may leave usable copies in Git history. Development and security teams need to rotate exposed credentials and move active secrets into environment variables, secret managers or other safer mechanisms.
• Discover and control MCP connections: Sanctioned and unsanctioned AI tools may already connect to privileged enterprise resources through MCP. CISOs can inventory MCP clients and servers, centralize access through gateways or aggregators, detect unapproved connections and move deployments to the latest MCP specification.