- 01Every MCP server in a production AI deployment is a trust boundary. Authentication, authorization, and audit logging must be enforced at the MCP layer, not delegated to the tools behind it.
- 02MCP tool definitions should be reviewed as part of the AI security launch gate. A tool that exposes a filesystem path or a database write capability requires the same scrutiny as a privileged API endpoint.
- 03Tool scope should be enforced by the MCP server using the calling identity context, not by the model. The model should not be able to request a scope that exceeds what the calling user is authorized to access.
- 04MCP server logs are a primary forensic source for AI incidents involving unauthorized tool use. Logs must capture the calling identity, the tool name, the parameters, and the response for every invocation.
The Model Context Protocol gives AI agents a standardized way to invoke external tools. As enterprise AI deployments have adopted MCP, the protocol has become a critical trust boundary that most security programs have not yet addressed systematically. An MCP server that accepts requests from an AI model and executes tools on its behalf is architecturally equivalent to a privileged API gateway, and it should be secured accordingly.
The security community is still developing a shared baseline for MCP server security. This article describes the controls that have proven necessary in enterprise deployments where MCP servers have real authority over databases, filesystems, external APIs, and communication systems.
Authentication and authorization at the MCP layer
MCP servers must authenticate both the AI model making the request and the end user identity on whose behalf the request is made. Without both, the MCP server cannot enforce authorization correctly.
- 01Model authentication. The MCP server should require a signed token from the AI gateway or orchestration layer that identifies the model instance making the request. Anonymous connections should be rejected.
- 02User identity propagation. The end user identity must be propagated through the orchestration layer to the MCP server so that tool scope can be enforced per user. The model identity alone is insufficient for authorization.
- 03Least privilege tool access. Each model instance should be configured with a tool whitelist. Tool calls outside the whitelist should be rejected with an error logged, not silently dropped.
- 04Tool parameter validation. MCP servers should validate all tool parameters against a strict schema before execution. Out of schema parameters should be rejected, not coerced.
MCP servers that trust the model to declare user identity without verification are vulnerable.
A prompt injection attack that manipulates an AI model can cause the model to report a different user identity in its MCP requests, gaining access to tools and resources belonging to another user. The user identity used for authorization must come from the authenticated session context, not from the model output.
MCP server operational security workflow
Operational security for MCP servers requires four ongoing practices beyond the initial configuration controls.
- 01Tool inventory maintenance. Maintain a registry of all MCP servers in production, all tools each server exposes, and the worst case impact for each tool. Review this registry as part of the quarterly AI security review.
- 02Access review. Quarterly review of which model instances have access to which MCP servers. Any access not tied to an active AI feature should be revoked.
- 03Log review. Weekly review of MCP server logs for rejected requests, out of schema parameter attempts, and calls to tools outside the configured whitelist. These events are early indicators of attempted exploitation.
- 04Vulnerability management. MCP server software and its dependencies should be included in the existing vulnerability management program. A vulnerable MCP server is a privileged target.
MCP security metrics
- 01Tool whitelist coverage. Percentage of MCP server tool calls covered by an explicit whitelist configuration. Target is 100 percent.
- 02Rejected request rate. Number of MCP requests rejected per week due to authentication failure, authorization failure, or schema validation failure. Sudden increases indicate an active attack or misconfiguration.
- 03Log completeness rate. Percentage of MCP tool invocations captured in the audit log. Target is 100 percent.
- 04Access review currency. Percentage of MCP server access configurations reviewed in the past 90 days. Target is 100 percent.
MCP server security as part of a broader AI security program
MCP server security is not a standalone discipline. It is a component of the broader AI security program that also includes launch gates, audit logging, incident response, and supply chain governance. The most effective way to integrate MCP security into an existing program is to add MCP server configuration to the AI security launch gate checklist and to include MCP server logs in the SIEM AI telemetry pipeline.
Teams that treat MCP server security as a separate concern from the AI application it serves often discover the gap during an incident, when they find that the AI application logs contain no record of a tool call that the MCP server executed. Treating the MCP server as part of the AI feature's audit surface from the beginning prevents this gap.