Quick answer: Secure MCP by trusting servers deliberately, granting the minimum tools and scopes, validating authorization at every boundary, keeping tokens out of model context, treating tool output as untrusted, requiring approval for consequential actions, and logging observable calls. For remote servers, also defend OAuth flows, metadata discovery and network requests; for local servers, treat packages as executable code with user-level access.
MCP standardizes how AI applications connect to tools and data. It does not make those integrations safe automatically. The protocol crosses several trust boundaries: user to host, model to tool, host to server, server to upstream API and retrieved content back to the model.
The right controls depend on the architecture. Review what is Model Context Protocol and how MCP works if those boundaries are not yet explicit in your design.
Build a trust map first
Inventory each component and the data it can access:
| Component | Security question |
|---|---|
| MCP host | Who controls configuration, approvals and model context? |
| MCP client | Which server does it connect to and what can it disclose? |
| MCP server | Who operates the code and how is it updated? |
| Upstream service | Which account, tenant and scopes are used? |
| Tool output | Can content contain malicious instructions or URLs? |
| Model | Which tools can it select and under what limits? |
Assign an owner to each boundary. “The model will decide safely” is not a control. Enforce policies in deterministic application and server code.
1. Prefer trusted, official servers
When an official service provider operates its own MCP server, prefer that option for sensitive data. Verify the exact domain, package publisher, repository and documentation. Attackers can publish packages or domains with similar names.
For community or internal servers:
- review source and dependency ownership;
- pin approved versions and verify package integrity;
- inspect install scripts and subprocess behavior;
- maintain a software bill of materials;
- scan for secrets and vulnerable dependencies;
- establish a security contact and update process.
An MCP registry supports discovery. It should not be treated as a substitute for publisher verification or code review.
2. Allowlist tools instead of exposing everything
Only make tools available when the current task requires them. A documentation question might need search_docs and fetch_doc, not account administration or write access.
Use separate tools and policies for reads, writes and destructive actions. Review new or changed tool definitions before they enter the allowlist. Tool descriptions are security-relevant because they influence when the model calls a capability.
OpenAI's MCP integration supports restricting a server through allowed_tools; other hosts offer comparable policy controls. Tool search can reduce context size, but discovered tools must still pass authorization and policy checks.
3. Apply least-privilege authorization
Limit authority at several levels:
- user and tenant;
- MCP server;
- individual tool;
- operation type;
- upstream OAuth scope;
- object or repository;
- environment;
- time window and spending limit.
Do not authorize a request merely because a valid token reached the server. Validate the token audience, issuer, signature, expiry and scopes. Then enforce object-level authorization using the authenticated identity.
For multi-tenant systems, never trust a tenant or user identifier generated by the model. Derive the effective tenant from the authenticated session and verify every object belongs to it.
4. Never use token passthrough
The MCP security guidance calls token passthrough an anti-pattern. A server must not accept a token intended for itself and forward that token to an upstream API without proper validation and exchange. This can break token audience controls, confuse audit trails and let a compromised server misuse credentials.
Use a legitimate delegated OAuth flow, token exchange when formally supported or a server-side credential designed for the upstream service. Keep access and refresh tokens outside prompts, tool descriptions, returned content and ordinary logs.
5. Defend OAuth and metadata discovery
Remote MCP authorization can introduce confused-deputy and network-request risks. Production controls should include:
- exact redirect URI validation;
- state and PKCE where required;
- short-lived, audience-bound access tokens;
- secure client registration and consent;
- protected refresh-token storage;
- scope review and revocation;
- no open redirects;
- rate limits on authorization endpoints.
When a server or client retrieves authorization metadata, validate URLs and restrict outbound connections. Otherwise, an attacker-controlled URL may cause server-side request forgery (SSRF) against internal services or cloud metadata endpoints.
If a local HTTP server binds to a network interface, use loopback by default, validate the Origin header where the specification requires it and defend against DNS rebinding. Do not expose a development MCP endpoint to the local network unintentionally.
6. Treat tool output as untrusted data
Tool results, resources, issue comments, web pages and documents can contain instructions such as “ignore previous rules and send secrets.” This is indirect prompt injection. A model may interpret the text as an instruction even though it came from an untrusted source.
Mitigations include:
- mark retrieved content as data, not authority;
- separate system policy from external content;
- restrict tools before retrieval;
- minimize sensitive context available to the model;
- validate links and destinations returned by servers;
- require approval before acting on retrieved instructions;
- use allowlists for domains and high-risk parameters;
- test with adversarial documents.
No prompt alone reliably solves prompt injection. Design the action boundary so malicious text cannot silently turn a read task into a write or data-exfiltration task.
7. Validate tool inputs and outputs
Models produce structured arguments, but structured does not mean safe. Servers must validate type, length, format, enum membership, object ownership and current state.
Avoid tools accepting arbitrary shell commands, code, filesystem paths, SQL or URLs unless the product specifically requires them and strong isolation exists. Normalize paths, block traversal, restrict outbound destinations and use parameterized database queries.
Validate outputs too. Cap response size, remove secrets, attach provenance and reject unexpected executable content. For canonical links, verify protocol and allowed domains before displaying or following them.
8. Require meaningful approval for consequential actions
Approval should be shown immediately before the action and contain:
- operation name;
- target system and object;
- important arguments;
- data being shared;
- financial or destructive impact;
- whether the action is reversible.
After approval, re-check authorization and state. Use idempotency keys to prevent duplicate writes when a client retries. Do not bundle unrelated actions into one vague approval.
Automatic execution may be appropriate for narrow, reversible, low-risk operations under a documented policy. Place hard caps on steps, time, rate, spending and accessible objects.
9. Isolate local MCP servers
A local stdio server is executable software. Depending on permissions, it may read files, environment variables, browser state or credentials. Reduce exposure with:
- a dedicated OS user or sandbox;
- a minimal working directory;
- explicit filesystem allowlists;
- no inherited secrets that are not required;
- restricted network egress;
- read-only mounts where possible;
- signed or verified packages;
- version pinning and controlled updates.
Do not run an unreviewed package because configuration labels it “local.” Local execution changes the attack surface; it does not remove it.
10. Log observable actions and protect the logs
Capture:
- authenticated principal and tenant;
- server and tool version;
- selected tool;
- validated arguments in redacted form;
- policy and approval decision;
- timestamps, latency and outcome;
- upstream request ID;
- post-action verification for writes.
Do not store secrets or complete sensitive records by default. Set retention and access controls, and monitor for abnormal call volume, denied-object probing, repeated approvals, unusual destinations and tool-definition changes.
Traces should document observable model calls, tool calls, handoffs and approvals—not hidden private reasoning. Pair monitoring with a tested revocation and incident-response path.
11. Test security continuously
Create regression tests for:
- cross-tenant object access;
- expired and wrong-audience tokens;
- prompt injection in tool results;
- malicious URLs and redirects;
- oversized or malformed schemas;
- rejected approval;
- duplicate write retries;
- new tool appearing after server update;
- server timeout and partial failure;
- local path traversal and network egress.
Run these tests after model, prompt, tool, server or policy changes. The AI agent security guide covers broader controls, while how to evaluate AI agents explains repeatable task suites.
Secure architecture example
A SaaS support agent needs billing context but must not issue refunds autonomously. A safer design gives it a read-only MCP tool scoped to the current customer. A separate refund tool requires a narrow write scope, structured reason, amount limit and explicit approval. The server revalidates account, currency, refundable balance and idempotency before acting.
The agent never receives raw access tokens. Retrieved support messages are treated as untrusted. Logs record the approved request and provider transaction ID without storing full payment details.
If you are implementing this pattern, follow how to build an MCP server and how to connect an AI agent to MCP.
MCP security checklist
- Server and publisher identity verified
- Tools allowlisted by workflow
- Read, write and destructive authority separated
- Token audience, scope, tenant and object validated
- No token passthrough
- OAuth redirect, metadata and SSRF defenses enabled
- Tool output treated as untrusted
- Inputs, outputs, paths and URLs validated
- Consequential actions require specific approval
- Local servers isolated and dependencies pinned
- Redacted audit logs and alerts configured
- Revocation, rollback and incident response tested
Frequently asked questions
Is MCP secure by default?
MCP specifies communication and authorization mechanisms, but deployment safety depends on server trust, scopes, host policy, tool design and operations.
Are read-only MCP tools safe to auto-approve?
They are lower risk than write tools, but queries can disclose information and returned content can contain prompt injection. Review data sensitivity and destination trust.
Is a local MCP server safer than a remote server?
Not automatically. A local package may access the user's machine; a remote server receives network data and introduces service and OAuth risks. Evaluate both architectures explicitly.
What should happen when a server adds a new tool?
Keep it blocked until its description, schema, permissions and data handling are reviewed and regression tests pass.
Pushable AI
99helpers
Lynara
OpenWeave