Appendix F: Security Checklist

Every line points to where it is explained. Appendix B holds the OAuth-specific checks; this page doesn’t repeat them.

Capability Surface

• Tool names and descriptions accurately reflect risk → ch06
• Read-only capabilities are separated from write capabilities → ch20
• Generic execution tools have been justified explicitly → ch20
• Dangerous tools require approval or equivalent control → ch10
• Resource content does not unintentionally expose secrets or sensitive data → ch06

MCP-Specific

• Tool descriptions and server metadata from other servers are treated as untrusted input, and hashed → ch20
• Annotations match behaviour, and a test proves it for every readOnlyHint: true tool → ch20
• Origin is validated on Streamable HTTP, and local servers bind to 127.0.0.1 → ch07
• Tokens are audience-checked, and the caller’s token is never passed through to a downstream API → ch19
• OAuth metadata and other remote fields are never used to build a local command → ch21
• The Inspector and other dev proxies are not bound to 0.0.0.0 → ch21
• Local servers are pinned to an exact version, not npx -y some-server → ch21
• requestState is integrity-protected and bound to the caller → Appendix A

Authentication and Authorization

• Every item in Appendix B §Minimal Security Checklist → ch19
• Tenant and project scope are enforced server-side, from the token, never from a tool argument → ch25
• Break-glass or admin paths are explicit and auditable → ch18

Input and Data Handling

• Inputs are validated for size, type, and allowed values → ch06
• SQL injection and command injection paths are blocked → ch08
• Filesystem paths are normalized, symlink-resolved and traversal-checked → ch21
• Untrusted content cannot silently drive high-risk actions → ch20
• Secrets never appear in normal tool responses → ch20

Logging and Monitoring

• Tool invocations are logged with identity and outcome, one event per call → ch23
• Logs avoid raw secrets and unnecessary PII → ch20
• Alerting exists for auth failures, spikes, and suspicious access patterns → Appendix I
• Incident review can reconstruct which tool was invoked by whom → ch21

Abuse Resistance

• Rate limits exist per principal, per tool and per tenant, and the error tells the model to stop → ch20
• Expensive or sensitive tools have tighter budgets → ch27
• Retry behavior is safe and bounded → ch23
• Long-running tasks can be cancelled or expired cleanly → ch10

Release Discipline

• Security review happened before publication → ch30
• Rollback and containment steps are documented → ch24
• Support contact and disclosure path exist → ch30
• At least one hostile-path test was run for tenant isolation or privilege abuse → ch21