Model Context
Protocol Security
Understanding how MCP works, the enterprise security risks it introduces, and how Privileged Access Management principles apply to AI-to-tool access.
Large language models (LLMs) are increasingly deployed as autonomous AI agents — systems that don't just answer questions but take actions: running code, querying databases, sending emails, calling APIs. To do this effectively, agents need a standardized way to connect to external tools and data sources.
Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that defines how AI systems communicate with external services. Think of it as a universal connector — instead of each AI application building bespoke integrations for every tool, MCP provides a common interface that any compliant server can implement.
Analogy: MCP is to AI agents what USB-C is to devices — a standardized interface that allows any compliant host to connect to any compliant peripheral, removing the need for proprietary adapters.
Before MCP, each LLM integration required custom code. A Slack integration for GPT-4 couldn't be reused for Claude. MCP standardizes the handshake, enabling a growing ecosystem of reusable connectors.
Major vendors — including Atlassian, GitHub, Salesforce, and Google — have released MCP server implementations, signaling MCP is rapidly becoming the de facto enterprise AI integration standard.
MCP enables "agentic" workflows where AI acts over multiple steps: reading a ticket, querying a database, drafting a response, and posting it — all through a single MCP-connected session.
MCP servers are being deployed for CRM data, code repositories, file systems, HR platforms, financial APIs, and internal knowledge bases — anywhere AI agents need enterprise context.
MCP follows a client-server architecture. The AI model (or the application hosting it) acts as the client, and purpose-built servers expose capabilities — tools, resources, and prompts — that the AI can use.
The MCP lifecycle proceeds in distinct phases:
The MCP client connects to a server and requests a manifest of available tools, resources, and prompts. The server responds with descriptions the LLM can use to understand what actions are available.
Based on a user's request (or its own agentic plan), the LLM decides which MCP tool to call and constructs a structured request — for example, create_issue(project="SEC", title="...", priority="high").
The tool call is serialized as a JSON-RPC 2.0 message, transported over stdio (for local servers) or HTTP with Server-Sent Events (for remote servers), and executed by the MCP server.
The server's response is returned to the LLM as context. The model can chain multiple tool calls in a single reasoning loop — using the output of one call to inform the next.
// Example MCP tool call (client → server)
{
"jsonrpc": "2.0",
"id": 42,
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": {
"sql": "SELECT * FROM customers WHERE region = 'EMEA'",
"connection": "prod-crm-db" // ← using a named credential
}
}
}
Key observation: Credentials are typically held by the MCP server, not the model. The AI never "sees" the password — but it does get to decide what query runs with those credentials. This distinction matters enormously for access control design.
MCP dramatically expands the attack surface of enterprise environments. When AI agents can autonomously invoke tools across dozens of connected systems, the security implications are significant and often underestimated by teams focused on model safety rather than integration security.
Critical framing: MCP security is not primarily about the AI model being "unsafe." It's about the access permissions granted to the MCP server and the absence of controls traditionally applied to human users performing the same actions.
Primary Threat Vectors
MCP servers require credentials to authenticate to upstream services — API keys, OAuth tokens, database passwords, service account credentials. These secrets must be stored somewhere accessible to the server process, creating a new class of credential exposure risk.
Unlike human-operated credentials managed through password vaults with MFA enforcement, MCP server credentials are often:
- Stored in plaintext environment variables or config files
- Shared across multiple server instances with no rotation schedule
- Service accounts with no expiration date
- Copied between environments (dev → staging → prod) without policy enforcement
Teams deploying MCP servers often grant broad permissions to "make things work" during setup, then never revisit the scope. This violates the principle of least privilege and creates conditions where an AI agent can access far more data than any individual task requires.
The risk is compounded by the autonomous nature of agents: unlike a human who consciously chooses to access a sensitive file, an LLM may retrieve data it doesn't strictly need because it was available in the tool manifest and seemed contextually relevant.
Because MCP tools are invoked based on the LLM's reasoning about user inputs, an attacker who can influence the model's input can potentially redirect what tools are called and with what parameters. This is called prompt injection.
In an MCP context, prompt injection can cause the agent to:
- Exfiltrate data through a "benign" tool (e.g., creating a Jira comment containing extracted file content)
- Modify or delete resources it has write access to
- Chain tool calls to escalate privilege or pivot to other connected systems
When a human accesses a system, their identity is typically tied to authentication logs, change records, and sometimes video monitoring. When an AI agent performs the same action through MCP, attribution is often limited to the service account the MCP server uses — there is no "who asked the AI to do this" in most deployment logs.
This creates critical gaps for:
- Incident response — investigators can't reconstruct the chain of reasoning that led to a destructive action
- Compliance — GDPR, SOX, HIPAA requirements for data access attribution cannot be met
- Insider threat detection — anomaly detection tools see service account activity, not user intent
MCP clients can be connected to multiple servers simultaneously. An agent that has access to both a file system server and a code execution server can combine these capabilities in ways not anticipated during deployment — reading sensitive configuration files and then using the code server to exfiltrate them.
Tool chaining across security boundaries (e.g., from an internal Wiki MCP to an external Slack MCP) enables data leakage that would be blocked by traditional DLP controls if a human performed the same steps.
Risk Summary Matrix
| RISK | LIKELIHOOD | IMPACT | TRADITIONAL CONTROL | MCP GAP |
|---|---|---|---|---|
| Credential exposure | HIGH | CRITICAL | Secrets managers, rotation | Often bypassed at deployment |
| Over-permissioned service account | HIGH | HIGH | RBAC, entitlement reviews | Not applied to AI service accounts |
| Prompt injection | MEDIUM | CRITICAL | Input validation, sandboxing | No standard defenses for LLMs |
| Missing audit trail | HIGH | HIGH | SIEM, user activity logging | Identity attribution gap |
| Cross-server data exfiltration | MEDIUM | HIGH | DLP, network segmentation | Not MCP-context-aware |
Privileged Access Management (PAM) is the discipline of controlling, monitoring, and auditing access to high-value systems using principles like least privilege, just-in-time access, and session recording. These principles map directly onto MCP deployment security — treating the AI agent as a privileged identity that requires the same governance controls as a human administrator.
The core insight: an MCP server is a privileged identity. It should be subject to the same access policies, credential vaulting, rotation schedules, and audit requirements as a human administrator account — regardless of the fact that an AI is invoking it.
The Five PAM Principles for MCP Deployments
Every MCP server should be granted only the minimum permissions required for its defined use case. Scope permissions at the resource level, not the system level. Review and trim entitlements quarterly.
- Use OAuth scopes, not service accounts with admin rights
- Create read-only credentials for data-retrieval tools
- Use separate credentials per MCP server (no shared service accounts)
- Define allow-lists of permitted SQL operations, not blanket DB access
- Separate production and non-production MCP credentials strictly
MCP server credentials must be stored in an enterprise secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and rotated on a defined schedule. The credential should never be in plaintext in config files, env files, or version control.
- Inject credentials at runtime via secrets manager SDKs
- Rotate API keys every 30–90 days with automated pipelines
- Use short-lived dynamic credentials where the target system supports them
- Alert immediately on any direct access to the raw secret value
Rather than granting always-on access to sensitive tools, implement JIT provisioning: MCP permissions are elevated only when an authorized workflow is active and automatically revoked when the task completes or a timeout elapses.
- Tie MCP tool availability to active user session context
- Provision elevated DB access only during approved maintenance windows
- Require human approval for high-risk MCP actions (e.g., delete, export-all)
- Automatically expire OAuth tokens after workflow completion
Every MCP tool call must be logged with enough context to reconstruct: who initiated the AI session, what prompt triggered the tool call, what parameters were sent, and what data was returned. Logs must be immutable, timestamped, and correlated to user identity.
- Log: session_id, user_id, tool_name, input_params, response_summary, timestamp
- Correlate MCP server logs with upstream system change logs
- Forward logs to SIEM with user-to-agent attribution
- Retain logs per your regulatory compliance requirements
- Alert on anomalous patterns (bulk reads, off-hours access, unusual tool chaining)
Security teams must be able to immediately revoke an MCP server's access — to a single tool, to all tools, or to a specific connected system — without taking down the entire AI application. Design for rapid containment.
- Use centralized access policy enforcement (not per-server ACLs)
- Implement circuit breakers: rate limits on tool calls per session
- Maintain a live MCP server inventory with ownership and status
- Test revocation procedures in tabletop exercises
- Define incident response playbooks for MCP-related security events
# Example: MCP server policy definition (PAM-aligned)
mcp_server:
name: "crm-readonly-agent"
description: "Salesforce read-only access for support AI"
credential:
vault_path: "secret/mcp/salesforce/support-agent"
rotation_days: 30
dynamic_secret: true
permissions:
allowed_objects: ["Account", "Case", "Contact"]
allowed_operations: ["read", "query"]
denied_fields: ["Salary__c", "SSN__c", "BankAccount__c"]
max_records_per_query: 100
access_control:
requires_active_session: true
session_timeout_minutes: 60
high_risk_approval: true
audit:
log_all_calls: true
log_response_summary: true
siem_forward: "splunk://siem.corp.internal"
retention_days: 365
Deployment Readiness Checklist
Click each item to mark it complete. Use this checklist before approving any MCP server for production deployment.