MCP in the enterprise: Model Context Protocol, specification 2026-07-28 and security

Connecting AI agents to your ticket system, wiki or ERP, with clear permissions? WZ-IT builds agents and internal assistants on your own infrastructure: a tool catalogue instead of full access, delegated identities, approvals for critical steps and logging of every run. Explore AI agents · Internal AI assistants · Book a call

The Model Context Protocol (MCP) is an open standard through which AI applications access tools and data sources. An MCP server built once for a ticket system works in every client that speaks MCP and survives a change of language model. For companies, MCP is therefore an integration layer, and like every integration layer it raises questions of identity, permissions and attack surface. This article explains the architecture and transports, summarises the 2026-07-28 specification, covers authorization and describes risks and operation with local models. As of October 2026.

Table of contents

• What MCP is: host, client, server
• Transports: stdio and Streamable HTTP
• Specification 2026-07-28: what has changed
• Authorization: OAuth 2.1 and identity providers
• MCP with local models and Open WebUI
• Risks: tool poisoning, stdio and tokens
• Permissions and approvals in operation
• When MCP makes sense and when an API is enough

What MCP is: host, client, server

MCP is an open protocol based on JSON-RPC 2.0. The specification names the Language Server Protocol as its model: just as LSP connects programming languages to editors in a uniform way, MCP connects tools and context to AI applications (MCP specification 2026-07-28). Anthropic released the protocol on 25 November 2024 and contributed it on 9 December 2025 as a founding project to the Linux Foundation's Agentic AI Foundation.

A server offers three kinds of capabilities:

The benefit is decoupling. Without a standard, every combination of AI application and target system needs its own integration. With MCP you write the server once, and every MCP-capable host can use it. The language model itself does not speak MCP: the host translates the tool list into the model's tool-calling interface and executes the calls.

Transports: stdio and Streamable HTTP

The specification defines two standard transports (MCP, Transports). The choice determines the operating model and the attack surface.

For Streamable HTTP, the specification requires servers to validate the Origin header and respond with 403 to an invalid value, to prevent DNS rebinding. Locally running servers should bind only to 127.0.0.1, not to all interfaces (MCP, Streamable HTTP). The older HTTP+SSE transport from version 2024-11-05 is deprecated and should be migrated.

In a company, Streamable HTTP is the normal case for shared servers: one service, one identity, central logging. stdio suits developer tools on one's own machine.

Specification 2026-07-28: what has changed

Revision 2026-07-28 was released on 28 July 2026 and replaces 2025-11-25 (announcement, changelog). It turns MCP from a stateful into a stateless request/response protocol.

For operators, the removal of sessions has the most consequences. An MCP server that tied state to a session must now model it with handles. The security best practices state that possessing a handle must never count as authentication and that handles should be bound server-side to the authenticated user. According to the announcement, the official SDKs for TypeScript, Python, Go and C# support the new version, the Rust SDK as a beta. Clients that need to keep supporting older servers can detect the counterpart's generation and fall back to the previous handshake.

Authorization: OAuth 2.1 and identity providers

Authorization is optional in MCP. Where an HTTP-based server implements it, it follows an OAuth 2.1 profile (MCP, Authorization). The MCP server acts as resource server, the host as OAuth client, and the token is issued by an authorization server, in a company typically the existing identity provider such as Keycloak.

Issuer validation is deliberately graded: if an authorization server advertises iss in its metadata and the value is missing from the response, the client must reject it. The specification announces a future upgrade from SHOULD to MUST for servers (RFC 9207).

Three points follow for enterprise operation. First, scopes should be narrow: the security best practices explicitly list wildcard scopes and publishing every scope in scopes_supported as mistakes and recommend incremental elevation via step-up. Second, pre-registration in your own identity provider is often more controlled than open registration paths, because only known clients receive tokens. Third, an MCP server that calls a third-party system on behalf of the user needs its own token for that system. Forwarding the user's MCP token is exactly the forbidden token passthrough.

MCP with local models and Open WebUI

MCP is not tied to a model vendor. The prerequisites are a model that handles tool calling reliably and an inference server that exposes the tool interface. Open WebUI states the limit clearly: MCP connects the interface to tools, it does not improve the model's ability to use them (Open WebUI, MCP).

A typical setup with local models: the model runs in vLLM or Ollama, LiteLLM bundles model access and MCP servers, Open WebUI is the interface and the identity provider supplies the user identity. MCP servers run as separate containers with Streamable HTTP on the internal network. Which models are suitable for tool calling on your own hardware is covered in Which LLM to self-host?, how LiteLLM works as a gateway in What is LiteLLM?.

A gateway centralises access, and with it the risk. Whoever takes over the gateway reaches every connected server. The LiteLLM vulnerability GHSA-7hp6-4w63-5g45 (published 30 September 2026, CVSS 9.9) allows an ordinary user to escalate to proxy admin and from there to execute commands via the MCP stdio endpoint. Affected versions and hardening are described in LiteLLM vulnerability: hardening the gateway.

Risks: tool poisoning, stdio and tokens

The specification itself states that tools represent arbitrary code execution and that descriptions from untrusted servers must be treated as untrusted (MCP specification, Security and Trust & Safety). The main attack paths:

In operation, one more point comes in: the concentration of credentials. An MCP server for five systems holds five sets of credentials. The security best practices describe the knock-on risk for tokens accepted by several services: whoever compromises one service reaches the others too. An MCP server therefore belongs in the same protection class as the most sensitive system it can reach.

How indirect prompt injection through documents, emails and tool results can be contained architecturally is described in Protection against prompt injection.

Permissions and approvals in operation

MCP standardises the access path, not the authorization. Who may use which tools is decided by the catalogue, the identity provider and the target system. The specification explicitly recommends a human in the loop who can deny tool invocations, as well as confirmation prompts for sensitive operations (MCP, Tools). For enterprise use this results in a checklist:

The fundamentals, meaning which identity an agent uses in the target system and which steps require approval, are covered in AI agents: permissions and approvals. Where RAG and tools access the same data, the same rules apply as for RAG with permissions: permissions are checked before access, not filtered afterwards.

When MCP makes sense and when an API is enough

MCP is an additional layer. It pays off when several applications use the same tools or when the integration should outlast a change of model or frontend.

When an agent makes sense at all instead of a fixed workflow is discussed in AI agents and automation. A comparison of frameworks from an operator's perspective, including MCP support, is in AI agent frameworks compared.

What this means for your project

MCP has become a widely used interface between AI applications and company systems, and with revision 2026-07-28 it is also more mature operationally: stateless, routable via headers, with stricter OAuth requirements. The security questions remain those of any integration, only concentrated: who may do what, under which identity, and who can see it afterwards.

WZ-IT connects approved MCP servers and existing APIs with limited permissions and documented data flows to AI agents and internal assistants. The foundation is Open WebUI, LiteLLM, Langfuse and the existing identity provider. Models run locally on the AI Cube or on WZ-IT managed GPU servers with NVIDIA RTX PRO 4000 Blackwell (24 GB) or RTX PRO 6000 Blackwell Max-Q (96 GB). Support, consulting and implementation by WZ-IT.

How the rest of the stack is built is shown in Open-source LLM stack. How local AI services can be made securely reachable from outside is described in Provide secure remote access to local AI.