MCP governance is becoming an identity problem, not just an integration one

At a glance

What this is: This is an analysis of why MCP’s integration gains also create identity and governance risk, especially around static credentials, context bloat, and expanding agent tool access.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern tool access for AI agents as a living identity problem, not a one-time connector decision.

By the numbers:

• By December 2025, Anthropic counted 10,000+ active public MCP servers and 97 million monthly SDK downloads across Python and TypeScript alone.
• 53% of MCP servers rely on static credentials rather than OAuth, creating a broad governance gap in enterprise deployments.
• CVE-2025-6514 put over 437, 000 installations of mcp-remote at risk through a shell injection vulnerability.

👉 Read Obot's analysis of MCP architecture, context bloat, and governance risk

Context

MCP is a protocol for connecting AI models and agents to tools and data sources through structured interfaces, but that convenience quickly becomes an identity and governance problem when access is granted at scale. In practice, the challenge is not only integration complexity, but also credential sprawl, audit gaps, and uncontrolled tool exposure across AI-driven workflows.

The primary security question is how to govern non-human identities that now interact with enterprise systems through MCP servers, CLI wrappers, and autonomous workflows. Obot’s analysis shows that the technical debate is shifting from connectivity to control, especially where static credentials, context bloat, and shadow AI begin to overlap.

That makes MCP maturity less about protocol adoption and more about whether an organisation can decide which tools deserve structured access, which ones belong behind policy, and which ones should never be exposed to agents at all. For many teams, that is a typical scaling problem rather than an edge case.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: What are the risks of using static credentials in MCP servers?

A: Static credentials, such as API keys and PATs, are often not rotated and can be easily compromised, posing a significant risk for unauthorized access. Organizations that rely on static credentials expose themselves to attacks that leverage these persistent access points.

Q: What breaks when too many MCP servers are connected at once?

A: The context window fills with tool definitions before the agent has done useful work, and governance gets harder because the reachable surface expands faster than oversight. That produces both performance drag and an access control problem. The agent sees more, can try more, and is harder to constrain.

Q: Should organisations use CLI instead of MCP for some workflows?

A: Yes, when the tool is already well understood, the workflow is narrow, and the environment is tightly controlled. CLI can reduce context overhead and simplify execution, but it should not be used to bypass identity, audit, or policy controls that matter in enterprise settings.

Technical breakdown

Why MCP creates context bloat at scale

MCP servers advertise their tools into the model context window, which means every connected server adds schema text, tool descriptions, and invocation metadata before the agent does any reasoning. In small environments that overhead is manageable, but in larger ones the tool catalogue itself becomes part of the cost of working. The result is context bloat, where the agent spends capacity remembering what it can do instead of deciding what it should do. This is not a defect in JSON-RPC or schemas. It is a scaling property of exposing too many governed actions at once.

Practical implication: limit exposed tool surfaces and separate high-frequency workflows from broad discovery-oriented MCP access.

How static credentials change the NHI risk profile

Static credentials inside MCP server configurations turn tool access into a long-lived secret problem rather than a session-scoped authorisation problem. If a server relies on stored keys instead of federated access and audit-friendly identity flows, then the agent inherits credentials that are hard to rotate, hard to scope, and hard to revoke cleanly. That makes the protocol’s convenience inseparable from classic NHI weaknesses: secret persistence, unclear ownership, and weak lifecycle control. The technical issue is not that the tool works. It is that the access method often outlives the task and the user who configured it.

Practical implication: treat MCP credentials like governed NHI secrets, not developer conveniences.

When CLI wrappers help and when they weaken governance

CLI wrappers can reduce context load because the model issues one command instead of maintaining multiple structured tool calls. That makes them attractive for well-known utilities and batch-style workflows. But the governance trade-off is real: wrappers often bypass the native authentication, logging, and permission structure that MCP was designed to support. In enterprise settings, that can move the problem from protocol overhead to invisible access paths. The architecture decision is therefore not about whether CLI is simpler. It is about whether simpler execution erodes the control plane the organisation needs for audit and containment.

Practical implication: reserve CLI batching for tightly controlled environments and keep enterprise-facing access inside governed identity boundaries.

NHI Mgmt Group analysis

MCP is becoming an NHI governance surface, not just a developer protocol. Once agents can discover tools dynamically and invoke them against live systems, access control is no longer a connector issue. The real problem is that every tool becomes an identity decision with audit, scope, and lifecycle consequences. That moves MCP straight into the domain of NHI governance, where identity, privilege, and revocation have to be managed as one operating model.

Static credentials are the clearest example of trust debt in MCP deployments. The protocol may standardise integration, but it does not standardise how credentials are issued, rotated, or revoked. When organisations rely on stored secrets for servers that agents can reach at runtime, they accumulate access that is easy to deploy and hard to govern. The implication is that the control plane has not been solved by the protocol. It has merely been displaced into the credential layer.

Context bloat is an identity problem because tool visibility expands the effective blast radius. The more servers an agent can see, the more actions it can attempt, and the harder it becomes to reason about least privilege at provisioning time. That is especially true when the agent is acting across multiple enterprise systems with different risk profiles. Practitioners should treat exposed tool count as a governance signal, not just an engineering inconvenience.

The MCP decision boundary now sits between scalable integration and governable access. Some workflows belong in MCP because they need structured schemas and policy-aware authentication. Others belong behind narrower interfaces or remain in CLI because the toolset is already understood and the context cost is unjustified. The field needs that distinction because ungoverned standardisation simply creates a uniform attack surface with better packaging.

Context-bloated access paths: this is the named concept that best captures the article’s core lesson. When tool exposure grows faster than governance, the organisation does not just add convenience. It adds reachable action paths that have to be owned, reviewed, and retired like any other privileged identity.

From our research:

• 53% of MCP servers rely on static credentials rather than OAuth, according to The State of Secrets in AppSec.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, according to The State of Secrets in AppSec.
• Related reading: Explore Top 10 NHI Issues for the governance patterns that repeatedly surface when non-human identities scale faster than control.

What this signals

Context-bloated access paths: MCP adoption will keep exposing a familiar enterprise pattern, where integration speed outpaces identity governance and the reachable tool surface grows faster than review cycles can absorb. Teams should expect security reviews to focus less on protocol novelty and more on whether the access path is owned, scoped, and revocable.

The practical signal is that MCP programmes will increasingly be judged by their credential model, not their connector count. Where organisations still depend on static secrets or unmanaged server sprawl, the next phase of maturity is not adding more integrations. It is deciding which integrations deserve policy-backed identity in the first place.

For practitioners

• Inventory every MCP-connected identity path Map which servers, tools, and credentials each agent can reach, then assign an owner for each path. Include developer laptops, shared environments, and production-facing access so you can see where tool reach exceeds accountability.
• Replace static secrets with governed identity flows Wherever possible, move MCP access to OAuth-backed or otherwise federated patterns so credentials can be scoped, logged, and revoked. Treat any stored key in a server config as an unmanaged NHI secret with a lifecycle problem.
• Cap context-heavy tool exposure Reduce the number of tools declared to each session and group low-frequency integrations behind narrower surfaces. If an agent does not need a server for the current task, do not pay the context and governance cost for it.
• Decide which workflows stay outside MCP Keep well-known, batchable, or developer-only tasks in CLI where the control requirements are lighter and the operational model is simpler. Reserve MCP for the integrations that truly need structured schemas, auditability, and policy enforcement.

Key takeaways

• MCP reduces integration complexity, but it also turns tool exposure, credential handling, and auditability into first-class identity problems.
• Static credentials and context bloat are the two clearest signs that MCP adoption has outgrown informal governance.
• Teams that define which tools deserve MCP, which belong behind CLI, and which require policy control will avoid building a uniform attack surface.

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.
• Context bloat: The accumulation of tool definitions, schemas, and metadata in an agent’s working context until reasoning capacity is consumed by exposure rather than task execution. It matters because too many connected tools can reduce performance, obscure intent, and make access governance harder to reason about.
• Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.
• Tool Surface: The tool surface is the set of commands, APIs and connected services an AI agent can invoke at runtime. It is a governance boundary because each tool expands what the agent can do, and therefore expands what an attacker can abuse if they gain control of the runtime.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• The protocol-level comparison between MCP and CLI workflows for different tool shapes and schema complexity.
• The practical MCPorter pattern for batching agent actions into scripts while weighing control trade-offs.
• The evidence base around static credentials, context bloat, and enterprise governance failure modes in live deployments.
• The maturity progression from developer convenience to multi-team tool sprawl and shadow AI.

👉 Obot's full post covers the decision framework for MCP versus CLI, static credential exposure, and enterprise governance patterns.

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 building or maturing an IAM or NHI governance programme, it is worth exploring.