Topic starter
06/11/2026 6:36 pm
TL;DR: The explanation of the Model Context Protocol shows how MCP reduces repeated integration work by giving AI assistants a shared way to connect to tools and data, while leaving authentication, approvals, logging, and server security under local control, according to Serval. The protocol simplifies connection sprawl, but it does not remove the governance burden around what an assistant may do.
Editorial analysis by NHI Mgmt Group, based on content published by Serval: “MCP benefits for IT teams juggling dozens of systems”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP lowers the cost of connecting assistants to enterprise systems, but it leaves access policy and approval logic unchanged.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP reduces integration sprawl, but governance stays manual