Every generative AI project eventually hits the same wall: the model is capable, but it cannot see or act on the systems where work actually happens. For two years, teams solved this with bespoke connectors — one integration for each combination of model, framework and enterprise application. The result was a sprawl of brittle glue code, duplicated permissions logic and inconsistent security.
The Model Context Protocol (MCP) has emerged as the industry’s answer. Introduced by Anthropic in late 2024 as an open protocol for connecting AI applications to tools and data, it has since been adopted by most major AI clients and developer tools and, in December 2025, was donated to the Agentic AI Foundation under the Linux Foundation. In 2026 the question for most enterprises is no longer whether to use MCP but how to adopt it without creating a new, poorly governed attack surface. This playbook covers what changed this year, how to architect MCP for an enterprise, the security issues to design for, and a phased rollout plan.
What MCP Is, in Practical Terms
MCP standardizes the conversation between an AI application (the host, such as a chat assistant, IDE or custom agent), a client component inside it, and servers that expose capabilities. A server can offer three main kinds of capability:
- Tools: actions the model can invoke, such as “search_tickets” or “create_purchase_order,” described with a name, natural-language description and input schema.
- Resources: data the application can read into context, such as documents, records or files.
- Prompts: reusable, parameterized templates that encode a workflow.
The value proposition is the same one that made USB or HTTP successful: build a connector once and every compliant client can use it. An internal MCP server for your ticketing system can serve a developer’s IDE assistant, an operations agent and a customer-facing copilot, with permissions enforced in one place.
What Changed in 2025–2026
MCP has matured quickly, and several developments matter for enterprise architects:
- Neutral governance. On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with major cloud and technology companies joining as members. Vendor-neutral stewardship reduces lock-in concerns for enterprises standardizing on the protocol.
- Interactive interfaces. MCP Apps, the first official extension, shipped in January 2026, allowing a tool to return an interactive interface — a form or a dashboard — rendered in a sandboxed frame inside the conversation.
- An enterprise-focused roadmap. The 2026 roadmap, published in March, made enterprise readiness the top priority, including audit trails, single sign-on integration and gateway support, delivered mainly through extensions.
- A stateless core. The 2026-07-28 specification revision removes the session-initialization handshake and session header, moves version and capability information into request metadata, and adds headers that let gateways route traffic by method and tool name. For enterprises, this makes MCP far easier to run behind standard load balancers and API gateways.
- A wake-up call on security. According to a SerpApi review of the first half of 2026, more than 30 MCP-related CVEs were filed in January and February 2026 alone, including a critical remote-code-execution flaw.
Alongside MCP, Google’s Agent2Agent (A2A) protocol, also now under Linux Foundation governance, addresses a different layer: how agents discover and delegate work to other agents. A useful mental model is that MCP connects an agent to tools and data, while A2A connects agents to each other. Most enterprises will need MCP first.
The Enterprise Reference Architecture
Letting every team point every AI client at any MCP server it finds is the fastest way to lose control. A governed architecture has five layers.
1. Curated internal servers
Build or adopt MCP servers for your core systems — ticketing, CRM, ERP, document management, data warehouse — owned by the teams that own those systems. Design tools around business actions rather than raw endpoints. “approve_invoice(invoice_id, comment)” with server-side policy checks is safer and more useful to a model than a generic “call_api(method, url, body).”
2. An MCP gateway
Route all agent-to-server traffic through a gateway that authenticates clients, enforces authorization policy, applies rate limits and quotas, inspects and sanitizes tool metadata and responses, and logs every call. The stateless specification and routing headers make this pattern practical with standard gateway infrastructure.
3. Enterprise identity
MCP’s authorization model is built on OAuth 2.1, with remote servers acting as resource servers that validate tokens issued by your identity provider. Use it. Decide explicitly whether each tool acts on behalf of the end user (delegated access, so the agent can never do more than the user could) or as a service identity (for background automation, with narrowly scoped permissions). Avoid long-lived static API keys embedded in server configurations.
4. A private registry
Maintain an internal catalog of approved servers with owners, versions, data classifications, permitted clients and review status. Clients should be configured to connect only to registered servers. Public registries list thousands of community servers; treat them as you would any open-source dependency — reviewed, pinned and scanned before use.
5. Observability
Trace each tool invocation as part of the agent’s end-to-end trace. The OpenTelemetry generative AI semantic conventions, still in development status in 2026, define spans for agent invocations, model calls and tool executions, and MCP conventions now sit in the same specification effort. Adopting them early keeps traces portable across observability vendors.
MCP solves the integration problem, not the trust problem. Every server is a new path from untrusted content to privileged action, so put identity, a gateway and a registry in place before you scale the number of connections.
The MCP Threat Model
MCP inherits the risks of any API integration and adds some that are specific to language models. Security teams should understand at least these:
- Tool poisoning. A malicious or compromised server hides instructions in tool descriptions, which the model treats as trusted input but the user rarely sees — for example, telling the model to read a credential file and include it in a parameter.
- Indirect prompt injection through tool results. Data returned by a legitimate tool — an email body, a web page, a ticket comment — contains instructions that hijack the agent. Descriptions may be reviewed at connection time, but responses flow to the model continuously.
- Rug pulls and supply-chain risk. A server that behaved well when approved changes its tool definitions in a later version, or a popular package is compromised.
- Excessive permissions. A server holding broad credentials becomes a high-value target, and a confused agent can misuse them even without an attacker.
- Cross-server data exfiltration. An agent connected to both a sensitive internal server and an external one can be manipulated into moving data from one to the other.
- Classic vulnerabilities. Command injection, path traversal and insecure local servers still appear in MCP implementations, as the 2026 CVE wave showed.
Controls that work
- Allowlist servers through the private registry and pin versions; alert on any change to tool definitions.
- Scan server manifests and code before approval, and re-scan on update.
- Sanitize tool descriptions and responses at the gateway, and mark retrieved content as data rather than instructions in the agent’s context.
- Apply least privilege per tool and prefer delegated user tokens so an agent cannot exceed the user’s rights.
- Isolate high-privilege servers: do not let the same agent session combine sensitive internal tools with unrestricted internet access.
- Require human confirmation for destructive or high-impact tools, showing the exact parameters, and disable blanket “always allow” settings in client configurations.
- Run local servers in sandboxes with restricted file system and network access.
- Log every invocation with user, agent, tool, parameters and outcome, and feed the logs to your security monitoring platform.
A Phased Adoption Plan
Phase 1: Inventory and policy (weeks 1–4)
Find out where MCP is already in use. Developers frequently install servers into IDEs and desktop assistants on their own initiative. Publish an interim policy: which clients are approved, which servers may be used, and what data classifications are off-limits. Choose a gateway approach and decide how identity will work.
Phase 2: Pilot with two or three high-value servers (weeks 4–12)
Pick systems where read access alone delivers value — a knowledge base, a ticketing system, a read-only analytics layer — and build servers with business-oriented tools, OAuth-based authorization and full tracing. Connect them to one or two approved clients. Measure adoption, latency, error rates and the incidents your security team observes.
Phase 3: Introduce write actions with guardrails (months 3–6)
Add carefully designed write tools with server-side validation, approval flows for high-impact actions and per-tool rate limits. Stand up the private registry and require registration for any new server. Migrate legacy point-to-point AI connectors onto MCP where it simplifies maintenance.
Phase 4: Platform and scale (month 6 onward)
Offer MCP server templates, shared libraries for authentication and logging, and a self-service registration workflow so system owners can publish servers without reinventing controls. Track the 2026 specification changes, plan migration to the stateless transport, and evaluate A2A where multiple agents need to collaborate across team or vendor boundaries.
Build, Buy or Adopt Community Servers?
Many SaaS vendors now ship official MCP servers for their products, and the open-source community offers thousands more. A simple decision rule:
- Use official vendor servers for SaaS products when they support your identity model, offer adequate scoping, and are actively maintained — then still route them through your gateway.
- Build your own for internal systems, for workflows that combine several systems into one business action, or where you need policy checks the vendor server does not provide.
- Adopt community servers cautiously, after code review, for low-risk use cases, and fork and maintain them internally if they become important.
Worked Example: A Finance Operations Assistant
A company wants an assistant that helps accounts-payable staff investigate invoice exceptions. The assistant needs to read purchase orders and goods receipts from the ERP, look up supplier correspondence in the document system, and — eventually — place invoices on hold or release them.
The team builds one internal MCP server for the ERP with four tools: look up purchase order, look up goods receipt, list invoice exceptions, and set invoice hold status. The first three are read-only. The fourth validates that the user has approval rights for the invoice’s cost center and requires a confirmation that displays the invoice number, supplier and amount. A second server exposes the document system with resources scoped to supplier correspondence only.
Both servers sit behind the corporate MCP gateway, which validates tokens from the company’s identity provider so the assistant always acts with the logged-in user’s rights. The gateway strips unexpected content from tool descriptions, flags instruction-like patterns in document text, and blocks the assistant’s session from reaching external servers while finance tools are connected. Every call appears in the same trace as the model’s reasoning steps. When the team later wants a procurement agent to reuse the purchase-order tools, it registers a new client rather than building a new integration — the payoff of a standard protocol.
Pitfalls to Avoid
- Wrapping every API endpoint as a tool. Large, low-level tool lists confuse models and expand the attack surface. Fewer, well-described business actions work better.
- Shadow servers. Unregistered servers on developer laptops with production credentials are the MCP equivalent of shadow IT.
- Shared service accounts. They break audit trails and let agents exceed user permissions.
- Ignoring spec evolution. The protocol is still changing; pin versions and budget for upgrades.
- Assuming the protocol provides governance. MCP standardizes the connection. Authorization models, data classification and approval policies remain your responsibility.
Outlook
MCP is on a path similar to earlier integration standards: rapid community adoption, followed by a phase of hardening for enterprise use. Expect gateways, registries and identity integrations to become standard platform components, observability conventions to stabilize, and regulators to treat tool access as part of an AI system’s risk profile. For organizations building agents, the protocol is quickly becoming the integration layer of choice, and the competitive advantage will come from the quality and safety of the tools you expose through it.
Conclusion
MCP removes much of the cost of connecting AI to enterprise systems, which is exactly why it needs deliberate governance. Start by finding where it is already in use, put a gateway, enterprise identity and a private registry in front of every server, design tools around business actions with least privilege, and treat every tool description and response as untrusted input. Do that, and MCP becomes the foundation for scaling assistants and agents safely rather than the newest source of security incidents.
How Hanoi Technology Can Help
Hanoi Technology builds secure MCP servers, gateways and agent integrations for enterprise systems, with identity, tracing and guardrails designed in from the start.