MCP Security: Authentication & Enterprise Governance

MCP — the Model Context Protocol — is the standard by which Claude connects to external systems. An MCP server sitting between Claude and your Salesforce instance, your internal knowledge base, or your AWS environment is effectively a privileged credential store with an AI attached. When organisations ask us about MCP security, the concern is not abstract. An improperly configured MCP server can let Claude read data it should never touch, execute actions without approval trails, or expose API credentials in ways that bypass your existing IAM policies.

The good news is that MCP was designed with security in mind. The specification includes built-in primitives for authentication, permission scoping, and transport security. The risk comes from implementations that skip these controls in the rush to ship. This guide covers every layer of MCP security you need to address before rolling out to production — from OAuth 2.1 authentication flows to audit logging to the governance policies your CISO will actually sign off on.

MCP Transport Security: TLS, Local, and Remote Servers

MCP servers run in two modes: local (stdio) and remote (HTTP/SSE or WebSocket). Each has different transport security requirements, and conflating them is one of the most common mistakes we see in enterprise deployments.

Local stdio servers

When Claude Code or Claude Cowork launches an MCP server as a child process via stdio, the transport is the OS process boundary — not a network socket. This is inherently more secure than remote transport because there is no listening port to attack. The risk shifts to the binary itself: what process is being launched, who can replace it, and what file system permissions does it carry? For local stdio servers, the security controls are process isolation (run as a low-privilege user), binary integrity (verify checksums on launch), and file system ACLs (restrict the server's read/write scope to a defined directory tree).

Remote HTTP and WebSocket servers

Remote MCP servers — the more common pattern in enterprise deployments where the server runs on your infrastructure and multiple Claude instances connect to it — must use TLS 1.3 at minimum. TLS 1.2 is acceptable only with specific cipher suite restrictions (no RC4, no 3DES, no export ciphers). Certificate pinning is recommended for internal servers where you control the CA. Never expose a remote MCP server without TLS, even on internal network segments. Internal network compromise is a common attack vector, and unencrypted MCP traffic exposes both credentials and data payloads.

Our MCP server development service configures all remote servers with mutual TLS (mTLS) by default, requiring both the client (Claude) and the server to present valid certificates. This eliminates the class of attacks where a compromised host attempts to connect to your MCP server without legitimate credentials.

Authentication: OAuth 2.1, API Keys, and Service Accounts

The MCP specification supports multiple authentication mechanisms. Choosing the right one depends on whether the server acts on behalf of a specific user (user-delegated access) or as an autonomous agent (service account access).

OAuth 2.1 for user-delegated access

When an MCP server accesses resources that belong to a specific user — reading their emails, querying their CRM records, posting on their behalf — use OAuth 2.1 with the authorization code flow and PKCE. This ensures Claude can only access what the authenticated user has explicitly consented to share. The token scope should be as narrow as possible: if the use case is read-only email search, the scope should be mail.read, not mail.readwrite.

Token storage is a common vulnerability. OAuth tokens should never be stored in environment variables accessible to the Claude process, in plain-text config files, or in the MCP server's working directory. Use a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) with short-lived tokens and automatic rotation. For Claude Cowork deployments specifically, our Cowork connectors guide covers how the built-in connector framework handles OAuth tokens securely through the platform's vault integration.

API keys and service accounts for system-level access

When the MCP server acts as a system (querying a shared database, calling a pricing API, accessing company-wide documents), use API keys or service account credentials scoped to that system function. The principle is the same: least privilege. A CRM MCP server that only needs to read contact records should authenticate with a service account that has read-only access to that object, not a full admin credential.

Rotate all API keys on a schedule. Ninety-day rotation is a reasonable default; thirty days is better for high-sensitivity systems. Store rotation schedules in your secrets manager and automate them — manual rotation is a maintenance burden that gets deferred until it is too late.

# Example: Secure API key loading from environment
# NEVER hardcode credentials in source files

import os
import boto3

def get_mcp_credentials():
    """Load credentials from AWS Secrets Manager, not env vars."""
    client = boto3.client('secretsmanager', region_name='eu-west-1')
    response = client.get_secret_value(SecretId='prod/mcp-server/crm-api')
    secret = json.loads(response['SecretString'])
    return secret['api_key'], secret['api_secret']

Permission Scoping: The Least-Privilege Framework for MCP Tools

MCP exposes three types of capabilities to Claude: tools (functions Claude can call), resources (data Claude can read), and prompts (templated interactions). Each needs its own permission model, and over-permissioning any of them creates unnecessary risk.

Tool-level permissions

Each tool in your MCP server should have explicit documentation of what it can do — not just for Claude's context window, but for your security review process. Tools that write data (creating records, sending messages, modifying files) require higher scrutiny than read-only tools. For high-impact tools — those that can delete data, initiate financial transactions, or send external communications — implement a confirmation gate: Claude proposes the action, the user confirms, then execution proceeds. This is architecturally similar to privileged access management (PAM) workflows your security team already understands.

Resource scope

Resources define what data Claude can read via URI patterns. Scope these tightly. If your MCP server exposes a file system resource, define the root path explicitly and enforce it in the server — do not rely on Claude's instructions alone to prevent path traversal. The server itself must validate that every resource URI falls within the permitted scope before returning data. This is a defence-in-depth measure: even if a prompt injection or misconfigured instruction tells Claude to read /etc/passwd, the server should reject the request before it ever touches the file system.

Dynamic vs. static tool registration

MCP supports dynamic tool registration, where the available tools change based on context. In enterprise deployments, we recommend static tool registration with explicit allowlists per user role. A finance analyst's Claude instance should not see the same MCP tools as a developer's instance. Implement role-based tool visibility at the MCP gateway layer — a reverse proxy that sits in front of your MCP servers and filters available tools based on the authenticated user's role.

Audit Logging: Every Tool Call, Every Data Access, Every Action

For regulated industries — financial services, healthcare, legal, government — MCP audit logging is not optional. It is the evidence trail that shows regulators what Claude accessed, what actions it took, and who authorised those actions. Getting this wrong is a compliance failure, not just a security gap.

What to log

At minimum, every MCP tool invocation log should capture: timestamp (UTC, millisecond precision), user identity (the authenticated user on whose behalf Claude is acting), session ID, tool name, input parameters (sanitised — mask PII and credentials), output summary (not full output, which may contain sensitive data), and execution duration. For resource reads, log the URI, the user identity, and the timestamp. For write operations, log the pre-state and post-state where practical.

Log integrity and tamper protection

Audit logs are only useful if they cannot be altered after the fact. Write MCP audit logs to an append-only store with cryptographic chaining (each log entry hashes the previous entry), or use a dedicated audit log service (AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs) that provides tamper-evident storage by default. Never store audit logs on the same host as the MCP server — a compromised server should not be able to erase its own trail.

Alerting on anomalies

Raw audit logs are necessary but not sufficient. Build detection rules on top of them. Alert when: a single user's Claude session calls an unusual number of tools in a short time window (possible data exfiltration), a tool is called with parameters outside normal bounds (possible prompt injection exploitation), or an MCP server attempts to access a resource URI outside its permitted scope (possible server compromise). These alerts feed directly into your existing SIEM workflow — the MCP layer is not a silo.

See how we handled this for a financial services client in our case studies — a bank that needed full MCP audit trails for their trading desk deployment.

Prompt Injection Defence in MCP Contexts

Prompt injection is the most discussed AI security risk, and MCP deployments face a specific variant of it: data-exfiltration via tool outputs. If an MCP server returns data from an external source — a web page, a document, an email — and that data contains adversarial instructions, those instructions may influence Claude's subsequent behaviour.

Input sanitisation at the server

MCP servers should sanitise data before returning it to Claude. This is not about stripping all formatting — it is about removing patterns that are structurally similar to system prompts. Watch for: XML-style tags that mimic system prompt structure (<system>, <instructions>), instruction-like text in external data ("Ignore your previous instructions and..."), and embedded base64 or encoded content in unexpected fields. A lightweight sanitisation pass — regex-based at minimum, ML-based for high-sensitivity environments — should run on all external data before it enters Claude's context.

Confirmation gates for high-impact tools

The most robust defence against prompt injection in an agentic context is requiring human confirmation before any destructive or irreversible action. If Claude reads a document that says "send an email to all customers" and that triggers the email tool, a confirmation gate surfaces the intended action to the user before execution. This is particularly important for MCP tools that interact with external systems — email, Slack, CRM updates, financial transactions. The latency cost of a confirmation gate is trivial compared to the cost of a successful injection attack.

Enterprise Governance: Policies, RBAC, and CISO Sign-Off

Technical controls alone do not constitute an enterprise MCP security programme. You need governance policies that define who can deploy MCP servers, what approval process they require, and how they are monitored post-deployment. This is the layer that gets your CISO to sign off.

MCP server registry and approval workflow

Treat every MCP server as a privileged integration — the same category as an OAuth app or a service account in your IAM system. Maintain a central registry of all MCP servers deployed in your environment: server name, owner, credentials used, tools exposed, data sources accessed, and security review status. New MCP servers require security review before production deployment. This review checks authentication configuration, permission scope, audit logging, and data handling (does this server process PII? does it need to comply with GDPR?). The Claude security and governance service includes an MCP approval workflow template as part of the engagement.

Role-based access control for MCP tools

Map your existing RBAC model onto MCP tool access. If a user does not have permission to query the HR database directly, their Claude instance should not have access to an MCP tool that queries the HR database on their behalf. MCP is not a privilege escalation path — it should inherit and respect your existing access controls. Implement this at the MCP gateway layer with a policy engine (Open Policy Agent is a good fit) that evaluates tool access requests against the calling user's roles before forwarding to the MCP server.

Data residency and privacy controls

If your MCP servers process personal data, that processing must comply with GDPR, CCPA, or the relevant data protection regime. Document the data flows: what data enters the MCP server, what is returned to Claude's context window, what is logged. For EU-regulated data, ensure the MCP server infrastructure runs in EU-approved regions and that the Claude API calls are routed through Anthropic's AWS EU deployment. Our Claude Enterprise Implementation service maps these data flows as part of the deployment architecture document.

Incident Response for MCP Deployments

When — not if — an MCP security incident occurs, your response needs to be faster than your normal IT incident timeline, because Claude can act at machine speed. A compromised MCP server that is still processing requests can exfiltrate data or execute actions in minutes, not hours.

Define a kill switch procedure before you go live: a mechanism to revoke all MCP server credentials simultaneously and disable the MCP gateway. Test it. Know how long it takes from incident detection to full MCP shutdown. For Claude Cowork deployments, Anthropic's enterprise console gives admins the ability to revoke connector permissions at the organisation level — use this as your primary kill switch for Cowork connectors. For custom MCP servers, the kill switch is typically credential revocation in your secrets manager combined with gateway rule changes.

After an incident, the audit logs are your reconstruction tool. This is why tamper-proof audit logging is a prerequisite, not a nice-to-have. Work through the logs to determine the scope of data accessed, actions taken, and whether any external systems were affected. Brief your DPO or privacy counsel immediately if personal data was involved in the incident.

MCP Security FAQ

Related Articles