Guides · Deimos AI LLC
An MCP server security checklist for teams connecting AI agents.
Know every MCP server your agents can reach and where each one came from. Give each the least access that works. Put a person in front of anything that can’t be undone. Keep a record your agents can’t edit. And know, before you need to, what you will do on the day one of them goes bad. The checklist below turns that into items you can tick, each tied to what the MCP specification says.
Know what is connected.
- List every MCP server each agent and each client can reach, including the ones in configuration files on people’s own laptops.A server added on one machine for one afternoon is still a server with access.
- For each, record its registry name, the version you run, its transport (stdio or Streamable HTTP), who approved it and which credentials it holds.
- Name an owner for each server: the person who answers for it and reviews its updates.
- Remove what nobody uses. An idle server keeps its credentials.
- Review the list when a server’s tools change. A server’s tool list may change over time, and a client can be told when it does (Tools ↗).
Know where each one came from.
- Each server has public source you can read, and the package you install is built from it.Where a server has no public source, decide on purpose that you will run code you can’t read, and write the decision down.
- The publisher’s namespace belongs to the people whose service the server connects to, or to a maintainer you can name.
- Every server is pinned to a named version or image digest, and an upgrade is reviewed like new code.
- Before a local server is added, someone reads the exact command it will run. A client that offers one-click setup must show that command in full and ask before running it (local MCP server compromise ↗).
- Each server has been through the six checks for one server, and looked up in Marklode’s checker.
Give each server the least that works.
- Each server has its own credential, which can be revoked without breaking anything else. No server holds a person’s admin token.
- Scopes start small and grow when a tool needs more. The specification lists wildcard and full-access scopes, and asking for every scope up front, as common mistakes (scope minimisation ↗).
- No token passthrough: a server accepts tokens issued for it and no others, and never forwards a client’s token to another service. The specification forbids both (Authorization ↗).
- Tokens stay out of URLs, logs and tool arguments.
- Local servers run in a sandbox or container, with the file system and network access they need. A local server otherwise runs with the same privileges as the client that launched it.
- A local Streamable HTTP server listens on localhost, checks the Origin header of every request and requires authentication (Streamable HTTP, security ↗).
Put a person in front of what can’t be undone.
The specification says that, for trust, safety and security, there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations and show the tool’s inputs before calling the server (Tools ↗).
- Every tool that charges, deletes, deploys, publishes or sends to people outside the team is marked irreversible in your inventory.
- Each irreversible action waits for a person’s yes, and the person sees the inputs, not a summary the agent wrote.
- Your own list decides what is irreversible, not the server’s description of itself. Clients must treat tool annotations as untrusted unless they come from a trusted server.
- A retried irreversible action is started at most once (how to stop an agent doing something twice).
- A decision about a person comes from a written rule and checked facts, never from the agent’s own verdict.
Where Deimos instruments fit
Ratchet is an effect gate: one call before an action, one after. It starts a retried action at most once, can answer approval required and hold the action until a person says yes, and stops runaway loops with a surge ceiling. Crimp is an open-source decision gate: the agent brings the rule and the facts, never a conclusion, and when a fact breaks, the decision withdraws itself. Clockford™ lets you see, approve and stop your AI agents from your phone, whichever company built them; its private beta opens 2026-11-10.
Keep a record you can check.
- Every tool call is logged: which agent, which server and tool, with what inputs, who approved it and what came back. The specification tells clients to log tool usage for audit (Tools ↗).
- The log lives where the agents can’t edit or delete it.
- Secrets are kept out of the log. Header values are visible to network intermediaries, so the specification says sensitive parameters should not be mirrored into them.
- Each irreversible action has a durable record of its key and its outcome, including the ones whose outcome is unknown.
- You can answer, for any day: which servers were connected, at which versions, and what each one did.
Know what you will do when one goes bad.
A server can be compromised through its package, its maintainer’s account or a dependency, and a well-kept one can ship a bad release. Write these steps down before you need them.
- Stop. Halt the agents that use the server, and every gated action with them. Ratchet has one call that stops every kind of effect in a workspace (Ratchet docs ↗).
- Disconnect. Remove the server from every client configuration in your inventory.
- Revoke and rotate. Revoke every credential the server held, and anything those credentials could reach.
- Roll back. Pin to the last version you reviewed, or leave the server off until a fixed release has been checked.
- Read the record. Find what the server did and when, and check each action whose outcome is unknown with the vendor before anything is retried.
- Tell people. Tell the people affected, and the maintainer, through the project’s security policy.
- Check your machines. For this week’s leaks and live incidents in common software, run the free checks on Wardlatch.
What a checklist can’t do.
- The protocol won’t enforce it for you. The specification says so itself: MCP cannot enforce its security principles at the protocol level, so implementors should build them in (Security and Trust & Safety ↗).
- Ticking every box lowers the risk; it does not remove it. A server you trust today can change tomorrow.
- The specification moves. This page follows revision 2026-07-28; check the version your clients and servers speak.
- It is not legal or compliance advice.
Where this comes from.
Debrief.
The questions this page answers, every answer open.
What should an MCP server security checklist cover?
Six areas: an inventory of every server and the credentials it holds; provenance (public source, publisher, pinned version, the exact launch command); least privilege; a person’s approval in front of irreversible actions; logs and records the agents can’t edit; and a written plan for the day a server is compromised.
Does the MCP specification require a human in the loop?
It says there SHOULD always be a human in the loop with the ability to deny tool invocations, and that clients SHOULD ask for confirmation on sensitive operations and show tool inputs before calling the server (MCP specification, Tools).
Can I trust a tool that says it just reads?
Not on its word. The specification says clients must treat tool annotations as untrusted unless they come from a trusted server. Keep your own list of which tools can change things, and gate those.
What is token passthrough, and why is it forbidden?
It is an MCP server accepting a token that was not issued for it and forwarding it to another service. It bypasses the downstream service’s controls and blurs the audit trail, so the specification forbids it: servers must accept tokens issued for them and no others (MCP security guidance).
What should we log for MCP tool calls?
Which agent called which tool on which server, with what inputs, who approved it and what came back, kept where the agents can’t edit it and with secrets left out. The specification tells clients to log tool usage for audit purposes.
What do we do if an MCP server is compromised?
Stop the agents that use it, disconnect it everywhere, revoke and rotate its credentials, pin back to a version you reviewed, read the record of what it did and check unknown outcomes with the vendor before retrying, then tell the people affected. For live incidents in common software, run the free checks on Wardlatch.