MCP Security Checklist: Protect Files, Credentials and Customer Data

A practical, defense-in-depth checklist for limiting tool authority, isolating MCP servers, securing OAuth flows and reviewing sensitive agent actions.

Hardware security key connected to a laptop with text-free locked icons for files, credentials and data, beside an isolated network device. — A layered security approach limits access to sensitive files, credentials and customer data while keeping connected services isolated.

Key Takeaways

Give every MCP server narrowly scoped, short-lived credentials and expose only the tools required for the task.
Keep secrets outside the agent, restrict filesystem and network access, and isolate local servers and trusted gateways.
Treat tool descriptions and results as untrusted because prompt injection can arrive through an authorized server.
Require clear human approval and staged review for writes, deletions and other sensitive actions.
Map and log third-party data transfers because existing retention and residency guarantees may stop at the MCP boundary.

Connecting an AI agent to a Model Context Protocol server changes the agent from a system that produces answers into one that may read files, call external services or perform consequential actions. The central security question is therefore not simply whether the MCP connection is authenticated. It is whether every tool, credential, data path and action is restricted to what the current task requires.

This MCP security checklist combines the protocol’s authorization and security requirements with operational guidance from OWASP, OpenAI, Visual Studio Code and GitHub. It applies defense in depth: assume that prompts can be manipulated, servers can change, legitimate tools can be misused and data can cross a trust boundary through an authorized call.

Start with the MCP trust boundary

An MCP server can sit between an agent and sensitive resources such as a filesystem, business application or external API. A remote server may also receive and retain information sent through tool calls. Authentication confirms an identity and authorization limits access, but neither control proves that a server is trustworthy or that an agent’s requested action is safe.

Before enabling a connection, document:

Who operates the server: Prefer an official provider-hosted server where one is available, and review the provenance of its code, package and dependencies.
What the server can reach: Identify permitted files, directories, APIs, network domains and customer-data systems.
What the agent can do: Separate read operations from writes, execution, deletion and other sensitive actions.
Where data goes: Record whether tool inputs or outputs leave your infrastructure and what retention, residency and contractual terms then apply.
Which component holds credentials: Authentication material should remain in a trusted broker, gateway or other controlled component rather than being exposed directly to the agent.

Do not treat initial approval as permanent proof of safety. OpenAI’s guidance warns that a remote server may change its behavior after integration, while OWASP identifies supply-chain changes and “rug pulls” as relevant MCP risks.

MCP security checklist before connecting a server

1. Verify the server and minimize the imported tool set

Confirm the server’s operator, distribution source and intended function.
Review the tools and schemas exposed by the server instead of approving the server solely by name.
Import only the tools required for the workflow. Where the client supports a control such as allowed_tools, use it to prevent unnecessary tools from reaching the model.
Do not expose execution, write or administrative tools when read-only access is sufficient.
Repeat the review after server, package, schema or configuration changes.

2. Give each server separate, least-privilege credentials

Use credentials scoped to the specific MCP server and resource.
Prefer short-lived tokens over durable secrets.
Request only the scopes identified by the protected resource. Add broader scopes incrementally when a user-approved task genuinely needs them.
Do not share a powerful credential across unrelated servers or environments.
Store credentials in a secure credential facility, not in prompts, configuration committed to source control or files broadly visible to the agent.

The MCP authorization specification uses files:read as an example of a protected scope. The important design principle is to keep the initial grant narrow rather than asking for every possible permission at connection time.

3. Validate the OAuth flow, not just the token

Ensure the MCP server rejects access tokens that were not explicitly issued for that server.
Record the authorization-server issuer and validate it before sending an authorization code to a token endpoint. This helps prevent authorization-server mix-up attacks.
Expect a protected resource to initiate authorization with an HTTP 401 response and WWW-Authenticate metadata.
Use HTTPS for production authorization URLs. Under the 2026-07-28 MCP guidance, HTTP is limited to loopback development scenarios.
Validate authorization URLs, reject dangerous URL schemes and open them without invoking a shell.
Do not treat an OAuth state handle as proof that a user is authenticated. Bind state to the already verified user and transaction.

4. Defend OAuth discovery and URL handling against SSRF

A client that automatically retrieves OAuth metadata can become a server-side request forgery path. MCP’s security guidance calls for defenses covering private network addresses, cloud metadata endpoints, localhost targets, redirects and DNS rebinding.

Restrict which locations discovery can contact.
Recheck redirected destinations instead of validating only the first URL.
Block access to local, private and cloud-metadata addresses unless a narrowly defined deployment explicitly requires it.
Apply the same caution to URLs returned by tools or embedded in tool results.

5. Isolate local MCP servers

A local stdio server should not be treated as harmless merely because it runs on the user’s computer. It can potentially execute code, read local files and communicate with external services.

Run the server in a sandbox or isolated process.
Allow access only to explicitly required filesystem paths.
Restrict outbound network access to approved domains.
Separate the agent and MCP gateway into different containers or equivalent isolation boundaries where the architecture permits it.
Keep authentication material in the trusted gateway or another protected component rather than inside the agent environment.
Require additional review for sensitive files, including environment files containing credentials.

Visual Studio Code documents MCP server sandboxing for macOS and Linux, while its broader agent-sandboxing support varies by platform and maturity. These are product-specific capabilities, so check the linked official documentation for current availability. Sandboxing also does not replace provenance checks or outbound data controls.

Checklist for tools, prompts and actions

6. Assume prompt injection can arrive through tool results

Prompt injection is not limited to the user’s initial message. A malicious server can place hidden instructions in tool descriptions or results, and compromised external content can attempt to steer the agent toward another tool. OAuth does not stop this because the resulting calls may still use valid credentials.

Treat tool output as untrusted data rather than authoritative instructions.
Separate data returned by a tool from control instructions supplied by the application.
Review tool-call inputs and outputs for unexpected secrets, commands, destinations or cross-server data transfers.
Sanitize outputs before they are passed to another component or displayed in a sensitive context.
Prevent one server from causing data obtained from another server to be forwarded without an explicit policy decision.

7. Enforce strict tool schemas and validate both directions

Define narrow input types, permitted fields and acceptable values.
Reject undeclared properties. OWASP recommends additionalProperties:false for strict JSON schemas.
Validate tool arguments before execution rather than relying on the model to follow a schema correctly.
Validate and sanitize tool output before returning it to the agent.
Fail closed when a request does not match the expected operation.

Schema validation reduces ambiguity and unauthorized parameters, but it does not determine whether an otherwise valid action is appropriate. Sensitive operations still need authorization and, where warranted, human approval.

8. Keep approval for sensitive actions

Require explicit approval for writes, deletions, external communications and other consequential operations.
Show the reviewer the actual target, arguments and relevant data rather than a generic confirmation message.
Stage proposed writes before applying them so a person or trusted policy layer can inspect the change.
Require manual review for edits to credential-bearing or otherwise sensitive files.
Do not allow a low-risk read permission to become an indirect route to a higher-risk action through another server.

In OpenAI’s documented Responses API flow, MCP calls require approval by default. That is a product-specific default, not a property of every MCP client. Verify the behavior of the client and deployment you actually use.

9. Do not expose secrets directly to the agent

GitHub’s agentic-workflow architecture follows a clear principle: the agent should not possess secrets directly. A trusted component can authenticate the permitted call on the agent’s behalf while keeping the underlying credential outside the model’s reachable environment.

Use a gateway or broker to attach credentials after a request has passed policy checks.
Prevent secrets from appearing in prompts, tool output and logs.
Limit the calls that the trusted component will authenticate.
Combine credential isolation with network restrictions so an agent cannot send protected data through an unintended channel.

Checklist for files and customer data

10. Restrict filesystem access by path and operation

Mount or expose only the directories needed for the task.
Use read-only access where writes are unnecessary.
Keep credential stores, environment files and unrelated repositories outside the server’s accessible paths.
Review proposed file changes before they are applied.
Combine filesystem restrictions with process and network isolation.

11. Map every third-party data transfer

When information is sent to a third-party MCP server, the original model provider’s data-residency and retention guarantees may no longer cover that transfer. Before sending customer records, source code, credentials or other sensitive information, verify the server operator’s retention, residency and contractual terms.

Record what data each tool receives and returns.
Minimize fields before transmission.
Apply the organization’s data-loss prevention and retention controls in addition to protocol-level protections.
Block transfers that do not match an approved business purpose or destination.
Log data sent to third-party servers at a level that supports review without duplicating secrets into the logs.

For OpenAI API deployments, the supplied documentation states that stored API data may be logged for 30 days when store=true, unless Zero Data Retention applies. This detail is specific to that product and configuration. Check the official documentation and separately assess the policies of every third-party MCP server.

Checklist for operation and monitoring

12. Log tool activity with enough context to investigate it

Record tool invocations, timestamps and user context.
Capture the server and tool selected, the approval decision and the resulting status.
Monitor unexpected destinations, repeated authorization failures and attempts to access disallowed files or tools.
Protect logs from modification and avoid placing raw credentials in them.
Retain enough information to reconstruct sensitive actions and cross-server data flows under the organization’s own retention policy.

13. Reassess the connection over its full lifecycle

Review changes to server ownership, packages, tools, schemas and requested scopes.
Revalidate filesystem and network permissions after deployment changes.
Confirm that approvals remain enabled for sensitive operations.
Remove tools and credentials that are no longer required.
Treat unexplained behavioral changes as a reason to suspend the connection and investigate.

Choosing controls for local and remote MCP servers

For a local development server

Prioritize process isolation, explicit filesystem paths, outbound network restrictions and review of file changes. Local execution reduces neither the server’s authority nor the risk of exposing credentials stored on the machine.

For a remote provider-hosted server

Prioritize server provenance, per-server tokens, OAuth issuer and audience validation, narrow scopes, approval of sensitive calls and verification of retention and residency terms. An official server can reduce provenance uncertainty, but it does not eliminate the need for least privilege or data-flow review.

For customer-data or production workflows

Use the strongest combination of controls: isolated agent and gateway components, credentials withheld from the agent, restricted egress, staged writes, explicit approvals, strict schemas, output sanitization and comprehensive audit logging. Protocol authorization should be supplemented by the organization’s data-loss prevention, secrets-management and retention controls.

What This Means

A secure MCP deployment does not depend on a single permission dialog or OAuth exchange. It limits what the agent can see, which tools it can call, where each server can connect, what data can leave the environment and which actions require human review.

The practical standard is to assume that any one layer can fail. A prompt may be malicious, a tool result may contain hidden instructions, a server may change after installation and a legitimate credential may be used for the wrong purpose. Narrow scopes, server isolation, credential brokering, staged writes and auditable approvals prevent one failure from automatically becoming access to files, secrets or customer data.

The MCP specification and product implementations continue to evolve. Check the linked official sources for current protocol requirements, product defaults and platform availability before finalizing a deployment.