MCP server security exposes hardcoded credential risk in AI agent

At a glance

What this is: This research shows that MCP server adoption is scaling on a weak credential foundation, with hardcoded secrets and limited OAuth use dominating current deployments.

Why it matters: It matters because MCP sits between AI agents and enterprise systems, so weak credential handling in that layer directly affects NHI governance, agentic access, and broader identity controls.

By the numbers:

• The research analyzed over 5,200 public repositories.
• Only 8.5% use OAuth, the preferred delegation framework.

👉 Read Astrix Security's State of MCP Server Security 2025 research

Context

MCP server security is really about how AI agents obtain access to tools and data without turning every integration into a standing credential risk. In practice, that means the credential model matters as much as the protocol itself, because hardcoded API keys and PATs create durable access paths that are hard to govern once agents are in production.

This matters for NHI programmes because MCP servers sit squarely in the boundary between workload identity and agentic access. When most deployments depend on long-lived secrets, the result is not just exposure risk but weak lifecycle control, limited scoping, and poor visibility into which agent can do what.

Astrix Security’s research frames a common pattern across early MCP adoption: convenience first, governance later. That is a typical starting point for emerging identity layers, but it becomes a structural weakness once the protocol starts carrying real enterprise permissions.

Key questions

Q: How should security teams handle hardcoded credentials in MCP server deployments?

A: They should remove static secrets from configuration files, environment variables, and code repositories, then replace them with runtime retrieval from a controlled vault. The goal is to shrink exposure windows and bind each credential to a specific agent, tool, and task boundary. Without that shift, MCP becomes a reusable access path rather than a governed identity layer.

Q: Why do MCP servers create more NHI risk than ordinary service integrations?

A: MCP servers often sit in front of multiple tools and data sources, so a single exposed secret can grant broad downstream access. That makes scoping, revocation, and ownership more important than the protocol label itself. The risk grows when teams treat access as a development convenience instead of a governed non-human identity.

Q: What do security teams get wrong about secret rotation in AI agent environments?

A: They often focus on rotation cadence without first fixing where secrets live and how widely they are reused. If a credential is hardcoded into a server, rotation only reduces exposure after compromise, not before it. Teams need to redesign the access path so each secret is short-lived, scoped, and auditable.

Q: How can organisations tell whether MCP access is actually governed?

A: Look for three signals: whether credentials are fetched at runtime, whether each credential maps to one agent or tool, and whether access can be revoked without breaking unrelated workflows. If the answer is no, the environment is still relying on standing access. Governance is real only when ownership, scope, and revocation are all visible.

Technical breakdown

Hardcoded secrets in MCP servers

MCP servers commonly rely on static API keys, PATs, or environment variables to authenticate access to tools and data. That model is familiar because it is easy to wire into development workflows, but it creates a persistent secret that can be copied, leaked, or reused outside the intended runtime. In identity terms, the credential becomes the real control plane, which means compromise is not limited to the server process. The research’s findings show that many deployments still treat secret placement as a developer convenience rather than an access governance decision.

Practical implication: remove static credentials from MCP server configuration and move to runtime secret retrieval with explicit scoping.

OAuth delegation and least privilege for AI agents

OAuth is the cleaner delegation pattern because it can issue narrower, revocable access instead of embedding standing secrets. For MCP, that matters because AI agents do not need to inherit broad, durable credentials simply to call a tool. The problem is that protocol support alone does not guarantee governance, since token scope, consent boundaries, and renewal behaviour all shape real access. When OAuth adoption is low, the result is usually a fallback to coarse-grained secrets that are harder to review and much easier to overuse.

Practical implication: prefer delegated access models that can be scoped, revoked, and reviewed per agent and per tool.

Runtime secret retrieval and secret sprawl

Fetching secrets at runtime changes the exposure model, because the credential is no longer stored in configuration files, repositories, or endpoint variables. That reduces the chance of secret sprawl, but only if the runtime path is itself controlled and audited. If retrieval is broad, unauthenticated, or poorly segmented, the design simply moves the weak point from the file system to the vault boundary. The core issue is not storage alone, but whether the access path matches the actual task boundary of the agent or workload.

Practical implication: pair runtime retrieval with task-scoped access policies and logging at the retrieval boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hardcoded MCP credentials are not a hygiene issue alone, they are an identity design failure. MCP servers are becoming the access layer for AI agents, yet the research shows that most still depend on static secrets, environment variables, and coarse-grained access. That means the identity boundary is being implemented as a reusable credential rather than a governed delegation model. Practitioners should treat this as a structural NHI control gap, not a packaging problem.

Ephemeral credential trust debt: the MCP ecosystem is scaling faster than its access governance model. When 20,000 implementations grow around a secret-first pattern, the accumulated debt is not just exposure, it is operational dependence on credentials that are hard to scope, rotate, and revoke. OAuth adoption at 8.5% signals that delegated access is still the exception, not the norm. The implication is that NHI programmes must assess whether agent integrations are inheriting production permissions through convenience patterns that were never designed for durable scale.

Secret exposure windows are becoming the primary attack surface for agent integrations. This research aligns with broader breach patterns in which exposed credentials drive compromise, lateral movement, and persistence. The issue is not only whether a secret exists, but how long it lives, where it is copied, and whether it can be linked to a single workload or agent. For security teams, that shifts attention from isolated leak prevention to lifecycle governance across repositories, endpoints, and vault retrieval paths.

MCP governance is now a workload identity problem as much as an AI problem. AI agent access through MCP depends on the same lifecycle controls used for service accounts, tokens, and certificates, but the pressure to move quickly often bypasses those controls. That creates a category error: treating agent access as an integration detail instead of an identity object with ownership, scope, and revocation requirements. Practitioners should align MCP controls to NHI governance before these deployments become embedded in production workflows.

From our research:

• Only 8.5% use OAuth, the preferred delegation framework, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
• For the protocol and delegation side, see OWASP Agentic Applications Top 10 for the control categories teams should align against.

What this signals

Ephemeral credential trust debt: MCP adoption is turning access shortcuts into long-tail governance debt, especially where development teams default to static secrets to ship integrations faster. The programme-level question is whether identity teams can still enforce ownership and revocation once those shortcuts are embedded in production workflows.

A useful benchmark is that 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and investigation blind spot according to AI Agents: The New Attack Surface report. That gap will widen if MCP access is not tied to auditable credential issuance, retrieval, and tool-use telemetry.

Teams building MCP governance should map the protocol to workload identity controls already used for service accounts and tokens, then layer in agent-specific scoping. The next phase of maturity will be less about whether the protocol works and more about whether every integration can be owned, reviewed, and revoked cleanly.

For practitioners

• Eliminate hardcoded MCP secrets from repositories and configs Move credentials out of configuration files, environment variables, and checked-in manifests. Use runtime secret retrieval with explicit access boundaries so a repository leak does not become an access event.
• Scope each MCP credential to a single agent and tool boundary Avoid reusable credentials that can call multiple systems. Issue task-scoped access with the narrowest permissions possible and tie ownership to a named service, agent, or workload.
• Audit MCP deployments for OAuth coverage and fallback paths Identify where static API keys or PATs are still being used because OAuth is unavailable or unimplemented. Prioritise the highest-risk integrations where exposed credentials would grant broad access.
• Monitor secret retrieval and tool invocation separately Log when a secret is fetched, which identity fetched it, and which tool was called afterward. That separation helps detect misuse when a credential is legitimate but the downstream action is not.

Key takeaways

• MCP server adoption is expanding on a credential model that still relies heavily on hardcoded secrets, which makes identity governance the central security problem.
• The evidence points to a large and growing exposure surface, with static credentials, environment-variable leakage, and limited OAuth use all reinforcing the same weakness.
• Security teams need to treat MCP access as a governed workload identity issue, not a development convenience, if they want to keep agent integrations controllable.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI systems connect to tools, data sources, and services in a structured way. In security terms, it becomes an identity boundary because every connected server can inherit access risk if credentials, scopes, and delegation are not tightly governed.
• Hardcoded Credential: A hardcoded credential is a secret stored directly in code, configuration, or environment settings instead of being issued at runtime. It is dangerous because it persists across deployments, is easy to copy, and often outlives the task or identity it was meant to support.
• Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
• OAuth Delegation: OAuth delegation is a token-based access pattern that allows one system to grant another limited access without sharing a reusable secret. For MCP and AI agents, it is valuable because scope, revocation, and consent can be enforced more cleanly than with static API keys.

What's in the full report

Astrix Security's full research covers the operational detail this post intentionally leaves for the source:

• Repository-level breakdown of where hardcoded MCP secrets were found and how they were stored
• Credential pattern analysis showing which deployment styles relied on API keys, PATs, or OAuth
• The MCP Secret Wrapper implementation details for fetching secrets at runtime
• The full recommendation set for developers and enterprise teams securing MCP integrations

👉 The full Astrix Security research covers the repository findings, credential patterns, and runtime secret mitigation detail.

Deepen your knowledge

MCP server security, runtime secret handling, and AI agent access scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent integrations or workload identities, it is worth exploring.