MCP security checklist

Answer 13 questions about how your agents reach MCP servers. You get a score out of 100 and your biggest gaps first, each with a fix.

MCP security checklist

--/ 100
Answer the questions below

13 questions. Pick the closest answer for each. “Not sure” counts as a gap, because a reviewer will ask.

What an agent can callopen
Who the agent isopen
Where the keys liveopen
What you can see afterwardsopen
Which servers runopen

What an agent can call

  • Can you allow one tool on a server and block another for the same agent?

    For example read issues but not merge a pull request, on one GitHub server.

  • Does each agent start with only the tools its job needs?

    Not the whole server by default, with more added when someone asks for it.

Who the agent is

  • Does each agent have its own token, separate from any person’s?

    No agent runs on a developer’s personal token or a key shared between agents.

  • Do agent tokens expire within hours instead of months?

    A stolen token stops working on its own.

  • Can you cut off one agent in minutes without touching anyone else’s access?

    Suspend or revoke a single agent and nothing else breaks.

  • Do your MCP servers reject tokens that were issued for something else?

    Servers check the token’s audience and never forward a client’s token to another API.

Where the keys live

  • Are API keys kept out of agent config files, prompts and repos?

    No live key in an mcp.json, an .env that is committed, or a system prompt.

  • Is each upstream key stored in one place, not copied to every client?

    Rotating a key means changing it once.

What you can see afterwards

  • Is every tool call logged with the tool, the caller and the result?

    You can answer “what did this agent call on Tuesday, and did it work?”

  • Can those logs reach your SIEM or log store?

    Exported on a schedule or pushed as events, not only read in a dashboard.

Which servers run

  • Can you list every MCP server installed on your team’s machines?

    Including ones someone added on their own.

  • Is a local server’s startup command reviewed before it runs, with limited file and network access?

    Nobody pastes an npx line from a README and runs it with full rights.

  • Are third-party servers scanned for known vulnerabilities before anyone uses them?

    A scan of the image or package, with high-severity findings blocking the install.

Gaps to close, biggest first

Your gaps appear here as you answer, each with a fix and where the advice comes from.

Plain text for a ticket or a review thread. Your answers stay in this browser tab.

How it works

The questions cover five areas: what an agent can call, who the agent is, where the keys live, what you can see afterwards, and which servers run. Each one is weighted by how often it is the first thing a security reviewer raises. Per-tool access, an identity per agent, keys outside agent configs and a log of every call weigh 3. Token lifetime, revocation and server vetting weigh 2. Exporting logs weighs 1.

Answers are Yes, Partly, No or Not sure. Partly counts for half. Not sure counts for nothing, because a reviewer will ask the same question and you need to be able to answer it. If you run no servers of your own, or no local ones, mark those questions not applicable and they drop out of the score instead of inflating it.

Two answers are checked against each other. If your agents do not have their own tokens, a log of every call still names the person whose token the agent used, and revoking the agent revokes that person too, so credit for both is capped at half. Say No to everything except logging and you score 5. Give each agent its own token and the same setup scores 21. The page tells you when it applied the cap.

The advice follows the MCP project’s own security best practices page, and each gap links to the section it comes from. The access questions go deeper in MCP permissions, identity in MCP agent identity, and logging in MCP audit logs. If you run servers yourself, self-hosting an MCP gateway covers the infrastructure side. Nothing you enter is sent anywhere.

Questions

85 and above is few gaps, 60 to 84 is solid with gaps to close, 35 to 59 is significant gaps, and below 35 means little is in place yet. Use it to decide what to fix first. It is not a certification or an audit.

A security reviewer will ask the same question, and "we don’t know" is what they will write down. Finding out whether keys sit in a config file or whether calls are logged is usually quick, and the score rises once you do.

Three. If you run no MCP servers of your own, skip the token audience check. If you run no local servers, skip the startup command review. If you only use servers you wrote, skip the vulnerability scan. They are removed from the score rather than counted as passed.

No. Statio covers per-tool access, a token per agent, keys held in the gateway, call logging with export, server scanning and discovery of servers on team machines, and the page says which gaps those cover. It does not check token audience on servers you run or review a local server’s startup command.