Enterprise MCP governance is now mandatory for scaled AI agents

At a glance

What this is: This keynote argues that enterprise MCP needs a central governance layer because large AI agent estates create tool sprawl, inconsistent access, and unmanageable lifecycle complexity.

Why it matters: It matters because IAM, NHI, and platform teams now have to govern how agents discover, authenticate to, and use tools across hundreds or thousands of services.

By the numbers:

• Uber described more than 1,500 monthly active agents built across the company.
• 90%+ of its 5, + of its 5,000+ engineers use AI tools monthly.

👉 Read Obot's analysis of Uber's enterprise MCP governance model

Context

MCP, or Model Context Protocol, is a standard interface that lets AI agents connect to tools and services without bespoke integrations for every system. At enterprise scale, the governance problem is not whether agents can reach tools, but how access, discovery, and usage are controlled across many services and teams.

The article uses Uber as an example of why this matters when agent adoption is broad and service estates are fragmented. The underlying identity question is simple: who or what is authorised to invoke which tools, under what conditions, and with what visibility?

For IAM and NHI programmes, the lesson is that protocol standardisation and identity governance now overlap. MCP becomes part of the control plane for non-human access, not just an integration convenience.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do MCP environments create new identity governance problems at scale?

A: MCP environments multiply access paths as more agents and servers are added, which makes direct point-to-point governance brittle. Each new endpoint adds another authentication pattern, another routing decision, and another audit dependency. Without central control, identity policy fragments faster than operations can manage it.

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: What should IAM teams do before scaling agent-to-tool integrations?

A: Set guardrails around mutable endpoints, require telemetry for each invocation, and define which teams can add or change tools. Then align the MCP gateway with your existing access review and logging processes so non-human access is treated as governed identity, not just application traffic.

Technical breakdown

MCP as a control plane for agent tool access

MCP gives agents a consistent way to discover and invoke tools, replacing one-off integrations with a standard interface. That consistency matters because tool access is no longer just an application integration issue. It becomes an identity problem: the agent needs authenticated, authorised, auditable access to specific capabilities, not broad implicit reach. A mature MCP gateway therefore sits between agents and services to mediate which tools are exposed, how parameters are handled, and what actions are allowed.

Practical implication: treat MCP gateways as governance infrastructure and subject them to the same access review and logging expectations as other NHI control points.

Why registry and lifecycle controls matter for MCP servers

A registry creates a source of truth for available MCP servers, versioning, and discovery, which helps prevent uncontrolled sprawl. Without that layer, teams create duplicate servers, drift in tool definitions, and inconsistent security posture across similar functions. Lifecycle control is equally important because MCP servers change, retire, and get replaced. If those transitions are unmanaged, agents can keep invoking stale or unsafe tools long after the underlying service has moved on.

Practical implication: require inventory, ownership, and retirement processes for every MCP server the same way you would for NHI accounts or APIs.

Why observability and guardrails are part of identity governance

Observability in an MCP environment is not only for troubleshooting. Logging, metrics, tracing, redaction, and rate limits provide evidence of what an agent actually did and whether a tool invocation crossed policy boundaries. Guardrails that block mutable endpoints or require extra scrutiny for sensitive actions are especially important when the same agent can access many services. In practice, the security model depends on knowing not just that an agent connected, but exactly which tool, parameter, and operation it used.

Practical implication: require per-tool telemetry and policy enforcement so agents cannot operate as opaque consumers of enterprise services.

Threat narrative

Attacker objective: The objective is to gain unauthorised or excessive agent-mediated access across enterprise services while avoiding clear accountability and detection.

1. Entry occurs when agents connect to multiple services through a standard protocol without a central governance layer to control what is exposed and discoverable.
2. Escalation occurs when tool sprawl, inconsistent definitions, and weak lifecycle control let agents reach more services than intended or continue using stale capabilities.
3. Impact occurs when the enterprise loses visibility into agent actions, creating unmanaged access, policy drift, and audit gaps across the tool estate.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 governance is becoming the non-human access layer for enterprise AI. Once agents use a common protocol to discover and invoke tools, the governance question shifts from integration to entitlement. That means identity teams have to think about tool exposure, parameter control, and auditability as first-class access decisions, not technical implementation details. The practical conclusion is that MCP cannot be managed as a developer-only convenience if it is touching enterprise data or action paths.

Version drift in MCP servers is an identity problem, not just an engineering problem. When tool definitions, owners, and deployment states are inconsistent, the enterprise no longer knows what an agent is authorised to do today versus last week. That breaks the assumptions behind reviews, attestation, and lifecycle offboarding because the access surface is changing faster than governance can track it. The practical conclusion is that registry hygiene and retirement discipline are now governance controls.

Identity blast radius expands when one agent can traverse many services through a single protocol. Standardisation reduces integration complexity, but it also creates a wider shared access pattern if the protocol layer is not constrained. That is why control boundaries need to move closer to the protocol gateway, where tool-level policy, redaction, and logging can actually contain misuse. The practical conclusion is that least privilege must be expressed at the MCP tool level, not only at the service boundary.

Skills registries and evaluators point to the next governance problem: reusable agent behaviour. Once organisations start packaging multi-tool skills, they are no longer just controlling access, they are controlling repeatable action sequences. That raises the bar for assurance because the question becomes whether a skill should be available, how it behaves across contexts, and whether its output remains correct over time. The practical conclusion is that skill governance will need its own approval, testing, and revocation lifecycle.

Standardised agent access will force IAM, platform, and security teams to share responsibility. MCP sits across identity, application, and AI operations, so no single team can own the full control surface. The field is moving toward central policy with distributed implementation, which is the only practical way to keep scale from becoming sprawl. The practical conclusion is that enterprise MCP programmes need a named owner, a registry, and a policy model before agent counts grow further.

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.
• Only 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 gap is why OWASP Agentic Applications Top 10 remains useful as a forward-looking control lens for agent discovery, tool use, and policy enforcement.

What this signals

Identity blast radius: once agents can invoke many services through a shared protocol, the governance problem shifts from single-account control to tool-level containment. Teams should expect existing access review rhythms to miss fast-changing tool exposure unless MCP registry data and policy state are built into IAM operations.

The operational signal is that AI agent scale will keep increasing faster than review capacity unless discovery, logging, and change control are automated. That means platform teams need a control model that can absorb new tools, new skills, and new execution paths without turning every agent into a bespoke governance exception.

With 92% of organisations saying governing AI agents is critical but only 44% having implemented policies, the gap is not awareness. The programme risk is that agent access is already becoming production-grade before the governance layer is mature enough to support it.

For practitioners

• Define MCP tool ownership and approval boundaries Assign a named owner for every MCP server, every exposed tool, and every change path that can modify access or parameters. Require explicit approval for new tool exposure, mutable actions, and third-party MCP additions.
• Build a central MCP registry with lifecycle states Track active, deprecated, and retired servers in one source of truth so agents do not continue to call stale definitions or orphaned tools. Include versioning, environment, and service-owner metadata.
• Enforce tool-level logging and redaction Capture tool name, parameters, response class, and decision outcome for every invocation, and redact sensitive fields before logs are retained or forwarded. Use the log trail for review and incident investigation.
• Constrain mutable endpoints and high-risk writes Block or step up protection for tools that can change records, permissions, or downstream configuration. Separate read-only discovery from write-capable actions wherever possible.

Key takeaways

• Enterprise MCP turns AI agent connectivity into an identity governance issue because tool access, discovery, and lifecycle control all affect who can do what.
• Scale data from Uber shows why this matters now: thousands of agents, tens of thousands of weekly executions, and a large service estate create an access surface that manual governance cannot follow.
• The practical response is to govern MCP through registry discipline, tool-level policy, and auditable logs before agent sprawl hardens into unmanaged access.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools and data sources through a standard interface. In identity terms, it creates a governable access path for non-human actors, which means tool exposure, authentication, and logging become security controls rather than implementation details.
• 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.
• 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.
• Skills Registry: A catalog of reusable multi-tool workflows that an agent can invoke to complete a task. It extends governance from single tool access to packaged action sequences, which means evaluation, approval, and revocation need to follow the skill itself, not just the underlying tools.

What's in the full article

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

• The full architecture of Uber's MCP Gateway and Registry, including the IDL crawler workflow and definition generator.
• How service owners enable tools, tune descriptions, and route changes through code and security scanning.
• The specific way Uber handles auto-auth, PII redaction, observability, and write-operation guardrails.
• The Skills Registry roadmap, including evaluations, SLA metadata, and dynamic discovery on demand.

👉 Obot's full post covers the gateway architecture, registry design, and skills roadmap in more operational detail.

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