MCP server security checklist for businesses

Why MCP servers need their own security review

An MCP server is a production API whose caller is a language model acting for a person. The model can be steered by the content it reads, it can retry, and it can call tools in combinations nobody planned. The server has to be safe even when the model is wrong.

Identity and authorization

• Use OAuth with per-user tokens for remote servers. Avoid one shared credential that gives everyone the same access.
• Validate the token on every request, including its audience, so a token issued for another service is rejected.
• Derive tenant, account, and access groups from the verified token. Reject any tenant or permission fields the model supplies.
• Check authorization for every resource the tool touches, server-side, on every call.
• Report denied data as withheld. Never fall back to a lower-trust source to fill the gap.

Tool design

• Ship read-only first. Add write tools one at a time, only where asked.
• Annotate every tool as read-only, destructive, or open-world so clients can ask before acting.
• Require explicit confirmation and an idempotency key for writes, so a retry never runs twice.
• Validate inputs with strict schemas and reject unknown fields.
• Never accept raw SQL or file paths from the model unless the server enforces read-only access and limits.

Limits and data minimization

• Cap rows, documents, and response size for every tool.
• Set execution time limits and return a clear timeout so the model can retry narrower.
• Rate limit per user and per token.
• Return only the fields a question needs. Leave out internal IDs and personal data that are not required.

Prompt injection and untrusted content

Documents, emails, and records a tool returns can contain text written to manipulate the model. Mark tool output as data in your server instructions, keep write tools behind confirmation, and never let content returned by one tool silently trigger a write in another.

Logging and testing

• Log tool name, user, outcome, and latency for every call. Never log tokens or secrets.
• Write negative tests: wrong tenant, expired token, missing scope, oversized request.
• Test tool selection with real questions so the model picks the right tool.
• Re-run the suite on every change and every protocol upgrade.