MCP rollout is an API governance problem, not a protocol project

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Archestra's blog post: The real challenge in a four-week MCP rollout is governing internal API access inside AI sessions, not standing up the protocol itself.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat MCP as a governed access path with audit, approval, and lifecycle controls, not as a standalone integration project.

Context

MCP adoption exposes a governance gap that most identity programmes already know well: the system is not hard because it exists, but because it creates a new way to expose internal APIs to a non-deterministic client inside an AI session. The primary question is who can reach which tools, under what conditions, and with what evidence.

That makes the rollout an identity and access problem before it is a protocol problem. The article frames the work as deciding ownership, scopes, logging, and approvals around MCP security rather than treating the server itself as the centre of the project.

Key questions

Q: What should security teams govern first in an MCP rollout?

A: Start with API ownership, data sensitivity, and the destructive actions each endpoint can trigger. MCP is not a blank-slate protocol. It is a new access path to existing systems, so governance has to begin with who may reach which tools, under what conditions, and with what audit evidence.

Q: Why does MCP gateway governance matter for access control decisions?

A: Because the gateway is where tool invocation is actually approved or denied, and that decision sits closer to runtime action than the original login. If access is granted only at the identity layer but not at the tool layer, the organisation loses control over what the model can do.

Q: How should teams handle authorisation beneath an MCP layer?

A: They should treat the MCP server as a translation layer, not a trust boundary. The wrapped APIs still need object-level authorisation, least privilege, and confusion-resistant identity checks, because an autonomous agent can otherwise use a valid tool path to reach data or actions it was never meant to access.

Q: How do you know an MCP rollout is ready for broader access?

A: Look for boring behaviour in the pilot: tool selection should be predictable, auth failures should be explainable, and logs should show user, tool, arguments, and result consistently. If those signals are not stable in a small internal test, scaling the rollout will only multiply the same governance gaps.

Technical breakdown

Why MCP rollout starts with API governance

MCP is a transport and authorisation wrapper around existing internal APIs, so the control problem stays familiar even if the client changes. The AI model is non-deterministic, which means the request path may vary from one session to the next, but the organisation still has to define the same fundamentals: which API is exposed, who can reach it, what the blast radius is, and what gets logged. That is why inventory and scoping come before implementation. The hardest mistake is assuming MCP creates a new category of trust, when in practice it reuses the same identity, scope, and audit questions that already govern API access. Practical implication: start with API ownership, sensitivity, and destructive action mapping before any server build.

Practical implication: Map each candidate MCP use case to the owning team, the data it touches, and the destructive actions it could trigger before implementation.

Why a gateway changes the control plane for MCP

A gateway in front of MCP servers centralises the controls that would otherwise fragment across multiple servers. In this pattern, unified authentication, audit logging, namespace filtering, credential injection, and version pinning become the shared policy layer for every tool request. That matters because the security team is not really reviewing one server, but the policy surface that sits between the model and internal systems. Without a gateway, every new server becomes a new place to implement the same controls, which increases inconsistency and audit friction. The gateway does not solve the governance problem by itself, but it creates a single place to enforce and observe it. Practical implication: treat the gateway as the policy enforcement point, not as a simple routing layer.

Practical implication: Use a gateway as the single enforcement point for authentication, logging, filtering, and credential handling across MCP servers.

How delegated auth changes the identity model for MCP

The article separates basic SSO and audit from delegated authorisation, which is a useful operational distinction. SSO answers who entered the gateway, but delegated auth answers what the session may do on behalf of that user across downstream tools. That is the same architectural problem identity teams face with on-behalf-of flows in other systems, only now it is tied to tool selection and session context inside an AI interaction. The result is that scope, audience, and approval boundaries become governance decisions, not implementation details. Enterprises should expect this to touch IdP configuration, policy design, and lifecycle review for privileged access paths. Practical implication: postpone delegated auth until the base authentication and audit model is stable, then evaluate on-behalf-of with identity governance in mind. See the NHI Authentication Guide.

Practical implication: Introduce delegated access only after the base session, audit, and scope model is stable enough to govern consistently.

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 turns API governance into a session-time identity problem. The article is correct to reject the idea that MCP is mainly a protocol rollout. What changes is the context in which APIs are consumed: access now occurs inside an AI session where the client is non-deterministic and the human requester cannot directly inspect every action. That shifts governance from static integration approval to runtime control over scope, evidence, and tool use. Practitioners should treat MCP as a governed access path, not a new class of application.

Gateway centralisation is the real control boundary. Once MCP traffic is funnelled through a gateway, the security posture depends on whether that layer actually enforces policy or merely forwards requests. Unified auth, structured logs, namespace filtering, and credential injection are not convenience features. They are the controls that make auditability and containment possible when multiple tools sit behind the same session. This is where teams should stop thinking in terms of individual servers and start thinking in terms of a single control plane for identity and tool access.

The governance assumption is that access can be pre-scoped at provisioning time. That assumption was designed for stable, human-readable workflows and predictable application calls. It fails when the actor is a model that can choose among tools dynamically during a session, because the exact path of access is not fully known until runtime. The implication is not merely tighter policy. It is a rethink of how identity, request context, and approval boundaries are expressed for AI-mediated access.

Enterprise-managed authorisation is the right frame for delegated MCP access. The article's emphasis on SSO first, delegation later, and approval by security, legal, and IT is the right sequencing model. That sequencing matters because MCP introduces a new place where identity, data residency, retention, and joiner-mover-leaver logic intersect. If those controls are not aligned early, the organisation will end up debating exceptions instead of governing a stable access model. Practitioners should make delegated auth an identity design decision, not an integration afterthought.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Access reviews will not govern MCP on their own: the more dynamic the AI session, the less useful a periodic review becomes as the primary control. Teams need to shift some of that governance to issuance time, gateway policy, and per-request evidence, because the session itself becomes the unit of risk.

The most durable operating model will be the one that treats MCP as an extension of existing IAM, PAM, and audit controls rather than as a separate programme. That alignment matters because the real question is not whether a model can call a tool, but whether the organisation can prove and constrain that call inside normal identity governance.

For practitioners

• Inventory candidate APIs before building anything List the internal APIs that users want AI to act on, then record the owner, current auth model, destructive endpoints, and business impact of a bad call.
• Place every MCP server behind a gateway Use a single gateway for unified auth, structured audit logs, namespace filtering, credential injection, and version pinning instead of exposing servers directly.
• Delay delegated auth until the base model is stable Get SSO and audit working first, then evaluate on-behalf-of flows and downstream scopes once the organisation has a reliable evidence trail.
• Run an internal pilot before external exposure Start with ten internal users, one server, and one week of testing so you can measure wrong tool selection and auth failures before broader rollout.

Key takeaways

• MCP rollout should be governed as an access and audit problem, with API ownership and sensitivity defined before any server goes live.
• A gateway becomes the main control boundary because it centralises authentication, logs, filtering, and credential handling across servers.
• Delegated authorisation belongs later in the sequence, after SSO and audit are stable enough to support consistent governance.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Zero Trust for AI Agents · Zero Trust Identity Guide

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.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
• Tool Filtering: Tool filtering is the practice of exposing only a selected subset of tools from a larger MCP environment. It helps reduce context bloat, lower token waste, and prevent an AI client from seeing or using capabilities that are not needed for a specific team, workflow, or access boundary.
• Interaction-Level Audit Trail: A record that captures the full AI session rather than only network traffic or file events. It ties the prompt, model response, identity, and policy response together so auditors can reconstruct what happened and why the control acted the way it did.

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