SHARE ARTICLE

The AI Infrastructure Gap

Why scaling AI requires a new foundation and the nine components every enterprise ends up needing.

FEATURED

MCP Security Architecture: Moving Beyond HTTPS for Enterprise Deployments

Mubbashir Mustafa

9 min read

MCP's security model was designed for developer simplicity, not enterprise complexity. The specification relies on HTTPS for transport encryption and leaves authentication, authorization, and audit logging to individual implementations. In practice, this means each MCP server implements its own security posture. Fifty-three percent use hard-coded credentials. Only 8.5% implement OAuth. The rest fall somewhere between these extremes, using a patchwork of API tokens, basic authentication, and environment variables.

For developer tooling on a local machine, this is acceptable. For enterprise deployments where MCP servers connect AI agents to production systems containing customer data, financial records, and regulated information, it's inadequate. Enterprise MCP security requires an architecture that addresses the specific threat model of agent-to-tool communication, not a retrofit of generic API security.

The MCP Threat Model

MCP introduces security considerations that differ from traditional API architectures in three important ways. Learn more

First, the client is an AI agent, not a deterministic application. An API client sends requests that a developer explicitly coded. An MCP client sends requests that an AI model generates at runtime based on natural language prompts. This means the request surface is unpredictable. An agent might construct a tool call that accesses data the developer never intended it to, not because of malicious intent, but because the model's interpretation of the prompt led to a valid-but-unintended request.

Second, MCP servers typically have broader access than the tools they expose. An MCP server connected to Jira has access to the full Jira API, but it should only expose a scoped subset of operations to AI agents. The gap between what the server can do and what agents should be allowed to do through it is the primary attack surface. A compromise or misconfiguration that exposes the full API surface to agents is a privilege escalation path.

Third, MCP's tool discovery mechanism means agents learn what tools are available at runtime. When an agent connects to an MCP server, it queries the server's capabilities and dynamically decides how to use them. This is different from a hardcoded API integration where the available operations are determined at development time. An MCP server that adds a new tool (intentionally or through a malicious update) can change agent behavior without any code change in the agent itself.

These characteristics produce a threat model with four primary vectors.

Credential compromise gives an attacker full access to everything the MCP server can reach. Since 53% of servers use static credentials, a single compromised token provides persistent, unscoped access. The CVE-2025-6514 incident demonstrated how credential compromise at scale can propagate through developer environments.

Privilege escalation through tool chains occurs when an agent uses one MCP server to gain access to another, escalating its effective permissions beyond what any single server was intended to provide. If Server A provides read access to customer records and Server B provides write access to the billing system, an agent that chains calls to both servers has read/write access across customer and billing data, a combination that neither server was individually designed to permit.

Data exfiltration through context exploits MCP's design as a context protocol. Agents request data from MCP servers to build context for their reasoning. An attacker who compromises an agent (through prompt injection or other means) can use this context-gathering capability to extract data from any MCP server the agent connects to, effectively turning the agent into a data exfiltration tool. The attack is particularly dangerous because it uses MCP's intended functionality (context gathering) for an unintended purpose (exfiltration), making it difficult to distinguish from normal agent behavior through simple monitoring.

Supply chain attacks through server updates target the MCP server itself. When a server is updated (either by its maintainer or through a compromised update pipeline), new tools or modified capabilities are automatically available to all connected agents. An attacker who compromises the update mechanism can introduce malicious tools that agents begin using immediately. Learn more

Authentication Architecture

Enterprise MCP authentication should move through three tiers of maturity.

Tier 1: Rotating tokens with vault integration. Replace hard-coded credentials with tokens stored in a secret management system (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Tokens should be scoped to specific servers, have expiration times (hours, not months), and rotate automatically on a schedule. This eliminates the "leaked credential provides permanent access" risk. It's the minimum viable security improvement and should be the immediate priority for any enterprise with MCP servers in production.

Tier 2: OAuth 2.0 with scoped authorization. OAuth provides a standard authentication framework with built-in concepts for token scoping, refresh, and revocation. Each MCP server acts as a resource server. Agents authenticate through an authorization server that issues tokens scoped to specific capabilities. When an agent connects to a Jira MCP server, it receives a token that permits read access to a specific project, not admin access to the entire Jira instance. Token scoping is where most enterprises fail with OAuth implementations. The effort of defining fine-grained scopes for each MCP server is significant, but the alternative (broad-scope tokens that over-permission agents) undermines the purpose of adopting OAuth.

Tier 3: Mutual TLS with workload identity. For high-security environments, mTLS provides certificate-based authentication where both the agent (client) and the MCP server verify each other's identity. Combined with workload identity systems (Kubernetes Service Accounts, AWS IAM Roles, Azure Managed Identities), mTLS eliminates shared credentials entirely. Each agent process receives its own certificate, issued at startup and revoked at termination, that identifies it uniquely. This is the highest-assurance authentication model and the standard for regulated industries. Learn more

Authorization Architecture

Authentication answers "who is this?" Authorization answers "what are they allowed to do?" For MCP, authorization needs to operate at three levels.

Connection-level authorization determines which agents can connect to which MCP servers. This is the coarsest granularity and the minimum requirement. A customer support agent should be able to connect to the CRM server and the knowledge base server but not the billing system server or the HR database server.

Tool-level authorization controls which tools within an MCP server each agent can invoke. A single MCP server might expose five tools. An agent authorized to use the "search" tool should not automatically have access to the "delete" tool. Tool-level authorization is where most enterprises need to invest, because MCP servers frequently expose more tools than any single agent needs.

Parameter-level authorization is the finest granularity, controlling the specific arguments an agent can pass to a tool. An agent authorized to search customer records should be restricted to searching its own department's customers, not the entire customer database. Parameter-level authorization requires the authorization system to understand the data model behind the MCP server, which adds complexity but provides the precision that least-privilege access requires. For most enterprises, implementing parameter-level authorization for all servers simultaneously is impractical. Start with the servers that handle the most sensitive data and expand coverage as the authorization infrastructure matures.

Policy engines like Open Policy Agent (OPA) or AWS Cedar are well-suited for MCP authorization. They evaluate each request against a policy set and return allow/deny decisions with audit trails. The policy inputs include the agent's identity, the MCP server, the tool being invoked, the parameters, and any contextual signals (time of day, request frequency, data sensitivity of the target). Learn more

Encryption and Data Protection

Beyond transport-layer TLS, enterprise MCP deployments should consider three additional encryption layers.

End-to-end encryption for sensitive data that passes through MCP servers. If an agent retrieves customer PII through an MCP server, the data should be encrypted at the application layer (not just in transit) so that intermediary infrastructure (load balancers, proxies, logging systems) cannot access the cleartext.

Key management must scale with the number of MCP servers. Each server needs its own encryption keys, managed through a centralized key management system with rotation schedules, access logging, and hardware security module (HSM) integration for high-security environments. Key management for 50 MCP servers is manageable. Key management for 500 requires automation.

Data classification enforcement prevents MCP servers from returning data above the requesting agent's clearance level. If an MCP server connects to a database containing both public product information and restricted financial data, the server should enforce classification boundaries, returning only data that matches the agent's authorized sensitivity level. This requires the MCP server to understand data classification metadata for every record it accesses. In practice, classification enforcement is the hardest layer to implement because most enterprise data lacks consistent classification labels. Organizations that have invested in data governance (tagging, cataloging, sensitivity labeling) can extend that investment to MCP. Organizations that haven't will find MCP security blocked by a data governance gap that predates MCP entirely.

Audit Logging and Incident Response

Enterprise MCP audit logging captures five categories of events.

Authentication events: agent connections, disconnections, authentication failures, token issuance, and token revocation. These form the foundation of access tracking and are the first thing incident responders review during an investigation.

Authorization events: permission evaluation decisions (allow and deny), policy violations, and privilege escalation attempts. Deny events are especially important because they indicate either a misconfigured agent or an attempted policy bypass.

Tool call events: the complete record of every tool invocation, including the requesting agent, the tool called, the parameters passed, the response returned, the latency, and the result status. This is the primary audit trail for compliance and the most valuable data source for behavioral analysis.

Configuration events: changes to MCP server capabilities, tool registrations, permission modifications, and credential rotations. These events detect when a server's posture changes, whether through authorized updates or unauthorized modifications.

Anomaly events: alerts generated by behavioral analysis, including unusual access patterns, volume spikes, new tool invocations, and connection patterns that diverge from baselines. Anomaly detection improves with data volume, so the earlier you start collecting behavioral baselines for your MCP servers, the more effective your anomaly detection will be when you need it.

For incident response specifically, enterprises should build MCP-specific runbooks that address the common scenarios: credential compromise (revoke, rotate, audit), unauthorized server discovery (isolate, investigate, register or decommission), data exposure (assess scope, notify, remediate), and supply chain compromise (freeze updates, audit capabilities, verify integrity).

The audit logging infrastructure should integrate with your existing SIEM (Splunk, Elastic, Microsoft Sentinel) to provide correlation between MCP events and broader security signals. An MCP tool call that coincides with a suspicious login attempt or an unusual data access pattern elsewhere in the environment tells a different story than either event in isolation. This correlation capability is what transforms MCP audit logs from a compliance checkbox into an active security tool. Learn more

The Security Checklist for MCP Deployments

For enterprises deploying or evaluating MCP, a minimum security baseline includes seven requirements.

No hard-coded credentials anywhere: all credentials stored in vault with automated rotation. Authentication at Tier 2 or above (OAuth with scoped tokens) for any server accessing sensitive data. Tool-level authorization enforced through a policy engine. Structured audit logging for all five event categories captured above. An MCP registry that inventories every server, its capabilities, and its approval status. Automated detection of unregistered (shadow) MCP servers. And an incident response runbook that addresses MCP-specific scenarios.

This baseline doesn't require custom security infrastructure. It requires applying established enterprise security patterns (secret management, policy-as-code, structured logging, asset inventory) to a new category of infrastructure. The patterns are proven. The application to MCP is what's new.

The implementation order matters. Start with credential management (highest risk, most immediate impact). Then add authentication upgrades (OAuth, then mTLS for high-security environments). Then build authorization infrastructure (connection-level first, then tool-level, then parameter-level). Then instrument audit logging. Finally, implement anomaly detection on top of the audit data. Each step builds on the previous one, and each step reduces a specific risk category. Trying to implement everything simultaneously leads to half-finished security layers that create a false sense of protection.

The timeline for a complete MCP security architecture varies with organizational maturity. Enterprises with existing secret management, policy engines, and structured logging can adapt these systems for MCP in 60-90 days. Enterprises building these capabilities from scratch are looking at a 6-9 month project. In both cases, the credential management step (replacing hard-coded tokens with vault-managed secrets) should be treated as an emergency priority for any production MCP server, because it addresses the highest-probability, highest-impact risk vector in the current MCP threat landscape.

The 53% credential statistic will improve as enterprises mature their MCP security practices. The question is whether your organization leads that improvement or becomes a cautionary incident report along the way. Learn more

Rebase handles MCP security at the infrastructure layer: vault integration, OAuth with scoped tokens, policy-enforced authorization, and comprehensive audit logging. See how it works: rebase.run/demo.

Related reading:

  • Model Context Protocol for Enterprise

  • Shadow MCP: The Unauthorized AI Agent Risk

  • AI Agent Identity: The New Frontier

  • AI Agent Security Posture Management

  • Enterprise AI Infrastructure: The Complete Guide

  • MCP Observability: Monitoring Enterprise AI Agents

Ready to see how Rebase works? Book a demo or explore the platform.

SHARE ARTICLE

The AI Infrastructure Gap

Why scaling AI requires a new foundation and the nine components every enterprise ends up needing.

The AI Infrastructure Gap

Why scaling AI requires a new foundation and the nine components every enterprise ends up needing.

WHITE PAPER

The AI Infrastructure Gap

Why scaling AI requires a new foundation and the nine components every enterprise ends up needing.

WHITE PAPER

The AI Infrastructure Gap

Why scaling AI requires a new foundation and the nine components every enterprise ends up needing.

Recent Blogs

Recent Blogs

Ready to become AI-first?

Ready to become AI-first?

document.documentElement.lang = "en";