AI + MCP SECURITY
SECURITYMCP Security and Governance: A Production Threat Model and Control Checklist
A practical MCP security guide covering OAuth boundaries, token audience, tool privilege, prompt injection, third-party servers, auditability, approval gates, and incident response.
Draw the trust boundaries first
Before connecting an MCP server, draw the identities and tokens that cross the system. The user authenticates to the host. The host may create one or more MCP client relationships. A protected remote MCP server acts as a resource server and validates tokens intended for that server. If the MCP server itself calls an upstream service, that is another authorization relationship.
The 2026-07-28 authorization specification is explicit that protected MCP servers need appropriate OAuth-based controls and resource metadata. Security considerations also require servers to reject tokens not intended for them. This prevents a common shortcut: accepting a token merely because it is valid somewhere.
The highest-value threats to test
| Threat | Failure pattern | Control |
|---|---|---|
| Prompt injection | Untrusted content attempts to redirect agent behavior | Separate data from policy; tool confirmation; content trust labels |
| Tool poisoning | Server metadata or tool description influences unsafe use | Approve servers; pin configuration; review tool schemas |
| Token passthrough | Credential for one service is reused through another boundary | Independent audience-bound tokens |
| Overprivileged server | One server exposes broad read/write capability | Split servers; least privilege; read-only defaults |
| Argument injection | Model supplies dangerous path, query, or command | Strong schemas; allowlists; server-side validation |
| Confused deputy | Host causes server to act with authority not intended by user | Bind identity, resource and action; explicit consent |
| Data exfiltration | Tool or server sends sensitive data outward | Egress controls; classification; trusted destinations |
| Shadow server | Unapproved MCP endpoint enters developer workflow | Managed configuration; inventory; network policy |
Design approval around consequence
Not every tool call needs a human prompt. Excessive confirmation causes users to click through warnings. Classify actions by consequence instead: read-only low-sensitivity calls may run automatically; writes that are reversible can use bounded approval policies; privileged or irreversible actions should require explicit approval with enough context for the reviewer to make a real decision.
The approval screen should show what will change, which identity will perform the action, the target system, and the evidence used to choose the action. “Allow tool?” is not meaningful governance.
Log decisions, not just HTTP requests
Traditional API logs are insufficient for an agentic workflow. Capture the user intent, selected server/tool, validated arguments, policy decision, approval event, tool result, model interpretation, verification result, and final outcome. This creates the causal record needed for incident analysis.
Keep secrets and sensitive payloads out of logs where possible. Store identifiers, hashes, classifications, and redacted summaries when full payload retention is inappropriate.
Production readiness checklist
Review history
August 9, 2026 — Reworked as a flagship XTIANZ guide with current primary sources, original decision frameworks, and technical review.
Suggest a correction ↗Disclosure
AI tools may assist research organization, drafting, code, and quality checks. The final structure, claims, frameworks, and publication decision are manually reviewed. XTIANZ does not accept payment to change technical conclusions.