Model Context Protocol gives AI agents a standard way to call tools, read resources, and reuse prompts. Most coverage explains how to write a server. This post explains what enterprise teams need to know before they deploy one: authentication, audit logging, secrets isolation, failure handling, and data residency.
Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024 that gives AI models a structured, standardized way to interact with external tools and data sources. Instead of each application building a bespoke integration layer between a model and its tools, MCP defines a common communication protocol. A tool built as an MCP server can be plugged into any MCP-compatible host, from Claude Desktop to VS Code Copilot to a custom enterprise AI agent, without rewriting the integration code for each host.
The developer coverage of MCP has been extensive. There are hundreds of tutorials explaining how to write an MCP server in Python or TypeScript, how to expose a database as an MCP resource, how to wrap an internal API as an MCP tool. That coverage is useful for getting something working quickly. What it consistently skips is the question that enterprise architects and CTOs need answered before they commit to MCP as their AI integration layer: what controls does enterprise deployment actually require, and where does the MCP specification leave gaps that the implementation team must fill?
The gaps are real and they are not small. MCP is a communication protocol. It defines how messages are formatted and exchanged. It does not define how authentication is enforced, how tool calls are logged for audit, how credentials are isolated from the model's context, how failures are handled gracefully, or how data residency is maintained. Each of those is an implementation responsibility. This post covers each one.
MCP defines a client-server protocol built on JSON-RPC 2.0. Three components interact: an MCP Host (the application the user runs, such as Claude Desktop or a custom agent harness), an MCP Client (embedded in the host, manages the connection to servers), and one or more MCP Servers (processes that expose tools, resources, or prompts to the host). The host presents the server's capabilities to the AI model and routes model-initiated tool calls back to the appropriate server for execution.
Tools are executable functions. The model calls a tool by name with arguments; the server executes the function and returns a result. This is the mechanism behind "the model can browse the web" or "the model can query your database." Resources are readable data endpoints, analogous to GET requests. Prompts are reusable prompt templates stored server-side and surfaced to the model on request. Most enterprise deployments center on tools.
MCP supports two transports. Local transport uses standard input/output (stdio): the MCP server runs as a child process of the host, and messages flow over stdin/stdout. Remote transport uses HTTP with Server-Sent Events (SSE): the MCP server runs as an HTTP service, and the host connects over the network. The transport choice has significant security implications that the specification intentionally leaves to the implementer.
The MCP specification is deliberately minimal about security to preserve flexibility across deployment contexts. This is a reasonable design choice for an open protocol. It is also exactly the gap that enterprise teams need to close before deploying MCP in any context where the tools handle sensitive data, where regulatory requirements apply, or where multiple users share the same agent infrastructure.
The MCP specification includes OAuth 2.0 as the authorization framework for remote HTTP servers. This is an important addition to the spec. What it does not do is mandate that any given MCP server implement it, define minimum token scope requirements, or specify how token rotation is handled. Many open-source MCP servers available today, including widely used ones for database access and file system operations, ship with no authentication at all. They are designed to run locally, where the assumption is that process-level access control is sufficient.
In a single-user local development context, that assumption is often fine. In an enterprise deployment where an MCP server exposes internal APIs, where the agent runs in a shared environment, or where the MCP server is exposed over a network boundary, unauthenticated tool execution is not acceptable. Enterprise MCP deployment requires: authenticated connections to all remote servers using OAuth 2.0 or equivalent; token scoping that limits each server to the minimum access required for its function; token rotation and revocation mechanisms; and explicit handling of authentication failures that does not silently degrade to unauthenticated access.
Every tool call an MCP server executes is a potentially auditable event. The arguments passed to a tool often contain sensitive information: query parameters that reveal what data the model is looking for, file paths that reveal the directory structure being navigated, API parameters that reveal the scope of an operation. In regulated industries, the ability to reconstruct what an AI agent did and why is not optional. It is a prerequisite for operating AI in any compliance-sensitive context.
The MCP specification does not address logging. The protocol carries no built-in mechanism for the host to request that a server produce audit logs, no standard format for log entries, and no requirement that implementations log anything at all. Audit logging for MCP must be implemented at the server layer, and it must capture: the tool name and full argument set for each call; the identity of the user or session that initiated the agent interaction; timestamps with sufficient precision; the result or error returned; and the model and host version that made the call. Without this, an agent deployment is operating without an audit trail.
MCP tools frequently need credentials to do their work: a database tool needs a connection string, an API tool needs an API key, a file system tool may need elevated permissions for certain paths. Where those credentials live and how they are accessed is an implementation decision with significant security implications.
The pattern to avoid is any design where credentials flow through the model's context. This can happen in several ways: a user pastes an API key into the chat to "configure" a tool, the tool's arguments include credentials that the model must construct, or the tool result includes a token that the model then incorporates into a subsequent call. In each case, the credential enters the model's context window, from which it may be included in a logged conversation, surfaced in a subsequent output, or sent to a cloud model API where it becomes part of a third party's processing. The correct pattern is that credentials are held by the MCP server and accessed directly at execution time, never entering the model's context. The model sees the result of using the credential, not the credential itself.
MCP servers in enterprise deployments should retrieve credentials from a secrets management service (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or equivalent) at tool execution time. The model invokes a tool by name with data arguments. The server resolves the credential it needs for that operation, executes, and returns the result. The credential never appears in a message that crosses the MCP protocol boundary or enters the model's context window.
The MCP specification defines error response formats. It does not define how a host or agent should behave when an MCP server is unavailable, when a tool call times out, when a server returns a malformed response, or when authentication fails mid-session. The behavior in these cases is left entirely to the host implementation, and the behavior matters significantly for enterprise deployment.
An agent that receives a tool failure may retry indefinitely, consuming quota and potentially amplifying a failing operation. It may hallucinate a plausible-sounding result to continue the task, producing confidently incorrect output that is indistinguishable from a real tool result. It may surface an error message to the user that reveals information about the internal infrastructure. Each of these failure modes is problematic in a regulated or customer-facing context. Enterprise MCP deployments require explicit failure handling policies: defined timeout thresholds per tool category, maximum retry counts with exponential backoff, explicit failure responses that the model can interpret as "this operation could not complete" rather than gaps in context it may try to fill, and circuit breaker patterns for repeated failures that isolate the failing server without degrading the entire agent session.
This is the control gap most enterprise teams discover after deployment rather than before. When an MCP tool executes and returns a result, that result enters the model's context window. If the model is a cloud-hosted API, that context is transmitted to the cloud provider for processing. The content of the tool result is now subject to whatever data handling policies govern the cloud model API, including retention, logging, and geographic processing.
For many enterprise tools, the result contains precisely the data that data residency policies are designed to protect: customer records returned by a CRM tool, patient data returned by a healthcare database tool, financial data returned by an accounting system tool. The fact that the tool itself runs on-premises does not prevent the result from leaving the network. Only the combination of a self-hosted model with on-premises MCP servers achieves true data residency. Teams that are using cloud model APIs and on-premises MCP servers are transmitting on-premises data to a cloud provider on every tool call. This requires explicit legal review, not just a technical assumption that the data stays local.
The five control gaps are not insurmountable. They require deliberate architecture decisions at the point of MCP integration design, not retrofitted controls after the first deployment. The decisions that close the most surface area are:
stdio servers run with the host process's permissions and are harder to isolate. Remote HTTP servers can run with scoped service accounts, be network-segmented, and be independently monitored. The operational overhead of a remote server is justified by the access control benefit in any multi-user or regulated deployment.
Logging at the host layer captures what the model requested. Logging at the server layer captures what actually executed. For audit purposes, the latter is what matters: the actual tool invocation with the actual arguments and the actual result. Server-side logging also captures failed auth attempts and timeout events that the host may not surface.
MCP tool schemas define the structure of expected arguments, but schema conformance does not equal semantic validity. An argument that is structurally a valid string can still contain a prompt injection payload, a path traversal sequence, or a query that exceeds the intended data access scope. Input validation at the server layer is the correct boundary: the model's request is untrusted until the server validates it against the operation's actual permissions.
A single MCP server in a shared enterprise environment may serve requests from users with different data access permissions. Tool execution should be scoped to the requesting user's identity and access rights, not to the broadest permission the server holds. This requires passing user identity from the host through the MCP session and validating it at tool execution time, a pattern the MCP specification supports but does not enforce.
Run through these questions for each MCP server and host combination before moving a deployment beyond a sandboxed pilot environment.
A sandbox MCP deployment can reasonably defer most of these controls. The point of a sandbox is to evaluate whether MCP-powered tools deliver value for a specific use case, not to harden a full enterprise security posture. The decision to move from sandbox to broader rollout is the moment when each of these controls becomes mandatory. Build them into the architecture at that transition point, not retroactively after the tool layer is serving real user requests.
MCP's adoption trajectory is fast. The combination of Anthropic's backing, an open specification, and the practical need for a standard AI integration layer has driven rapid adoption across developer tools, enterprise platforms, and AI agent frameworks. The specification itself has been updated since the November 2024 launch, adding OAuth 2.0 support for remote servers and refining the capability negotiation handshake. Further updates are expected as the enterprise deployment base grows and surfaces requirements the initial specification did not anticipate.
The direction is toward MCP becoming for AI tools what REST became for web APIs: not the only option, but the default integration pattern that a new enterprise tool is expected to support. The implication for enterprise architects is that building an MCP-aware integration layer now, with the controls described in this post, is building infrastructure that will amortize across an expanding set of AI tools rather than remaining specific to a single deployment. The investment in authentication, audit, and secrets isolation is not MCP-specific. It is the security posture that any enterprise-grade tool integration requires, and MCP gives it a standard surface to attach to.
The teams that will be positioned to move fast on AI integration are not the ones that skipped the security architecture work to hit an early demo. They are the ones that built the controls early enough that adding a new MCP server is a configuration change rather than a security review process. The protocol is ready. The enterprise deployment posture needs to be ready alongside it.