Claude and MCP Security: A Checklist Before Tools Can Write

Is an MCP connection a security boundary?

An MCP connection gives an application a common way to expose tools and context. It does not replace the application's authorization checks. When Claude proposes a client tool call, the application still decides whether and how to execute it. A valid tool-shaped request is therefore a proposal, not proof that the caller may perform the action.

That distinction matters most when the tool can send a message, change a customer record or delete a file. A read-only assistant and an assistant with write credentials have different failure consequences even if their chat interfaces look identical.

Review the path from request to side effect

Use this checklist as a design review, not as a claim of certification. It complements the protocol's security guidance and your own threat model.

A prompt saying “only access the current customer” is not a substitute for a database query constrained by the authenticated tenant. Put the constraint where data is retrieved and where it is changed.

Separate read, draft and commit

Consider a hypothetical sales assistant that reads account notes and updates an opportunity. Expose three operations with distinct behavior: retrieve authorized context, draft a proposed change and commit the approved change. A model can help with the first two without receiving unrestricted permission for the third.

At commit time, recheck the record's tenant, version and allowed fields. Bind approval to the actual arguments rather than to a vague instruction such as “handle this account.” If the record changes after approval, require a fresh decision. This is an application design recommendation; it is not an automatic guarantee supplied by MCP.

The same rule applies to bulk work. Approval to change one record should not silently become approval to change every matching record. Bound the batch, destination and action before execution.

Treat retrieved instructions as untrusted content

A CRM note, web page or tool response may contain text telling the assistant to ignore earlier rules or send data elsewhere. That text is material to inspect, not a new source of authority.

Test a retrieved note containing a fake request to export the customer list. The expected behavior is that the assistant can summarize the note while the executor refuses unauthorized access or destinations. Merely asking the model to ignore malicious instructions leaves the failure boundary inside probabilistic behavior.

Keep secrets out of model-visible context wherever possible. Return the minimum useful fields from a tool instead of exposing a complete record because it is convenient for the connector.

Check the protocol-specific failure modes

MCP's security guidance discusses token passthrough, confused deputy attacks, server-side request forgery and session risks. Review the guidance for the protocol version you actually deploy; a current draft is not interchangeable with a released specification.

For a remote server, check token audience and intended resource, permitted redirect destinations and the ownership of each session. For a local server, review the executable and its filesystem/network access. “It runs locally” does not mean it has limited permissions. Restrict the process as well as the tool schema.

A small failure suite before rollout

Prepare at least one case for each of these outcomes: a normal authorized read, a cross-tenant read, an unapproved write, an expired approval, a malicious retrieved instruction, a repeated commit and a crash after an external service has accepted the operation.

Expected results should name both the business outcome and the permitted side effects. “The assistant apologized” is not a sufficient result for a failed authorization test. Verify that the record was unchanged and that the attempt is inspectable without leaking secrets into logs.

Pair this review with agent autonomy levels, MCP server design and idempotent writes. The aim is a bounded system whose failures remain understandable.

For the ownership decision, the n8n vs custom AI agents matrix helps identify which component and operator should own these enforcement boundaries.

Primary sources

Checked October 24, 2026. The checklist and test cases are the author's synthesis. They are not a complete security audit or a vendor endorsement.

• Anthropic: where Claude client and server tools execute
• MCP security guidance, version 2025-11-25
• MCP draft security guidance, for comparison with your chosen version