MCP Server Security: The Threat Model Nobody Is Talking About
The Model Context Protocol has rapidly become the standard for AI agent-to-tool communication. MCP servers exist for Postgres, Slack, GitHub, the local filesystem, AWS, GCP, Stripe, and hundreds of other services. The ecosystem is growing fast, the protocol is well-designed, and adoption is accelerating across every major AI platform.
But there is a security conversation that the community is not having loudly enough. MCP servers run as processes on your infrastructure. They have access to whatever the host process has access to. And the MCP specification includes no built-in sandboxing, credential scoping, or access control mechanisms. Security, as the spec explicitly states, is the responsibility of the implementation.
For development and experimentation, this is fine. For production enterprise deployments, this is a threat model that needs to be understood and addressed before MCP servers touch anything sensitive.
The Default Security Posture
Consider what happens when you start an MCP server for Postgres. The server needs database credentials to function — a connection string with hostname, port, username, and password. Those credentials are typically provided as environment variables or in a configuration file. Once running, the MCP server can execute any query the credentials allow against the database. If the credentials grant full access, the MCP server has full access.
Now consider a filesystem MCP server. It provides tools for reading, writing, creating, and deleting files. It runs with the permissions of the user or service account that launched it. If that user can read /etc/passwd or write to /var/www, so can the MCP server — and so can any AI agent connected to it.
A Slack MCP server has the bot token. A GitHub MCP server has the personal access token or OAuth credentials. An AWS MCP server has IAM credentials. Each MCP server holds the full credential set required for its target service, and there is no mechanism in the protocol itself to restrict what operations can be performed with those credentials.
This is by design. MCP is a communication protocol, not a security framework. The specification correctly identifies that security requirements vary enormously across deployment contexts and explicitly delegates security responsibility to implementations. But many implementations — especially community-built MCP servers — have minimal or no security controls beyond the credentials themselves.
Three Threat Vectors That Matter
Threat 1: Agent Hallucination Causing Destructive Operations
AI agents hallucinate. This is a well-documented limitation of current language models. An agent might decide that the correct way to fix a database issue is to drop and recreate a table. It might generate a file write operation that overwrites a configuration file. It might compose a Slack message that sends confidential information to a public channel.
With an MCP server connected to the relevant service and no intervening approval layer, these hallucinated operations execute immediately. The agent decides, the tool executes. There is no "are you sure?" prompt. There is no human review. The gap between the agent's intent (which might be wrong) and the tool's execution (which is faithful to whatever the agent requested) is where damage occurs.
This is not a theoretical risk. It is the default behavior of most MCP implementations. An agent connected to a Postgres MCP server with write credentials can execute any SQL the model generates, including destructive operations.
Threat 2: Compromised MCP Server as Persistence Mechanism
MCP servers are software dependencies. Like any software dependency, they can be compromised. The Ultralytics YOLO supply chain attack of December 2024 demonstrated that malicious code can be injected through CI/CD pipelines without modifying source code. A similar attack on an MCP server — especially a popular, widely-installed one — would give attackers persistent access to whatever services the MCP server connects to.
A compromised Postgres MCP server could silently exfiltrate query results. A compromised filesystem MCP server could establish a reverse shell. A compromised AWS MCP server could provision resources for cryptomining or data exfiltration. The MCP server runs continuously and has legitimate credentials, making it an ideal persistence mechanism for attackers — it looks like normal operation because it is using real credentials to access real services.
Threat 3: Credential Exposure Through Agent Context
MCP servers often include credentials in their configuration, and agent contexts can accumulate sensitive information across tool calls. If an agent's conversation context is logged, cached, or sent to a model provider for inference, credentials that appeared in tool outputs or error messages could be exposed. A database connection error that includes the connection string in its message. An API response that echoes the authorization header. A file read that returns a configuration file containing secrets.
Most MCP implementations do not sanitize tool outputs for credential material before returning them to the agent's context. The agent sees what the tool returns, credentials and all, and that information becomes part of the conversation that may be logged, analyzed, or sent to external services.
How Our Platform Addresses MCP Security
Our platform treats MCP as the right protocol for tool communication and adds the security layers that the protocol intentionally does not include. This is not a wrapper around MCP — it is the execution environment that MCP servers run inside, with purpose-built security components for each threat vector.
DLP Scanner: Real-Time Data Loss Prevention
The DLP Scanner addresses Threat 3 (credential exposure) directly. Every piece of data flowing through MCP tool calls is scanned in real time for PII and other sensitive information across a configurable library of data patterns. Database connection strings in error messages, API tokens echoed in responses, Social Security numbers in query results — the DLP Scanner detects and redacts them before they enter the agent's context or reach any logging system. This is not regex-based pattern matching — it is contextual detection that understands the difference between a phone number in a contact record and a phone number that should never appear in an agent conversation.
OBO Authentication: Agent Identity with User Permissions
OBO (On-Behalf-Of) Authentication solves the fundamental credential scoping problem. When an AI agent invokes an MCP tool, it acts with the identity and permissions of the requesting user — not with a privileged service account. A tool that needs to query a Salesforce API gets a scoped OAuth token derived from the user's own permissions, limited to the specific operations required, with the token expiring when the task completes. The agent never holds broad credentials. It inherits the least-privilege access of the human it is acting on behalf of.
This model eliminates the shared-credential antipattern where every agent in the system uses the same service account. If an agent is compromised, the blast radius is limited to what that specific user was authorized to do — not what the service account could do across the entire organization.
RBAC: Per-Tool Granularity
Role-Based Access Control on the platform operates at per-tool granularity. Define exactly which agents, users, and roles can access each MCP server and which operations they can perform. A junior analyst's agent can read from the Postgres MCP server but not write. A senior engineer's agent can deploy through the Kubernetes MCP server but only to staging namespaces. RBAC policies are declarative, version-controlled, and auditable — not embedded in application code where they drift and degrade over time.
Sandboxed Execution
Every MCP tool invocation runs in an isolated execution context. The MCP server process is containerized with explicit resource limits, network policies, and filesystem restrictions. A Postgres MCP server gets access only to the specific database and schemas required for the current task. The sandbox is enforced at the infrastructure layer, not the application layer, making it resistant to application-level bypasses.
Mandatory HITL Gates
Before any MCP tool call executes, the request passes through a human-in-the-loop approval gate. The human reviewer sees: the agent's reasoning for why the tool call is needed, the exact parameters that will be sent, the risk classification of the operation, and the credential scope that will be used.
For low-risk, well-understood operations (reading public data, querying non-sensitive APIs), HITL policies can be configured to auto-approve with logging. For high-risk operations (database writes, external communications, infrastructure changes), manual approval is required. The policy is configurable per tool, per agent, and per risk level — but it cannot be removed entirely. Every tool call is recorded regardless of whether it was auto-approved or manually reviewed.
Audit System: Immutable, Tamper-Evident Logs
The Audit System records every MCP tool invocation in immutable logs with cryptographic hashing — tamper-evident records that cannot be altered after the fact. Each entry captures: the originating request, the agent's reasoning chain, the tool call parameters, the OBO identity context, the RBAC policy that authorized the action, the approval decision (auto or manual), the execution result, and any downstream effects. This audit trail is designed to support the logging requirements ofSOC 2, HIPAA, and FedRAMP compliance frameworks.
When something goes wrong — and in production systems, things go wrong — the audit log provides a complete, reproducible record of what happened and why. You can trace from a business outcome back to the specific agent decision, user identity, RBAC authorization, tool call, and approval that produced it.
The Responsibility Gap
The MCP specification is right that security is the implementation's responsibility. The problem is that most implementations have not yet accepted that responsibility. Community MCP servers are built for functionality, not security. They demonstrate what the protocol can do, not what a production deployment needs.
This is a familiar pattern in technology adoption. Early implementations optimize for capability and developer experience. Security comes later, usually after the first incident. But with MCP servers holding database credentials, API tokens, cloud provider keys, and filesystem access, the blast radius of the first incident could be significant.
The time to add security is before the incident, not after. The MCP protocol itself does not need to change — it is correct in delegating security to the implementation layer. What needs to change is that production implementations actually implement security: real-time data loss prevention, identity-scoped authentication, granular access control, approval workflows, and tamper-evident audit trails. These are not optional nice-to-haves. For enterprise deployments, they are the minimum viable security posture for any system that gives AI agents the ability to act in the real world.