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 alongside insecure credential handling, with hardcoded API keys, PATs, and environment-variable secret passing still common.

Why it matters: It matters because MCP sits on the access path between AI agents and enterprise systems, so weak secret governance directly expands the blast radius of autonomous and non-human access.

By the numbers:

• Astrix Security analyzed over 5,200 public repositories in the State of MCP Server Security 2025.
• More than half, 53%, of MCP servers still rely on static API keys or Personal Access Tokens.
• Only 8.5% of MCP servers use OAuth, while 79% of API keys were passed via environment variables.

Context

MCP server security is about how AI agents obtain and use credentials to reach tools, data, and systems. In this case, the issue is not the protocol itself but the identity model being built around it: too many deployments still treat secrets as static configuration instead of governed runtime access.

Astrix Security's research shows a gap between how fast MCP adoption is growing and how slowly credential governance is maturing. When secrets are hardcoded, passed through environment variables, or left long-lived, the result is not just exposure risk but weak control over who or what can act on behalf of the agent.

For IAM and NHI teams, the relevant question is whether MCP integrations are being treated like ordinary application wiring or like a privileged identity surface. The article points to the latter, because agent integrations concentrate access and make secret handling a control boundary, not a convenience choice.

Key questions

Q: What breaks when MCP credentials are hard coded?

A: Hard-coded credentials break lifecycle control. They are difficult to scope, hard to rotate, and easy to reuse across tools or environments, which means the same secret can outlive the team or use case that created it. In an MCP context, that creates a standing access path that is far broader than the interface suggests.

Q: Why do static API keys create risk for AI agent access?

A: Static API keys create risk because they are long-lived, reusable, and difficult to tie to a specific action. In an agentic environment, that means the same secret can be replayed across tools, sessions, or workloads long after the original task is complete. Short-lived delegated credentials give teams a much better chance of limiting scope and preserving accountability.

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

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: What should security teams do when AI agents need access to tools and data?

A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.

Technical breakdown

Why hardcoded MCP credentials create persistent identity risk

Hardcoded credentials in MCP servers create a static trust anchor that survives far longer than the session, task, or deployment that uses it. API keys and PATs are bearer credentials, so anyone who obtains them can replay them until they are rotated or revoked. In an AI agent context, that matters because the agent is often the party calling tools at runtime, which means the secret becomes the real authorisation boundary. Environment variables do not fix that problem; they only relocate the secret. The underlying failure is lifecycle control, not storage format.

Practical implication: treat every MCP secret as a high-value NHI credential with explicit rotation, revocation, and scope controls.

Why OAuth changes the delegation model for MCP servers

OAuth changes MCP access from shared secret reuse to delegated authorisation with clearer scope and token lifecycle boundaries. That does not make the environment automatically safe, but it does reduce the reliance on static credentials embedded in code, configs, or deployment plumbing. For identity teams, the distinction matters because OAuth can express consent, audience, expiry, and scoped access in a way that simple API keys cannot. In an MCP deployment, that means the control plane can reason about who granted access, for what purpose, and for how long, instead of treating every integration as a permanent secret relationship.

Practical implication: prefer delegated, short-lived authorisation patterns over shared long-lived secrets wherever MCP can support them.

How runtime secret fetching shifts the control point

Fetching secrets at runtime moves the control point from static configuration to a governed access decision at execution time. That matters because the secret no longer needs to live in repositories, build logs, environment files, or endpoint configs for long periods. The real architectural gain is not just removal of hardcoded values but reduction of exposure surface and tighter coupling between credential issuance and use. In NHI terms, this is a shift from secret presence to secret delivery, which gives governance teams a chance to apply policy at the moment the credential is actually needed.

Practical implication: centralise secret delivery at runtime and pair it with issuance, logging, and revocation controls.

Threat narrative

Attacker objective: The attacker wants to reuse exposed MCP credentials to access connected tools and systems through the AI agent integration layer.

1. Entry occurs when MCP servers are configured with hardcoded API keys or PATs, often copied into repositories or passed through environment variables.
2. Credential access follows when those exposed secrets are retrieved from code, logs, or deployment artifacts and can be reused as bearer tokens.
3. Escalation happens when the same long-lived credential grants broad tool or data access beyond the original integration boundary.
4. Impact is unauthorized access to connected systems, with the potential for data exposure, agent misuse, or wider account compromise.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 secrets are not an implementation flaw, they are an identity governance flaw: The article shows that MCP adoption is scaling faster than secret lifecycle discipline. When agents depend on static API keys and PATs, the environment is building privileged access around reusable bearer credentials instead of governed delegation. That means the control question is not simply where the secret lives, but whether the identity model can tolerate secret reuse at all.

Ephemeral access must become the default assumption for agent integrations: MCP servers are increasingly the access path for AI agents, which means long-lived secrets now concentrate both trust and blast radius. Static credentials make every compromise more durable because they outlive the context that created them. Practitioners should read that as a signal that agent integrations need lifecycle control designed around issuance time, not later review cycles.

Environment variables are storage, not security: The article's 79% environment-variable figure shows how often teams confuse concealment with governance. Moving a key out of source code does not change its standing privilege, its replay value, or its revocation burden. The named concept here is credential storage masquerading as control: if the secret is still long-lived and broadly reusable, the risk model has not changed.

MCP adoption makes non-human identity policy a platform concern: Once MCP becomes the standard access layer for agents, NHI governance can no longer sit outside platform engineering. Access scope, secret delivery, and revocation now shape whether an AI agent is merely connected or truly governed. The practical conclusion is that identity teams must define MCP access as part of the NHI control plane, not as an application-side convenience.

Runtime secret delivery is becoming the minimum viable control for agentic access: The article's emphasis on fetching secrets from a vault at runtime reflects a broader shift in NHI security. Static secrets assume a stable access window; agentic systems make that assumption increasingly fragile. The implication is that organisations that keep treating credentials as deploy-time configuration will continue to inherit avoidable exposure.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Credential storage masquerading as control: The biggest MCP governance failure is not the presence of secrets but the assumption that hiding them in environment variables makes them manageable. When bearer credentials remain long-lived and widely reusable, the organisation still has standing access, only with a thinner paper trail.

MCP adoption is pushing identity teams toward runtime issuance models because static secret handling cannot keep pace with agent execution patterns. That shifts the control conversation from secret placement to secret lifecycle, which is where NHI governance becomes decisive.

Delegation, not concealment, is the real test: MCP access becomes governable only when the team can bound who issued the credential, what it can reach, and when it stops working. Without that, the environment variable is just a hiding place for the same risk.

For practitioners

• Replace hardcoded MCP credentials Move API keys and PATs out of repositories, configs, and endpoint files, and require runtime retrieval from a governed vault before any agent call is made.
• Scope every MCP integration as an NHI Classify each agent connection as a non-human identity with explicit ownership, purpose, expiry, and revocation criteria rather than an informal application integration.
• Enforce short-lived delegated access Use OAuth or equivalent delegated authorisation where available so token lifetime and audience are bounded instead of relying on reusable static secrets.
• Monitor MCP secret usage continuously Log secret issuance, use, and anomaly signals so teams can detect credential reuse, unexpected access paths, and orphaned integrations before compromise spreads.

Key takeaways

• MCP server growth is colliding with credential practices that still rely on static, long-lived secrets.
• The scale of the problem is already visible in public repositories, where hardcoded API keys, PATs, and environment-variable secret handling remain common.
• The practical response is to move agent access toward runtime-issued, tightly scoped credentials with explicit lifecycle governance.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Hardcoded Credential: A secret such as a password, API key, or token embedded directly in source code rather than retrieved from a secure vault at runtime. Hardcoded credentials are one of the most common and dangerous NHI vulnerabilities.
• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
• Runtime Secret Delivery: Runtime secret delivery is the practice of supplying credentials only when a workflow actually needs them, rather than storing them permanently in a file or environment. Used well, it reduces exposure, but it still depends on strong ownership, logging, and revocation discipline across the full lifecycle.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.