MCP Server Access: Direct vs Gateway-Brokered

Your AI agent needs to call GitHub, Salesforce and Gmail. You can connect directly, broker through a self-hosted proxy or terminate the connection at an identity-aware trust layer. The right answer depends on who is calling, what data is in play and how an auditor will reconstruct what happened. This guide is a decision framework, with the technical deltas that matter for regulated environments.

MCP architectures compared: Direct (agent connecting to many MCP servers, each with its own auth) vs Gateway-Brokered (agent through a single trust layer for identity, audit, policy, elicitation and origin isolation).

Three architectures

Same problem, three different blast radii.

At a glance

Where each architecture lands across the dimensions that matter for enterprise MCP access.

Dimension	Direct	DIY Broker	Trust Layer
Identity propagation	Long-lived bearer token. The MCP server sees one identity for all callers.	Per-user API keys forwarded as headers. Server trusts the proxy to assert identity.	Verified enterprise SSO identity terminated at the edge. Per-server credentials minted on demand.
Auth method support	Bearer token only. No OAuth2 consent flow.	Bearer or API keys. OAuth2 typically not supported.	Native multi-auth: OAuth2 user-mode (with consent) and bearer agent-mode side by side on the same provider.
Credential storage	Provider keys live as environment variables or in the agent runtime.	Vault or secrets manager. Plaintext in proxy memory at request time.	Per-tenant envelope encryption. Decryption scoped to the request, never logged, never returned to the client.
Per-call authorization	None. Any tool the token can reach is callable.	Tool allowlists at the proxy. Coarse-grained.	RBAC and ABAC on every tool invocation. Per-user, per-tool, per-argument policy.
Audit	Whatever the agent runtime logs. Usually request-only.	Proxy access logs. Forgeable. Not tied to a verified user.	Cryptographically signed, tamper-evident receipts per tool call. Replayable weeks later.
Sensitive-input handling (MCP elicitation)	Form-mode prompts route through the model context. Credentials and confirmations leak into prompts.	Same. The proxy has no protocol-level path to bypass the model.	URL-mode elicitations route the user to a hosted page. Credentials never transit the model or the MCP client.
Tool View origin isolation	All tool views render in the agent runtime origin. One rogue widget reads cookies for every other one.	Same. Proxy serves HTML on a single origin.	Per-server SHA-256 subdomain (e.g. a1b2c3.mcpapps.example.com). Strict CSP per server. Browser enforces isolation.
User mode vs agent mode	Not modeled.	Not modeled.	First-class distinction. User-mode tokens (interactive, OAuth2) and agent-mode tokens (workload-bound) are routed and authorized differently.
Multi-tenancy	Single tenant per deployment.	Possible but requires proxy-side tenant isolation logic.	Tenant-scoped MCP endpoints by design (e.g. acme.mcp.example.com). Cryptographic tenant isolation throughout.
Compliance posture	Operator owns it. No SOC 2 attestation transfers.	Operator owns it. Proxy code is in scope of audit.	SOC 2 Type II covers the trust layer. Verified user identity, signed audit and per-tenant isolation are out of the box.

Delta 1

Identity propagation

In a direct connection or a self-hosted proxy, the MCP server sees one identity. Either a long-lived bearer token issued for the integration, or a per-user API key forwarded as a header that the server has to trust. Neither of these is a verified user identity. The server cannot evaluate "is alice@acme allowed to delete this issue" because alice is not on the wire. The server only knows the token is valid.

A trust layer terminates enterprise SSO at the edge. Every request carries a verified subject that came from your IdP (Okta, Entra ID, Google Workspace) and was bound to the session through OIDC. The edge then mints per-server credentials on the fly, scoped to the verified user and the specific tool call. The MCP server still receives a token. The difference is what produced that token and what it represents.

Delta 2

Sensitive-input routing

The MCP specification (revision 2025-11-25) defines two elicitation modes. Form mode collects structured input through the MCP client. URL mode redirects the user to a hosted page so the data flows directly between the user's browser and the server. The distinction is not cosmetic. Form-mode inputs travel through the model context. URL-mode inputs do not.

Direct connections and DIY proxies typically only implement form mode. That means an OAuth authorization, an API key or a destructive-action confirmation lands in the prompt. From there it propagates to the model provider, the agent runtime logs, conversation exports and any caching layer in between. The protocol gives you a way out, but only if the client-server pair both support URL mode and the broker enforces it.

A trust layer treats URL mode as the default for sensitive operations. Credential pickers, OAuth consent screens and confirmation pages render on a Ferentin-hosted origin, the user interacts directly with the server through the browser, and the MCP client is told via elicitation/complete notification when the flow is done. The model never sees the secret. The agent runtime never sees the secret. The audit log records that a URL-mode elicitation completed for a verified user.

Delta 3

Tool View origin isolation

MCP Apps (SEP-1865) lets servers ship interactive HTML widgets that render inside the host. A GitHub server might return a pull-request preview card. A Stripe server might return a payment confirmation widget. A Calendar server might return an availability picker. All of these are arbitrary HTML running in a sandboxed iframe.

The browser's same-origin policy is the primary defense between two widgets. If every tool view loads from the same origin, that defense does not apply. A compromised or malicious widget can read storage and cookies for every other widget served from the same host. A direct setup or a DIY proxy that serves widgets from tools.example.com has this problem by construction.

A trust layer scopes each MCP server to its own origin: a SHA-256-derived subdomain like a1b2c3.mcpapps.example.com. The browser treats each subdomain as a separate origin. The server's declared CSP, including resource-src, connect-src and frame-ancestors, is enforced per server. A widget from one server cannot reach into another, and the host page cannot reach into either.

Decision framework

Which one should we run?

Two questions get most teams to the right answer. The first is about the user count: are we exposing this MCP server to multiple humans or workloads, or to a single developer running locally? The second is about the data sensitivity: would an auditor care about who called what?

Direct

Solo developer, one user, low-stakes data. The MCP client and the server live on the same trust boundary. No enterprise governance is in scope. Pick this when nobody else is calling the server through your agent.

DIY broker

Single team, internal-only data, willingness to own the stack. Works if you can credibly build verified identity, per-call policy, signed audit and origin isolation. Most teams underestimate the last three. See the OSS gateways comparison for what the open-source options do and do not cover.

Trust layer

Multiple teams, regulated data, an auditor in the room. Verified enterprise identity at the edge, RBAC and ABAC per tool call, signed receipts, URL-mode elicitations and per-server origin isolation are all out of the box. SOC 2 boundary transfers to the trust layer.

FAQ

A vault solves credential storage but not the three problems that matter most for MCP: per-call authorization tied to a verified user, tamper-evident audit of every tool invocation and protocol-level routing of sensitive inputs around the model context. Vault plus direct connection still leaves you with one identity at the MCP server, no policy gate and form-mode elicitations leaking through prompts.

Broker MCP through a trust layer

Verified enterprise identity at the edge. Signed audit on every tool call. URL-mode elicitations. Per-server origin isolation. Out of the box.

Get Started Free Book a Demo