Mcp server identity blind spots are widening enterprise ai risk

At a glance

What this is: This analysis says MCP is quickly becoming the connective tissue for AI agents, but early deployments still depend heavily on credentials, static secrets, and weak identity context.

Why it matters: IAM and security teams need to treat MCP as an identity control problem, because agent access without strong attribution, privilege scoping, and auditability expands risk across NHI and autonomous AI programmes.

By the numbers:

• Astrix Security says 88% of more than 5,200 open-source MCP server implementations require credentials.
• Astrix Security says 53% rely on long-lived static secrets, including API keys and Personal Access Tokens.
• Astrix Security says only 8.5% use OAuth.

Context

MCP is the protocol layer that lets AI systems connect to tools, data sources, and enterprise systems. In practice, that makes it an identity problem as much as an integration problem, because every tool call needs a trustworthy answer to who or what is acting.

Astrix Security’s article argues that early MCP deployments create blind spots in attribution, privilege scoping, and auditability. The issue is not only that AI agents are proliferating, but that their access is often mediated by credentials and tokens that were never designed for fine-grained non-human identity governance.

For IAM and security teams, the governance question is whether MCP becomes a controllable identity layer or a new accumulation point for static secrets and shared trust. The article treats current adoption as a warning that operational convenience can harden into long-lived access debt.

Key questions

Q: Where does MCP fail when multiple AI agents share the same credential model?

A: It fails when one credential is used to represent many actors, because attribution, revocation, and least privilege all become ambiguous. Shared tokens make it impossible to tell which agent performed an action or to remove one actor without disturbing others, so governance loses both precision and accountability.

Q: Why do long-lived secrets increase enterprise risk?

A: Long-lived secrets increase risk because they remain usable long after exposure. If a key, token or certificate is stolen, the attacker can keep returning until the credential expires or is revoked. That persistence makes detection less useful unless rotation and expiration are enforced automatically.

Q: What are the warning signs that MCP access is not properly controlled?

A: Warning signs include hard-coded credentials in server files, broad tool permissions, no per-tool ownership, and logs that cannot show which agent made a call. If teams cannot trace a tool action back to an identity, policy, and purpose, the access model is too loose to trust.

Q: How do IAM teams keep MCP from becoming another unmanaged NHI sprawl problem?

A: IAM teams should inventory every MCP connection as a governed identity relationship, not a one-off developer convenience. The controls that matter are entitlement minimisation, approval for sensitive tools, periodic recertification, and clean offboarding. Without that discipline, MCP adoption simply multiplies machine identities faster than governance can catch up.

Technical breakdown

Why MCP becomes an identity choke point for AI agents

Model Context Protocol sits between AI agents and the systems they touch, so it inherits the trust decisions that used to live in application code or manual integrations. When the protocol layer is built around bearer tokens and shared access paths, the control plane stops distinguishing between the agent, the human sponsor, and the task context. That is why MCP is not just a transport mechanism. It becomes the point where identity context, authorisation, and audit trail either exist or disappear. Once that distinction is missing, every downstream tool call looks valid even when the actor behind it is not sufficiently governed.

Practical implication: Treat MCP as an access decision layer, not just an integration standard.

Why static secrets create disproportionate risk in MCP deployments

The article’s core technical concern is that many MCP servers still authenticate with long-lived API keys, personal access tokens, and similar static secrets. Those credentials are easy to deploy, but they create broad persistence because the same token can outlive the agent, the workflow, or the business need. In NHI terms, that means the credential is doing too much work for too long. The more MCP expands across teams and tools, the more likely those credentials are copied, reused, and lost to inventory. That turns convenience into an attack surface rather than a control.

Practical implication: Scope MCP credentials to the narrowest possible use case and track them as governed NHIs.

How lack of identity context breaks least privilege and auditability

Astrix Security highlights that out-of-the-box MCP did little to answer which agent was acting, or which human it was acting on behalf of. That missing identity context matters because least privilege depends on attributable subjects, not anonymous tokens. Without per-agent attribution and fine-grained authorisation, audit logs can show that a tool was called, but not whether the access matched the business purpose. The technical problem is therefore not only credential choice, but the absence of identity binding between actor, action, and scope. That gap makes normal governance controls far harder to enforce.

Practical implication: Bind each agent action to a specific non-human identity and enforce per-action scope limits.

Threat narrative

Attacker objective: Obtain durable access through MCP-mediated credentials and use that access to act inside enterprise systems with limited attribution and excessive privilege.

1. Entry begins when an AI agent or integration reaches enterprise systems through MCP using a credential such as an API key or personal access token.
2. Credential abuse follows when the same static secret is reused across agents, scripts, or tools, creating a durable authentication path that is easy to copy or leak.
3. Escalation occurs when the protocol layer does not preserve identity context, allowing overbroad access to look legitimate and enabling actions beyond the intended task scope.
4. Impact is misattributed or excessive machine access, with weak audit trails and expanded blast radius across connected enterprise systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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 identity debt is becoming the hidden cost of AI integration: The central risk is not that MCP exists, but that it often inherits the weakest parts of the identity stack while looking like a neutral connector. When agents, scripts, and tools share static credentials, the governance problem shifts from access grant to access archaeology. Practitioners should read MCP as a compounding identity layer, not a simple interoperability layer.

Least privilege for MCP depends on actor attribution, not just token possession: A bearer token proves that something was allowed to connect, but not which agent, workflow, or human sponsor should own the resulting action. That matters because identity governance depends on binding action to subject. Without that binding, the programme can certify a credential but still fail to govern the behaviour behind it. Practitioners should treat attribution as a control requirement, not an audit nicety.

Ephemeral integration convenience is creating long-lived access debt: MCP’s early developer friendliness pushes organisations toward reusable secrets and shared access paths that are hard to unwind later. The more this pattern spreads, the more the enterprise accumulates machine access that outlives the use case. The practical consequence is that future governance becomes more expensive than early design discipline ever would have been.

Agentic AI makes this an identity governance issue, not only a security issue: AI agents are not just another workload when they can initiate tool calls across multiple systems. That means lifecycle, certification, and exception handling all need to reflect non-human subjects that can expand faster than human review cycles. Security teams should expect IAM to absorb this workload, because the alternative is unmanaged AI access drifting into normal operations.

MCP may become the standard that exposes whether organisations actually govern NHIs: The protocol will not create the identity problem, but it will reveal which programmes still rely on broad trust, shared tokens, and incomplete inventories. The organisations that can name each agent, each credential, and each delegated action will adapt faster. The rest will discover that integration velocity has already outpaced governance maturity.

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

Identity context is the missing control variable in MCP rollouts: The practical challenge is not whether tools can connect, but whether the enterprise can still answer which non-human identity used the connection and under what authority. That question now sits at the centre of AI governance, because a protocol that hides actor identity also hides accountability.

MCP is turning static secrets into a governance problem at scale: Once teams start spreading the same credentials across agents, scripts, and services, the issue becomes lifecycle control, not just authentication strength. Security leaders should expect MCP to expose whether their NHI inventory is real or merely assumed.

Agentic AI adoption is forcing IAM to confront a new trust boundary: A growing share of enterprise automation will be mediated by AI agents rather than people, which means review cycles designed for human access will not be enough. The programme has to govern issuance, delegation, and revocation around machine-paced activity, not human-paced approvals.

For practitioners

• Inventory MCP credentials as governed NHIs Map every API key, personal access token, and other secret used by MCP servers, agents, and scripts to an owner, purpose, and expiry condition.
• Separate agent identity from transport access Require a distinct non-human identity for each AI agent or workflow instead of allowing shared tokens to represent multiple actors or use cases.
• Replace long-lived secrets with time-bound access Reduce reliance on static secrets by scoping credentials to the shortest practical task window and revoking them when the task ends.
• Enforce audit trails that name the acting agent Make logs carry the specific agent identity, the human sponsor where relevant, and the action scope so investigators can reconstruct who did what through MCP.
• Review third-party MCP implementations before broad rollout Treat externally sourced MCP components as supply-chain dependencies and validate whether they preserve identity context, authorisation boundaries, and revocation paths.

Key takeaways

• MCP’s risk is not only technical connectivity but the identity and audit gap created when agents act through shared credentials.
• Astrix Security reports that 88% of the analysed MCP servers require credentials, 53% rely on long-lived static secrets, and only 8.5% use OAuth.
• Teams should inventory MCP access as NHI, bind actions to specific agent identities, and reduce dependence on reusable bearer tokens.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Identity Attribution: Identity attribution is the ability to determine which entity performed an action and under what authority. For AI agents, it requires separate identities, structured logs, and traceable decision records so investigations can distinguish human intent from autonomous execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.