MCP Security and Compliance
Once an agent can read, write, and act inside enterprise systems, MCP stops being a convenience and becomes a security boundary. The protocol’s power and its risk are the same property: a model with tools. This reference walks the full stack — from transport and authentication to governance and audit — with guidance aligned to the 2025 MCP security best-practices specification.
Security is built into the roles
MCP’s three roles are also three independent security boundaries. Each must validate exchanges rather than trust the layer above it.
| Role | Exposure | Its security job |
|---|---|---|
| Host | UI and session memory | Consent management, session isolation |
| Client | JSON-RPC transport and routing | Credential storage, per-server policy enforcement |
| Server | Tool execution and data access | Authentication, authorization, logging, sandboxing |
The governing principle: every request fails securely. Unauthenticated or unrecognized calls are rejected and logged, never silently honored.
The layered stack
| Layer | Main threats | Core controls |
|---|---|---|
| Transport | Interception, spoofing, downgrade | TLS 1.3, HSTS, origin checks, CSRF prevention |
| Authentication | Token reuse, leaked secrets | OAuth 2.1 + PKCE, short-lived tokens, refresh flow |
| Authorization | Privilege escalation | Per-tool scopes, consent screens, role-based ACLs |
| Execution | Injection, sandbox escape | Containerization, least privilege, resource quotas |
| Logging | Sensitive-data exposure | Log masking, token redaction, PII hashing |
Authentication and authorization
OAuth 2.1 + PKCE. Remote HTTP servers should use the OAuth 2.1 authorization-code flow with PKCE, issue short-lived access tokens (commonly an hour or less), and let clients request specific tool scopes such as database:read or storage:write. A token carries the subject, its scopes, the audience, and expiry:
{
"sub": "user-1234",
"scope": "database:read storage:read",
"aud": "example-mcp",
"iat": 1734176000,
"exp": 1734179600
}
Practical rules: never embed personal tokens in tool definitions; support revocation and rotation via .well-known/openid-configuration; and verify signatures against the published JWK set on every request.
Map every tool to a scope. Authorization is only as good as its granularity.
| Operation | Scope | Notes |
|---|---|---|
tools/call (read) |
read-only |
Analytics and retrieval servers |
tools/call (write) |
write |
State-changing — requires explicit consent |
resources/list |
metadata |
Directory browsing only |
prompt/use |
interaction |
No state mutation |
Inter-agent protocols: ship safeguards early
As agents begin calling other agents, standards are still competing to define how — MCP itself, plus proposals such as Google’s Agent2Agent, Cisco’s Agent Connect, and IBM’s Agent Communication Protocol, each with different emphases (handoff speed, identity binding, governance). Security cannot wait for a winner. Regardless of protocol, hold a minimum bar:
- Mutual authentication (mTLS). Agents prove identity to each other, not just to the host.
- Signed identity / attestation. Where possible, verify that an agent runs known-good code (e.g., via a trusted execution environment).
- Explicit permissioning. No implicit trust — Agent A needs a specific scoped token to call Agent B’s tool.
- Intent-level logging. Record the intent and payload of inter-agent messages so decision chains can be reconstructed in an audit.
Data protection
Encryption. TLS 1.3 (AES-256-GCM or ChaCha20-Poly1305) in transit; full-disk encryption at rest with regular key rotation. Client secrets live in environment stores and short-lived sessions, never in source control.
Minimize context. Give a tool only the fields it needs. Mask internal IDs and strip PII before serializing a response:
{
"email": "user****@domain.com",
"account_id": "acc_#######",
"result": "query_success"
}
Retention and erasure. Keep audit logs only as long as necessary (roughly 90 days is a common ceiling), store identifiers as hashes rather than plaintext, and implement a delete path for personal data to satisfy GDPR/CCPA erasure requests.
Secure execution
| Concern | Countermeasure |
|---|---|
| Code injection | Strictly parameterize inputs; disable eval and shell expanders. |
| Command chaining | Restrict pipe/redirect operators in exec calls. |
| Resource exhaustion | Enforce compute and I/O quotas; time out long calls. |
| Cross-tenant leakage | Isolate clients in dedicated containers or namespaces. |
| Sandbox escape | Run tools under AppArmor/SELinux with read-only mounts. |
| Lateral movement | Block outbound network calls that are not on an allow-list. |
Test these paths deliberately — fuzz tool inputs and pen-test the transport, don’t just assume the controls hold.
Compliance frameworks
| Framework | Relevance to MCP |
|---|---|
| GDPR Art. 25/32 | Data minimization and security by design; process only necessary fields. |
| ISO 27001 / SOC 2 | Operational controls; audit tool invocations and credential rotation. |
| NIST AI RMF | Risk management and human-in-the-loop oversight per integration. |
| OWASP LLM Top 10 | Prompt-injection and exfiltration controls; sanitize inputs and inspect responses. |
Governance controls that operationalize these: a policy registry of approved servers and scopes (to prevent shadow connections), consent logging when a user grants tool access, and periodic review to de-scope unused permissions.
Auditing and traceability
Every tool call should be reconstructable by a human and a machine. Log at minimum: timestamp, session_id, user_id, tool_name, scope, a request_hash (SHA-256 of the payload), latency_ms, and status_code. Bind those records to external API and model events with OpenTelemetry (or an equivalent), and partition logs per tenant so one customer can never read another’s trail.
Useful security metrics: mean time to detect and respond, unauthorized tool calls per thousand requests, and credential-rotation age.
Incident response
- Detect — alert on scope violations or anomalous latency.
- Contain — shut down affected servers and revoke tokens.
- Eradicate — patch dependencies and rotate keys.
- Recover — restore from verified images; re-validate protocol compliance.
- Review — write the post-incident report and update policy.
A scripted audit pass — for example a CLI step like mcp-security-audit --report critical --export=json — makes step 5 repeatable rather than ad hoc.
Build security in from the start
| Stage | Objective | Key activity |
|---|---|---|
| Design | Define risk and scope | Threat-model each tool capability |
| Implementation | Secure coding | Static analysis and dependency scans |
| Testing | Verify auth and transport | Pen tests and negative-scenario replays |
| Deployment | Lock down config | Rotate secrets, validate certificates |
| Monitoring | Detect and alert | Integrate security telemetry |
Takeaways
- Agentic workflows expand the attack surface — security has to be foundational, not bolted on.
- OAuth 2.1 + PKCE, fine-grained scopes, and container sandboxing are the baseline, not the ceiling.
- Treat server logs as regulated records subject to privacy law.
- Run a continuous secure development lifecycle for every connector.
- Compliance is the ability to prove protection and trace every action — not a posture statement.
