Notifications
Clear all
Topic starter
19/08/2026 3:54 pm
TL;DR: The N×M integration problem is reduced by MCP, according to Obot’s analysis, but it also creates new governance pressure through context bloat, static credentials, and rapidly expanding agent tool access. The core issue is no longer whether MCP works, but whether enterprise identity and access controls can govern it safely at scale.
NHIMG editorial — based on content published by Obot: LLMjacking and MCP governance analysis across context bloat, static credentials, and agent tool access
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every MCP-connected identity path Map which servers, tools, and credentials each agent can reach, then assign an owner for each path.
- 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.
- Cap context-heavy tool exposure Reduce the number of tools declared to each session and group low-frequency integrations behind narrower surfaces.
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.
👉 Read Obot's analysis of MCP architecture, context bloat, and governance risk →
MCP context bloat and static credentials: where do controls break down?
Explore further
19/08/2026 4:31 pm
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.
A few things that frame the scale:
- 53% of MCP servers rely on static credentials rather than OAuth, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, according to The State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: MCP governance is becoming an identity problem, not just an integration one
