The trust boundary
The model may propose a tool call. Deterministic application code must authenticate the caller, authorize the exact operation and target, validate arguments, control execution and record the resulting side effect.
An MCP server should expose curated domain capabilities such as get_incident_context or restart_approved_service, not generic primitives such as unrestricted HTTP requests, shell execution or arbitrary SQL.
Required security layers
Carry an attributable workload or delegated user identity through every tool invocation.
Issue capability-specific authorization rather than inheriting the caller’s complete application access.
Reject unknown fields, invalid identifiers, unsafe ranges and oversized inputs before business logic runs.
Evaluate subject, action, resource and environment independently of model-generated reasoning.
Cap response size, classify fields and redact secrets before tool output enters model context.
Record the normalized call, policy decision, executor identity and material outcome.
A defensible invocation flow
- The agent selects a named tool from an allowlisted manifest.
- The gateway binds the request to an authenticated user or workload identity.
- Strict schema validation normalizes and rejects malformed arguments.
- A policy service authorizes the exact action against the exact target.
- A deterministic executor performs the operation with narrowly scoped credentials.
- The response is bounded, classified and redacted before returning to the model.
- The complete decision and outcome are written to the audit trail.
Separation of duties
The model should not hold the credential that executes its proposal, and the executor should not infer authorization from natural-language reasoning.
Threats and corresponding controls
| Threat | Control | Verification |
|---|---|---|
| Prompt-injected privileged action | Independent policy decision and operation allowlist | Adversarial retrieval tests cannot expand scope |
| SSRF through a generic fetch tool | Domain-specific connectors and destination allowlists | Private, link-local and unapproved destinations fail closed |
| Cross-tenant access | Tenant-bound identity and datastore enforcement | Negative authorization tests at tool and storage layers |
| Secret leakage in tool results | Field classification, redaction and result caps | Canary secrets never enter model context |
| Replay of a destructive request | Short-lived authorization, nonce and idempotency key | Repeated requests do not duplicate side effects |
Architecture review checklist
- Can every tool be mapped to one business capability and one accountable owner?
- Are write operations distinguishable from reads in both policy and telemetry?
- Can a retrieved document alter authorization or only influence the proposal?
- Are service credentials inaccessible to the model runtime?
- Can investigators reconstruct the exact arguments and side effects months later?
- Does the system fail closed when identity, policy or audit dependencies are unavailable?
Authorship and evidence scope
This is a first-party architecture note based on Salah Awad’s stated practice designing MCP tool surfaces and defense-in-depth systems. It is not a claim that MCP alone provides these controls, nor independent certification of a specific confidential implementation.