MCP is entering enterprise governance, not just developer adoption

At a glance

What this is: MCP is becoming community-led enterprise infrastructure, and the key finding is that its real governance challenge now sits behind the firewall in identity, token handling, and control-plane design.

Why it matters: IAM, NHI, and platform security teams need to treat MCP as an access pattern, because agent and tool connections can spread identity risk across internal systems far faster than traditional app integrations.

By the numbers:

• MCP reached 110 million SDK downloads per month in sixteen months, a pace that shows how quickly a standard can become infrastructure.
• Claude Code’s earlier MCP implementation consumed roughly one fifth of a 200K-token context window with tool definitions.

👉 Read Obot's analysis of MCP, enterprise identity, and agentic governance

Context

MCP is an open protocol that lets AI applications connect to tools and data sources. In enterprise settings, that turns it into an identity and access problem as much as an integration problem, because every connected server can expand the scope of what an agent can reach.

The article argues that adoption is no longer happening only in public demos. Inside companies, MCP is being wired into Salesforce, Jira, Confluence, Snowflake, internal wikis, and HR systems, which means the governance question now sits squarely inside the firewall. That is where token brokering, audit logging, and server scoping stop being optional.

For teams already thinking about agentic AI, the important point is that MCP becomes useful precisely when it is invisible to users. That invisibility is also what makes lifecycle control, policy enforcement, and access review harder unless the control plane is designed first.

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 MCP environments create new identity governance risk?

A: MCP environments create risk because they connect agents to tools, registries, and data sources through dynamic trust relationships. The governance challenge is that access can expand through tool availability and connection logic, even when the original permission looked narrow. Teams need approval, logging, and review at the tool boundary, not only at authentication.

Q: What breaks when MCP servers expose all tools to every agent session?

A: Overexposure breaks least privilege and makes delegated action harder to contain. If every session sees every tool, the agent can inherit capabilities that exceed the user intent, which increases the chance of unauthorized approvals, deletions, or data access when policy is not checked before execution.

Q: How do teams keep MCP and agentic AI from outgrowing existing IAM controls?

A: They should extend IAM controls into the gateway, where token brokering, policy enforcement, and audit logging can be applied consistently. The key is to govern the session and the tool set together, because agentic systems can change what they touch faster than legacy access review cycles can follow.

Technical breakdown

Cross-app access moves authentication to the identity layer

Cross-app access changes MCP from a repeated OAuth consent flow into a federated access pattern where the identity provider issues the right token without exposing a new login screen each time. That reduces user friction, but it also concentrates trust in the gateway, token broker, and policy layer. In practice, the protocol does not remove authorization decisions. It relocates them to infrastructure that must now distinguish user identity, agent identity, and server-to-server access correctly.

Practical implication: Treat cross-app access as an identity architecture change, not a usability feature, and model the token broker as part of your IAM control plane.

Long-running tasks require session governance, not static permissions

The roadmap’s task primitive for long-running work matters because an agent running for thirty minutes or longer can outlive the assumptions baked into short-lived API calls. A credential that looked appropriate at session start may no longer match the task context by the time the agent reaches later steps. This is a control-plane problem, not just a secrets problem, because the issue is duration, scope drift, and whether the task can keep acting after the original business context changes.

Practical implication: Define expiry, revalidation, and interruption points for agent sessions before you allow long-running MCP workflows into production.

Progressive discovery limits tool exposure and context bloat

The article’s point about progressive discovery is architectural: clients should load tools only when needed instead of dumping every available capability into context. That reduces model load, but more importantly it narrows the blast radius of accidental or malicious tool use. In identity terms, the client should never see tools that were not already in scope for that role or session. This is where tool scoping, role mapping, and gateway policy intersect.

Practical implication: Enforce role-based tool discovery so the agent only receives the minimum tool set required for the active task.

NHI Mgmt Group analysis

MCP is now an identity governance surface, not just a protocol layer. Once MCP moves from demos into Salesforce, Jira, Confluence, Snowflake, and HR systems, the security question shifts from whether tools can connect to who or what is allowed to invoke them. That makes token handling, server scoping, and auditability central to programme design. For IAM and NHI teams, MCP should be treated as governed access infrastructure rather than a developer convenience.

Cross-app access removes friction by collapsing repeated authentication prompts, but it also concentrates trust in the gateway. That is a material change for enterprise control design because the control point becomes the place where policy, brokered tokens, and server eligibility all converge. The implication is that teams need to rethink where the authoritative access decision lives, especially when multiple internal servers share the same identity boundary.

Long-running agent tasks expose a governance gap that traditional short-lived API patterns do not cover. Access review, session duration, and task duration are not the same thing, and MCP pushes them together. Once an agent can continue operating after the original business moment has shifted, identity governance must account for state changes mid-workflow. Practitioners should read that as a sign that static provisioning assumptions are starting to fail.

Progressive discovery is a named control concept worth adopting for agentic systems. It means tools are revealed only when the current task or role needs them, rather than preloading the entire surface into context. That reduces exposure and makes policy enforcement more precise. For practitioners, the lesson is simple: if the agent can see every tool, the protocol is already broader than the job requires.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why our OWASP Agentic Applications Top 10 guide is a useful next step for teams defining tool exposure, autonomy boundaries, and agent oversight.

What this signals

Progressive discovery is becoming a governance requirement, not an optimisation choice. As MCP spreads into production systems, teams that preload every tool into context will create unnecessary exposure and weaker policy boundaries. The architecture should narrow what an agent can see at the moment of use, especially where internal systems carry sensitive data or privileged workflows.

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance problem around MCP is no longer theoretical. That means control planes must assume misuse, not just misconfiguration, and they must be able to show who or what executed each tool call across the lifecycle of the session.

Practitioners should expect agentic access requests to look more like privileged service integration than ordinary app onboarding. That makes least privilege, session scoping, and auditability the core design criteria, and it pushes MCP governance closer to workload identity discipline than to conventional user SSO.

For practitioners

• Map MCP servers to identity-critical assets Inventory every internal MCP server connected to production systems such as CRM, knowledge bases, finance, or HR. Classify each one by the identities it can impersonate, the data it can reach, and whether it is user-facing or agent-facing.
• Put an access broker in front of cross-app access Require token brokering, policy checks, and audit logging at the gateway rather than allowing direct server connections from clients. The goal is to make every MCP request pass through a control point that can enforce server eligibility and record the resulting action.
• Scope tools by role and task Use progressive discovery so an agent only receives the tools needed for the current session or role. Remove any tool definitions that are unrelated to the business task, especially where tools can touch sensitive internal data.
• Set explicit expiry for long-running sessions Define maximum session length, revalidation triggers, and interruption rules for agent workflows that can run for extended periods. If the task context changes, the session should not continue on the original permissions without reassessment.

Key takeaways

• MCP is becoming enterprise identity infrastructure, so the main risk is no longer adoption but governability.
• Cross-app access and long-running tasks shift the control burden to gateways, token brokers, and session policy.
• Teams that scope tools by role and task will have a better chance of containing agentic access before it becomes sprawl.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• 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.
• Progressive Discovery: A tool-loading pattern that reveals capabilities only when a task needs them. For MCP and agentic systems, it reduces context bloat and limits unnecessary exposure, which makes the active permission set smaller and easier to govern.

What's in the full article

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

• David Soria Parra’s keynote framing for the MCP roadmap and why the community expects enterprise-grade control patterns.
• The June spec revision details for cross-app access, including how token issuance and user experience are expected to change.
• More explanation of the proposed task primitive for long-running work and how server-initiated triggers affect enterprise workflows.
• The practical discussion of skills over MCP and how that changes tool use inside internal servers.

👉 Obot's full article covers the MCP roadmap, cross-app access, and the enterprise control-plane questions behind agentic adoption.

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