Mcp server identity blind spots are widening enterprise ai risk

At a glance

What this is: This is an analysis of early MCP server security challenges, with the key finding that credential handling and identity context are lagging behind rapid AI-agent adoption.

Why it matters: It matters because MCP is turning AI agents into actionable identities, and IAM teams need controls that work for NHI sprawl, tool permissions, and auditability before the pattern hardens into technical debt.

By the numbers:

• The Astrix Research team analyzed over 5,200 unique, open-source Model Context Protocol server implementations to understand how they manage credentials.
• 88%, vast majority of servers, 88%, require credentials.
• 53%, r half, 53%, rely on insecure, long-lived static secrets.
• 8.5%.

👉 Read Astrix Security's analysis of MCP server security challenges and AI identity risk

Context

MCP, or Model Context Protocol, is the bridge that lets AI models reach tools and data sources. The governance problem is that many early implementations treat that bridge as a convenience layer rather than an identity control point, which leaves security teams with broad access, weak attribution, and unclear tool permissions.

That matters because AI agents are already being treated as operational identities inside enterprises, even when the surrounding IAM model still assumes a human or service account. When the protocol layer does not distinguish which agent is acting, least privilege, audit, and offboarding all become harder to enforce consistently.

For security and IAM teams, the issue is not whether MCP is useful. It is whether the identity model underneath it can support the access patterns it creates without normalising static secrets, invisible delegation, and unauditable tool use. That is why early MCP deployments look less like a finished control plane and more like a governance gap in the making.

Key questions

Q: How should security teams govern AI agents that use MCP to reach enterprise tools?

A: Treat MCP as an identity control point, not just an integration layer. Assign each agent a distinct identity, scope every tool permission tightly, and require logs that preserve attribution from action to actor. If a transaction cannot be tied back to a specific non-human identity, it is not governed well enough for sensitive use.

Q: Why do static secrets create so much risk in MCP environments?

A: Static secrets create standing trust that persists beyond the moment a task is executed, which makes them hard to scope, audit, and revoke. In MCP environments, that means one leaked token can expose multiple tools or workflows, while also hiding which agent actually performed the action. That is a governance failure as much as a technical one.

Q: What do teams get wrong when they assume MCP logs are enough for accountability?

A: Logs alone do not solve accountability if they do not preserve agent identity, delegation context, and the exact tool scope in use. A token use record tells you that something happened, but not always who initiated it or whether the access was appropriate. Teams need attribution plus scope, not activity records alone.

Q: How should organisations decide whether to allow MCP in sensitive systems?

A: Allow MCP only when the organisation can prove three things: distinct identity for the agent, narrowly scoped tool permissions, and reliable auditability across the full delegation chain. If any one of those is missing, the integration should stay out of sensitive environments until the control gap is closed.

Technical breakdown

Why static secrets dominate early MCP server deployments

Early MCP deployments often defaulted to bearer tokens, API keys, and PATs because they were simple to wire into developer workflows. That simplicity comes at a cost: static secrets create long-lived trust relationships that are hard to scope, hard to attribute, and easy to reuse across tools or agents. In practice, the protocol layer becomes a credential transport mechanism rather than an identity boundary. Once that happens, every tool call inherits the weaknesses of the secret behind it, not the governance intent of the platform.

Practical implication: treat long-lived MCP credentials as a governance exception and force them through the same control review as any other high-risk secret.

How missing identity context turns MCP into an audit problem

MCP’s early challenge is not only authentication, but identity context. A tool call authenticated by token does not tell you which AI agent initiated the action, whether a human requested it, or which delegated workflow triggered the call. That breaks the traceability chain needed for least privilege, recertification, and incident reconstruction. Without that context, the protocol can authorize access while still failing the governance test. Security teams end up with actions, but not accountable identities behind those actions.

Practical implication: require per-agent attribution and action logging before allowing MCP connections into sensitive systems.

Why partial adoption creates inconsistent NHI controls

The article describes a patchwork pattern where some teams use MCP for newer or less sensitive apps while preserving direct API calls for critical systems. That split matters because it creates multiple trust models in the same environment, each with different credential practices, audit depth, and access scope. Governance then becomes inconsistent across similar workloads, which is how shadow exceptions become standard operating practice. For NHI programmes, that inconsistency is often the real risk, because it hides behind a product decision rather than an explicit access policy.

Practical implication: map MCP and non-MCP integrations into one NHI control inventory so policy does not vary by integration style.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

MCP security is really an identity governance problem wearing a protocol label. The article is not describing a tooling gap alone. It is showing that when AI agents gain tool access through MCP, the core question becomes who or what is authorised to act, under what identity, and with what attribution. That makes MCP an NHI governance boundary, not just an integration standard. Practitioners should treat it as an identity plane decision, not a developer convenience.

Static secret dependence is the specific failure mode MCP exposes first. This pattern creates a standing-credential exposure window that persists across agent sessions, tool calls, and environment changes. The article’s 53% static-secret figure shows that the ecosystem is normalising long-lived trust where ephemeral, scoped access would be safer. The implication is not just that secrets need better handling, but that the current MCP trust model still assumes credentials are acceptable substitutes for governed identity.

Identity blind spots are amplified when AI agents act faster than review cycles can observe them. MCP implementations that do not carry agent identity context collapse action, delegation, and accountability into one opaque token flow. That breaks a basic NHI governance premise: access can only be governed when the actor can be distinguished at the point of use. Practitioners need to recognise that the control failure is traceability itself, not merely missing logging.

Named concept: protocol-level identity opacity. MCP’s early design shows how a protocol can be functionally useful while still obscuring the actor behind each action. That opacity creates audit gaps, policy gaps, and offboarding gaps at the same time. The discipline-level lesson is that identity governance has to sit at the protocol edge, or every downstream system inherits ambiguity. Practitioners should not confuse successful tool execution with governed access.

MCP adoption pressure will force teams to standardise NHI governance faster than many planned. The article points to rising use because developers want to collapse integration complexity. That means security teams will not get the luxury of waiting for a perfect standard. They will need a repeatable way to classify MCP-enabled identities, scope their permissions, and prove accountability across mixed integration patterns. Practitioners should plan for governance under adoption pressure, not after it.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• In the same research, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
• For the governance angle behind that exposure, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and sprawl patterns that make NHI estates hard to control.

What this signals

Protocol-level identity opacity: MCP adoption will keep increasing because it reduces integration friction, but that convenience will pressure security teams to absorb a new class of governed identities. The programme-level response is to treat agent identity, tool scope, and delegation context as one control problem rather than three separate ones.

With 53% of MCP servers relying on insecure, long-lived static secrets, per The State of MCP Server Security 2025, most environments are still normalising standing trust where controlled delegation should exist. That makes secrets inventory, attestation, and offboarding the immediate operational priorities for IAM and NHI teams.

If your current access model cannot distinguish one agent from another at the point of action, your audit model will fail later under incident pressure. Teams should expect MCP to force tighter alignment between NHI lifecycle controls, tool-level authorisation, and evidence quality for compliance.

For practitioners

• Inventory every MCP-enabled identity path Map which agents, scripts, and services use MCP today, then record the exact credentials, tool scopes, and downstream systems attached to each path. Prioritise any path that still depends on long-lived static secrets or shared tokens.
• Require per-agent attribution before production use Block sensitive tool access unless each MCP transaction can be tied to a distinct non-human identity, with logs that show the agent, the tool, the request context, and the target system.
• Scope tool permissions by task, not by server Do not let a working MCP server become a blanket trust boundary. Split permissions by tool, environment, and data class so a single credential cannot inherit super-user behaviour across unrelated actions.
• Fold MCP into NHI recertification and offboarding Review MCP integrations during access certification, and remove or rotate credentials when an agent, workflow, or integration is retired. Offboarding has to include the protocol path, not only the upstream application.

Key takeaways

• MCP is exposing an NHI governance gap, not just a protocol integration issue, because early deployments often authenticate actions without preserving clear actor identity.
• The scale of the problem is already measurable, with 88% of servers requiring credentials and 53% depending on long-lived static secrets.
• Security teams need to govern MCP through identity attribution, tool scoping, and lifecycle controls before the pattern becomes embedded technical debt.

Key terms

• Model Context Protocol: Model Context Protocol is an integration standard that lets AI models connect to tools and data sources through a common interface. In identity terms, it becomes a governance boundary because every tool call carries access, attribution, and delegation implications that security teams must be able to control and audit.
• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and authorize access, including service accounts, tokens, certificates, bots, and AI agents. In practice, the key governance issue is not whether it is automated, but whether its access can be scoped, reviewed, and revoked cleanly.
• Standing Credential Exposure: Standing credential exposure is the condition where a long-lived secret remains usable beyond the narrow task it was meant to support. For NHI programmes, this creates persistent attack opportunity, weak attribution, and revocation risk, especially when the same credential is reused across tools or agents.
• Protocol-level Identity Opacity: Protocol-level identity opacity occurs when a system can execute actions but cannot clearly identify which actor initiated them. For MCP and similar integrations, that means security teams may see successful tool usage without reliable attribution, which undermines least privilege, audit, and offboarding.

What's in the full article

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

• The survey-style breakdown of how customers, partners, and experts are seeing MCP adoption patterns across teams.
• The practical examples of how developers are wiring bearer tokens and static credentials into early MCP deployments.
• The discussion of when teams are keeping direct API calls instead of adopting MCP in sensitive environments.
• The article's preview of how MCP structure might also become part of the solution in a later instalment.

👉 Astrix Security's full post expands on the MCP adoption pattern, credential risks, and the next-step solutions.

Deepen your knowledge

MCP server security and AI agent identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are working through the same credential sprawl and auditability issues, it is worth exploring.