The production MCP security checklist

01 / Identity and authorization

• □ Every remote request is authenticated; anonymous access is an explicit exception, not a default.
• □ HTTP authorization follows the current MCP specification and OAuth requirements applicable to your deployment.
• □ Tokens are validated for issuer, signature, expiry and the MCP server's intended audience.
• □ Tokens are never accepted through URL query parameters.
• □ User identity and machine identity are modeled separately where their permissions differ.
• □ Scopes map to actual server-side checks on each call; they are not decorative metadata.
• □ Revocation takes effect within a defined and tested window.

The current specification's issuer validation and issuer-bound credentials address known authorization mix-up risks. They do not define which workspace, connector or document a principal may read. That mapping must exist inside your service.

02 / Data and tenant boundaries

• □ Every tenant-scoped record carries an immutable workspace or tenant identifier.
• □ Every query filters by that identifier before retrieval; database-level policy exists as a backstop.
• □ Cross-tenant denial tests run automatically.
• □ Source permissions survive ingestion instead of disappearing when content is chunked or embedded.
• □ Returned citations cannot reveal titles, URLs or snippets outside the caller's scope.
• □ Logs avoid raw secrets and minimize customer content.
• □ Retention and deletion apply to originals, derived chunks, embeddings, caches and backups.

This is where MCP security becomes data architecture. A properly authenticated agent can still receive the wrong customer's data if tenant context is lost behind the endpoint.

03 / Tool and action safety

• □ Tool names and descriptions state exactly what is read or changed.
• □ Tool annotations are treated as claims from the server, not proof of safe behavior.
• □ Read and write capabilities are separated wherever practical.
• □ Consequential or destructive actions require explicit user approval.
• □ Inputs are schema-validated and bounded in size, depth and execution time.
• □ Idempotency keys or safe retry semantics exist for actions that may be repeated.
• □ Outputs are bounded so a server cannot fill the model's context with uncontrolled data.
• □ Results from external content are treated as untrusted input to the model.

OpenAI's MCP controls distinguish read-only tools and provide approval policies for remote server calls. That is useful host behavior; server-side enforcement remains necessary because not every client will expose or honor controls in the same way.

04 / Credentials, observability and failure

• □ Connector credentials are encrypted at rest and never sent to the browser.
• □ API keys are stored as hashes when the raw secret does not need to be recovered.
• □ Secrets are redacted from structured logs, traces and error responses.
• □ Every tool call records principal, workspace, tool, outcome, latency and a request identifier.
• □ Rate limits exist per principal and workspace—not only per server process.
• □ Timeouts, circuit breakers and bounded retries protect downstream systems.
• □ Authorization failures return a denial and never silently broaden access.
• □ An operator can disable one key, connector or tool without taking down the whole service.

05 / Production rollout

1. Inventory first. List the exact tools, data sources, actions and principals included in the release.
2. Begin read-only. Validate retrieval, permissions, citations and logs before adding mutations.
3. Test adversarially. Include cross-tenant access, forged audiences, expired credentials, prompt injection in source content and repeated write calls.
4. Canary the clients. Different hosts can present approval and tool-selection behavior differently.
5. Define rollback. Keep one action that immediately revokes access without depending on the affected MCP server.
6. Review on change. Re-run the checklist when the specification, SDK, tool catalog or permission model changes.

The July 2026 specification introduced a formal deprecation lifecycle and multiple authorization improvements. Use the SPYN3 release briefing to identify migration-relevant changes, then validate them against the current official specification.