MCP security checklist: a central guide for developers and organizations

Introduction

There is no single box that certifies any MCP integration as secure. This checklist helps development teams and organizations identify controls and owners. Adjust its scope to the type of data, transport, permissions and consequences of the tools.

Checklist for developers

Architecture and trust

• I documented client, model, server, tools, external services and data flows.
• I identified which content is external and I treat it as untrusted input.
• I chose a transport and controls suited to the deployment.
• I keep an inventory of tools, inputs, effects and owners.
• I grant only the necessary tools, resources and operations.
• I separate reading and writing; I validate parameters and authorization in the server.
• I avoid turning free text into commands; I isolate processes and limit resources.
• I show relevant parameters and effects before sensitive actions.
• I protect credentials and avoid reusing them across users or clients.
• If I implement MCP HTTP authorization, I follow the current version of the specification and apply the relevant OAuth practices.
• For Streamable HTTP, I validate Origin; if the server is local, I review binding to localhost and authentication.
• Tools that make outgoing requests apply a policy for destinations, redirects and resolution.
• I review changes to description, schema, code, versions and dependencies.
• I minimize context, responses and data retention.
• I log the necessary events without storing secrets or unnecessary content.
• I can revoke credentials, disable the integration and review calls.

Checklist for organizations

Review the process and keep evidence for each integration:

• There is a practical process for registering, reviewing and approving servers.
• The review covers owner, origin, permissions, data, dependencies and updates.
• Evaluation environments use limited data and credentials.
• There are owners for operations, inventory and incident response.
• Authorized tests include denied access, unexpected inputs and later changes.
• Observability and retention rules are proportionate and transparent.

How to use the list

Do not tick a box just because an option exists in the interface. Keep evidence of the configuration and test the control in the real implementation. For controls that do not apply, record the reason and the residual risk. Repeat the review if the permissions, the server, its tools or the data handled change.

Conclusion

MCP security is a property of the integrated system and its operation. Use this list as a starting point and follow the links to analyze in more depth the controls that apply to your architecture.

Series map

Explore the eleven articles on architecture, threats, identity controls and operations to go deeper into each section of this list.

• MCP explained: how it connects AI assistants with tools and data
• Where the risk really is
• Indirect prompt injection
• Tool poisoning
• Rug pull and later changes
• Least privilege
• Tokens, OAuth and confused deputy
• SSRF and DNS rebinding
• Command injection and validation
• Supply chain and shadow IT
• Information leakage through context, responses and logs