MCP is entering enterprise governance, not just developer adoption

At a glance

What this is: MCP is shifting from developer tooling into enterprise infrastructure, and the core finding is that governance now matters as much as adoption.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as a control-plane problem because token issuance, auditability, and server scoping become enterprise requirements once agents touch production systems.

By the numbers:

• MCP reached 110 million SDK downloads per month in sixteen months.

Context

MCP is a protocol for connecting AI agents and applications to tools and data sources. In enterprise use, that makes it an identity and governance problem, not just a developer convenience, because each connection introduces authorization, audit, and lifecycle decisions that security teams have to own.

Obot argues that the real deployment surface is inside corporate environments, where MCP servers are wired into Salesforce, Jira, Confluence, Snowflake, internal wikis, and HR systems. That changes the control question from whether MCP is useful to whether access, token handling, and policy enforcement are being governed with the same discipline as any other production integration.

The article frames 2026 as the year when MCP must support production agentic systems at enterprise scale. That is a typical progression for a widely adopted integration layer: once adoption crosses internal tooling into business systems, the identity model becomes part of the operating model.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do long-running agent tasks increase identity risk in MCP deployments?

A: Long-running tasks increase identity risk because the work window and the credential window can diverge. If a task keeps running after the token or approval that authorised it becomes stale, the control plane loses synchronisation with runtime behaviour. That creates drift, especially where agents touch multiple systems and no one is watching the continuation path.

Q: What breaks when MCP servers are added without a gateway?

A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow. The hidden failure is that each new server expands the trust boundary and the blast radius. Without a gateway, teams usually discover the problem only after a server has already been wired to credentials and internal tools.

Q: How should identity teams govern MCP compared with conventional API integrations?

A: MCP needs runtime identity governance because it is not just a transport layer for requests. Conventional integrations can often be reviewed at design time, but agentic workflows require control over context, delegated authority, and the lifecycle of the credentials that power each tool path.

Technical breakdown

Cross-app access shifts authentication into the identity layer

Cross-app access changes the user experience by removing repeated OAuth prompts, but the deeper shift is architectural. Instead of every MCP server running a separate, user-visible auth flow, the server receives the right token through the identity provider. That centralises authentication, but it also increases the importance of token brokering, server scoping, and policy enforcement at the gateway or control plane. In practice, the risk does not disappear. It moves from the client edge into the identity layer, where entitlement decisions and auditability must be consistent across every connected server.

Practical implication: treat cross-app access as an identity architecture change, not a usability feature.

Long-running tasks create fresh credential lifetime pressure

MCP’s move toward long-running tasks matters because the protocol is no longer only carrying short, synchronous requests. Once agents can work for thirty minutes or longer, the question becomes whether credentials, scopes, and approvals remain valid for the full task or expire mid-execution. That is a classic NHI governance issue: the access window and the task window no longer line up neatly. If the control plane assumes the work will finish quickly, it will miss drift, stale tokens, and unreviewed continuation paths.

Practical implication: align token lifetime, task duration, and policy checks before allowing multi-step agent work.

Triggers and skills widen the authorization surface

Triggers make MCP servers proactive rather than purely request driven, while skills bundle instructions for how tools should be used. Together they expand the surface from simple tool access to tool selection, sequencing, and context sharing. That matters because the system is no longer just exposing a connector. It is shaping runtime behaviour and deciding when the client should act. For security teams, that means the policy model must account for event-driven initiation, role-specific tool visibility, and the possibility that a server is influencing execution timing as well as access.

Practical implication: govern event-driven access and tool surfacing as separate controls, not one combined permission.

Threat narrative

Attacker objective: The objective is to exploit weakly governed MCP connections to gain persistent, hard-to-audit access through trusted enterprise integrations.

1. Entry occurs when agents or users connect MCP servers to enterprise systems such as Salesforce, Jira, Confluence, or Snowflake.
2. Credential access and control dependence emerge as tokens, OAuth flows, and gateway decisions determine which server can act on behalf of which identity.
3. Impact follows when production integrations proliferate without consistent audit logging, server scoping, or lifecycle governance, creating unmanaged access paths across business systems.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is now an identity problem, not an integration problem. Once a protocol becomes the default layer for connecting agents to business systems, the question shifts from connectivity to who can authorise, observe, and revoke those connections. That is why the enterprise use case belongs in IAM, PAM, and NHI governance conversations, not only architecture reviews. Practitioners should treat MCP as part of the identity fabric, not a side channel.

Cross-app access exposes the control gap that too many enterprises already have. The promise is fewer prompts and cleaner user experience, but the security consequence is that token brokering and policy enforcement become invisible until they fail. When authentication disappears from the front end, the control plane has to carry the burden of segmentation, audit, and entitlement boundaries. The practitioner takeaway is that invisible authentication still needs visible governance.

Long-running agent tasks create an identity lifecycle mismatch. Access review processes assume access persists long enough to be reviewed; agentic workflows can acquire and release privileges within a single work cycle. That means the classic joiner-mover-leaver model does not fully describe runtime access for agents and workloads. The implication is a named runtime governance gap: the control that certifies standing access is being asked to govern ephemeral execution.

Skills and triggers turn MCP servers into policy-bearing actors. A server that can teach an agent how to use tools, and notify it when to act, is no longer just an API surface. It is participating in execution decisions and shaping the order of operations. That widens the governance question from permissioning to behavioural boundaries, especially when enterprise operators assume the server only exposes capabilities. Practitioners should rethink where instruction, initiation, and authorisation separate.

Protocol adoption without a control plane creates identity blast radius. When MCP spreads across internal knowledge systems and business applications faster than governance matures, every new connection expands the number of places where identity, audit, and approval can fail. The issue is not MCP itself, but the assumption that adoption can outrun control design. Security teams should expect this pattern to look like every other rapid platform shift: convenience first, governance debt second.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

MCP is becoming a governance surface for agentic systems. As more enterprises wire MCP into internal business applications, the operating model has to shift from project-based integration to identity-controlled infrastructure. Teams that already struggle to govern service accounts and API tokens will feel the same pressure here, only faster because agent runtime is more dynamic than traditional workloads.

Runtime control will matter more than static approval. MCP’s roadmap points toward long-running tasks and server-initiated triggers, which means the decisive control is not whether access was granted once, but whether it is still valid when action occurs. That is a stronger fit for NHI lifecycle governance than for one-time entitlement review alone.

For practitioners

• Establish MCP gateway enforcement Centralise token issuance, server allowlisting, and audit logging at a control plane that can scope which identities may connect to which MCP servers.
• Map agent task duration to credential lifetime Review whether long-running agent work can outlast the tokens and approvals it depends on, then block execution paths that can continue on stale credentials.
• Separate tool visibility from tool execution Use role-based scoping so clients only discover the tools they are allowed to use, and so the server cannot implicitly broaden access through discovery.
• Classify internal MCP servers by business criticality Inventory the servers connected to enterprise data and systems, then assign ownership, review cadence, and revocation rules based on the sensitivity of the data they can touch.

Key takeaways

• MCP is no longer just a developer protocol. In enterprise use it becomes a governance problem because every connection creates a new identity decision, a new audit requirement, and a new revocation path.
• The most important shift is away from visible user prompts and toward control-plane enforcement. That changes where security teams need to focus their effort.
• Long-running tasks, triggers, and skills make access timing, tool exposure, and server initiation part of the risk model, so governance has to move closer to runtime behaviour.

Key terms

• Cross App Access: An ecosystem name for IdP-mediated app-to-app authorization in enterprise environments. It allows an identity provider to approve or deny AI app connections centrally, reducing hidden delegation and making downstream access revocable from one place instead of inside every connected tool.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• Long-running task: A long-running task is an execution pattern where an agent or workload continues operating over an extended period rather than completing a single request-response cycle. For identity governance, that matters because access decisions, token lifetime, and revocation timing must stay aligned with ongoing runtime behaviour.
• Trigger: A trigger is the condition that starts an automated workflow. It can be time based, event based, or initiated on demand. In a security operations setting, triggers control when an agent reviews a queue, writes a report, routes a case, or performs another predefined action.

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.