MCP security checklist: 10 questions before you expose tools to a model
Model Context Protocol servers are APIs that a model decides how to call. Ten questions to answer about authorization, sessions, credentials, context and sandboxing before your MCP deployment goes to production.
The Model Context Protocol (MCP) gives models a standard way to discover and call tools and to read resources. For engineering teams it removes a lot of glue code. For attackers it creates something very familiar: an API surface, now driven by a component that can be manipulated through the content it reads.
Most MCP risks are not new. They are authorization, session and input-validation problems, with one twist: the caller is a model acting on behalf of a user, and sometimes on behalf of whoever wrote the last document it read. These ten questions are where we start when testing an MCP deployment.
Authorization
1. Who is allowed to call each tool, and how is that enforced? Authorization should be decided by the server for the authenticated user, per tool and per resource. “The model will only call it when appropriate” is not a control.
2. Are tool permissions scoped to the least the use case needs? A tool that only needs to read invoices should not share credentials with one that can approve them. Split tools by impact.
3. Can one user’s session reach another user’s resources? Test object-level access the same way you would test any API for IDOR/BOLA: change identifiers, replay requests across sessions and tenants.
Sessions and credentials
4. Whose credentials does the server use to reach downstream systems? A single powerful service account behind every tool turns any successful prompt injection into full access. Prefer credentials bound to the user and the session.
5. Are tokens bound to the session and the intended audience? Tokens issued for one server or session should not be reusable elsewhere. Check expiry, audience and how tokens are stored on both client and server.
6. What happens when a session ends or a user’s access is revoked? Background tasks and cached context should not outlive the permissions that started them.
Input, output and context
7. Are tool inputs validated against strict schemas? Arguments come from a model, which means they can come from an attacker. Validate types, ranges and allowlisted values, and watch for command injection and unsafe YAML or JSON processing downstream.
8. Can context leak across users, sessions or tenants? Shared caches, resource listings and error messages are common places where one user’s data shows up in another user’s context.
Execution and visibility
9. Is tool execution sandboxed? Tools that run code, touch the filesystem or spawn processes need isolation, resource limits and no unnecessary network access.
10. Can you reconstruct what happened? Log every tool call with the user, session, arguments and the input that led to it. Without provenance, an incident investigation stops at “the model did it”.
Turning the checklist into evidence
A checklist tells you what to ask. An assessment tells you which answers hold up under attack. For each question above, the useful output is a test: a request that should be denied, a token that should not work, a context that should not appear, and proof of whether it did.
Map findings to MITRE ATLAS and the OWASP Top 10 for LLM Applications where they apply, and to the OWASP API Security Top 10 for the authorization issues that are, at heart, API issues. Then retest after every change to your servers or tools, because MCP deployments evolve as fast as the agents that use them.