MCP connects your tools. Who controls the calls?
A CTO guide to MCP proxy architecture, trust boundaries, approval semantics, and production trust.
The decision in brief
Keep protocol routing, authorization, provider permission, execution, and operations as separate architectural concerns.
The gateway is a trust boundary
A gateway is useful when it is the place where a request gains context: who is asking, which client is acting, which connection is targeted, what tool and resource are involved, and what policy version applies. That context lets platform teams make a deterministic decision before dispatch.
The architectural mistake is to treat routing as authorization. The gateway should validate its own audience and credentials, preserve upstream consent boundaries, and fail closed when capability or resource coverage is unknown.
Illustrative scenario: a tool changes shape
Imagine an upstream tool adds a new argument that changes a read into a write. A gateway that merely forwards JSON may continue operating while its policy and review model lag behind. A governed path treats schema and capability changes as review inputs. This is an illustrative design scenario, not a reported event.
Model the path as separate stages: authenticate, authorize, obtain approval when required, record intent, dispatch, and classify the provider outcome. That separation makes retries and uncertain writes explicit rather than accidental.
Architecture checklist
Before scaling connections, write down the answers to these questions:
- Which MCP clients are supported, and how are their versions and configurations verified?
- How are upstream identities, scopes, consent, and token audiences separated from gateway identity?
- Where are reviewed tools, schemas, resources, and policy versions stored and changed?
- How are approvals bound to the exact principal, arguments, schema, expiry, and use count?
- How are timeouts and ambiguous provider writes represented and reconciled?
- Which controls enforce egress, private connectivity, retention, backup, and recovery?
A bounded evaluation with Durin
Durin gives a platform team a concrete request path to exercise: identity, default-allow policy checks, optional approval or disallow controls, scoped connections, and audit. An evaluation workspace can validate the model before provider activation. Discovery, remote provider activation, hosted identity, private connectivity, and operational assurance are production trust checks.
Use that boundary to build an architecture decision record. Name the capabilities the gateway proves, the capabilities network or clients must prove, and the gates that must pass before production exposure.