MCP reduces integration sprawl, but governance stays manual

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Serval's blog post: Model Context Protocol reduces repeated integration work for AI assistants, but authentication, approvals, and server-side governance still determine safe use at enterprise scale.

Why it matters: IAM, ITSM, and security teams need to treat MCP as a connection model, not an access-control layer, because the protocol can speed integration without replacing permissioning, approval routing, or auditability.

Context

Model Context Protocol is a shared interface that lets AI assistants reach external systems through a standardised connection pattern instead of one-off integrations. That matters because the control problem shifts from building connectors to governing what each assistant may request through those connectors. For teams already running multiple systems and assistants, the issue is not just technical reuse but MCP security and access control at scale.

The governance gap appears when the same assistant can look up status, request access, or trigger workflows across different tools. Existing IAM and ITSM controls still have to decide who can approve, what the assistant can invoke, and how actions are traced back to the initiating identity. Standardisation reduces integration churn, but it also concentrates risk if server permissions are loose.

Key questions

Q: How should teams govern access to context exposed through MCP servers?

A: Treat MCP exposure as a governed entitlement problem, not a simple integration task. Teams should define who can discover context, who can consume it, and under what policy conditions, then enforce those rules consistently across gateways, registries, and downstream orchestration layers.

Q: What is the difference between MCP transport and access control?

A: MCP transport is the communication layer that moves messages between an agent and a host, such as stdio, HTTP or another channel. Access control decides which tools, data sets or actions the agent may use once connected, usually through authentication, authorisation, scoped tokens or policy checks. Transport can be open while access remains tightly constrained.

Q: How can shared AI assistants create governance risk in IT workflows?

A: Shared AI assistants create governance risk when multiple users rely on the same agent, session or credential set and the assistant can act across IT workflows with mixed authority. That makes it harder to attribute actions, enforce least privilege, separate approvals from execution and revoke access cleanly when a user or workflow changes.

Q: What should security teams do first before allowing agents to trigger workflows?

A: Start by identifying which sources, definitions, and ownership records the workflow depends on, then require those controls to be current and machine-readable before the agent can run. If the context cannot be trusted, the workflow should not proceed.

Technical breakdown

How MCP clients and servers exchange tool calls

MCP splits the interaction into a client inside the AI application and a server that exposes tools, resources, and prompts. The client discovers what the server offers, then sends a structured request such as a JSON-RPC message with the tool name and required inputs. The server executes the action against the underlying system and returns the result. That architecture matters because the assistant does not directly act inside the target system; the server mediates the request and response path, which becomes the enforcement point for permissions and validation.

Practical implication: Treat the MCP server as the control boundary and verify that it enforces caller permissions before any tool executes.

Why reusable integrations change the governance burden

Point-to-point integrations create a maintenance burden because every assistant-system pairing needs its own connector. MCP replaces that repetition with a reusable server interface, which lowers engineering effort but also makes the server a shared dependency across teams and assistants. The technical consequence is centralisation: more consumers depend on the same tool surface, so mistakes in server authorisation, input handling, or audit logging can affect many workflows at once. The protocol standardises transport and discovery, not policy logic.

Practical implication: Design MCP server policy as if multiple assistants will reuse it immediately, because shared reuse expands the blast radius of a weak permission model.

How access requests and workflow triggers should be bounded

MCP can carry requests such as access lookups, JIT approval flows, or workflow starts, but the underlying system still has to decide whether the action is permitted and whether an approval step is required. In practice, the assistant supplies intent, while the server and target application enforce scope. That distinction is important because status queries, workflow initiation, and remediation actions are not equivalent from a security standpoint. A system that lets an assistant inspect or submit requests should not automatically let it complete the final privileged step.

Practical implication: Separate read-only actions from approval-gated actions so an assistant can assist without inheriting unrestricted execution rights.

Threat narrative

Attacker objective: The objective is to turn a legitimate assistant connection into a path for unauthorised tool use, request manipulation, or workflow execution.

1. Entry occurs when an assistant gains a valid connection to an MCP server and can enumerate available tools and inputs.
2. Escalation can follow if the server authorises more actions than the caller should have, allowing the assistant to invoke sensitive tools through ordinary requests.
3. Impact appears when the assistant can submit or trigger workflows that should have remained approval-gated, creating unintended changes across connected systems.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.

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 is an integration standard, not an authorisation model: The protocol makes it easier for assistants to reach tools, but it does not decide which actions are safe, approved, or reversible. That means governance stays anchored in the server, the identity layer, and the underlying application permissions. Organisations that treat protocol adoption as a control substitute will overestimate the security benefit and underestimate the policy work still required.

Shared interfaces create shared risk concentration: Reusable MCP servers reduce the number of bespoke connectors, but they also concentrate authority into a smaller set of tool surfaces. If one server exposes access requests, ticket changes, and workflow execution, the permission model behind that server becomes strategically important. Practitioners should think of MCP reuse as a force multiplier for both efficiency and misconfiguration.

Approval boundaries matter more when assistants can initiate work: A tool that only retrieves status is not equivalent to a tool that starts onboarding, changes roles, or submits access requests. The governance assumption that “the system will only do what a human explicitly asked in context” weakens once an assistant can initiate the workflow path itself. That is why permission scope, logging, and approval routing need to be designed around action classes, not just around tool availability.

Runtime control has to follow the identity, not the interface: MCP standardises how requests are carried, but it does not erase the underlying question of who is acting and with what delegated scope. If multiple assistants can use the same server, then identity binding, token scope, and audit attribution determine whether the organisation can tell one assistant from another. Practitioners should govern the assistant, not just the endpoint it calls.

Prompt injection is only one failure mode in a larger governance problem: The more important issue is whether an MCP server permits an assistant to do more than the business process intended. Tool poisoning and prompt manipulation matter, but the deeper control gap is excessive tool privilege exposed through a convenient interface. The named concept here is shared server authority: when many assistants reuse one server, server policy becomes the effective access-control plane and must be treated accordingly.

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

Shared server authority: As MCP reuse spreads, the real governance question becomes who owns the policy surface behind each server. Teams that centralise assistant access without centralising permission design will create a single control point that is easy to integrate and easy to misuse.

MCP will push identity teams to think less about connector building and more about tool-class governance, approval routing, and audit attribution. The practical shift is from integration sprawl to reusable enforcement points, which is exactly where access scope mistakes become harder to spot and easier to repeat.

The protocol can help standardise assistant connectivity, but it does not remove the need to verify whether a given action is request, approval, or execution. That distinction will matter most when assistants start operating across shared systems that already have human, service, and workflow identities in play.

For practitioners

• Define tool classes by risk level Separate read-only lookups, request submission, and state-changing actions into distinct policy buckets so one assistant cannot inherit a broader privilege set than the process allows.
• Bind assistant identity to server permissions Require each assistant to authenticate with scoped credentials that reflect its role, tenant, and approved use case, then validate every tool call against those scopes.
• Preserve approval gates for privileged workflows Keep human approval in place for access changes, onboarding, and remediation workflows even when an assistant can start them through MCP.
• Log initiator, tool, and outcome together Record which assistant initiated the request, which tool was called, what inputs were supplied, and what the underlying system returned so investigations can reconstruct the full chain.
• Test server behaviour before broad reuse Exercise each MCP server with low-risk and high-risk prompts to confirm that the server rejects overbroad requests, strips unsafe inputs, and preserves existing approval rules.

Key takeaways

• MCP lowers the cost of connecting assistants to enterprise systems, but it leaves access policy and approval logic unchanged.
• The main control issue is server-side authority, because a shared interface can concentrate too much privilege behind one reusable connection.
• Practitioners should separate lookup, request, and execution paths so assistants can help without acquiring broader operational power.

Related NHI Mgmt Group resources: MCP Security Guide · OWASP Agentic Applications Top 10 · IAM and Identity Provider Buyer's Guide · Identity Provider and SSO Security Guide

Key terms

• 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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Mcp Client: An MCP client is the application or agent that connects to a Model Context Protocol server to request tools, data, or prompts. It manages the session, sends structured requests, and receives responses in a standard format. In identity terms, it is the calling party that may need authentication, authorization, and audit controls.
• Tool Call ID: Tool Call ID is the identifier attached to a specific call from an AI agent to a tool or function. It lets the system correlate the request, the tool response, and the agent turn, which helps with tracing, debugging, and access audit of tool use.

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