I would not ship a remote MCP server just because the OAuth flow works. Authorization proves that a client can ask for access. It does not prove that the right user context reaches every downstream call, that the model sees only the tools it needs, or that a tool update will not quietly widen the blast radius next week.
That is the practical line I draw after reading the current MCP authorization spec, OpenAI's connector safety notes, and the recent research measuring real remote MCP deployments. MCP is becoming the normal way to expose tools to agents. The risk is that teams treat it like a simpler OpenAPI wrapper, when it is closer to a privileged runtime boundary.
The checklist
1. Bind every token to one resource
The 2025-06-18 MCP authorization spec leans on OAuth 2.1, protected resource metadata, authorization server metadata, dynamic client registration, and resource indicators. The important implementation detail is not the acronym stack. It is audience binding.
A remote MCP server should reject tokens that were issued for another resource. It should also avoid passing the client's inbound token through to an upstream API. If the MCP server calls GitHub, Stripe, Linear, or an internal service, it should use a separate downstream token issued for that downstream resource.
That sounds obvious until an agent platform grows from one internal server to ten vendor and team-owned servers. Token passthrough becomes tempting because it is faster than building a proper exchange. It also turns the MCP server into a confused deputy.
My rule: write the expected resource audience into the server contract, test it with a deliberately wrong token, and log the rejection path. A security control that only exists in a diagram will drift.
2. Treat tool approval as a product control
OpenAI's remote MCP guidance is blunt about the trust boundary: a malicious server can exfiltrate data from model context, and sensitive actions should use approval flows through require_approval and allowed_tools.
I like making approvals boring and typed:
| Tool class | Default policy | Example |
|---|---|---|
| Read-only lookup | allowed with logging | search issues, read docs |
| Low-risk mutation | approval on first use per task | create draft, add label |
| External side effect | approval every time | send email, charge card |
| Secrets or admin | separate human workflow | rotate key, invite user |
The mistake is to ask, "Do we trust this MCP server?" That is too broad. Ask whether this user, in this task, with this model context, should call this specific tool with these arguments.
This is also where I would reuse the same discipline from agent-ready issue writing: scope the work so the agent has fewer reasons to improvise.
3. Keep the tool surface small enough to inspect
MCP makes discovery convenient. Convenience can become tool sprawl.
A server with thirty loosely named tools is harder for a model to use and harder for an engineer to review. Recent MCP architecture research frames this as a production pattern problem: servers often become resource gateways, tool orchestrators, stateful session servers, proxy aggregators, or domain adapters. Those patterns have different failure modes.
For a production integration, I want three artifacts before launch:
- A tool inventory with owner, risk tier, auth scope, and side-effect class.
- Golden-path transcripts for the top five tasks.
- Negative-path tests for denied scopes, expired tokens, malformed arguments, and downstream failures.
If a tool cannot explain its side effects in one sentence, it is probably not ready for an agent. Split it or hide it behind a narrower workflow.
4. Put a gateway in front of shared servers
A direct client-to-server connection is fine for demos. For a company-wide agent platform, I would put a small governance gateway between hosts and shared MCP servers.
The gateway does not need to be dramatic. It should enforce server allowlists, tool allowlists, per-user scopes, rate limits, approval requirements, and request logging. It should also stamp each call with task id, user id, model id, server version, and tool version.
That version data matters. OpenAI's docs call out that MCP servers may update tool behavior unexpectedly. Without versioned logs, an incident review turns into guesswork.
This is the same reason I liked the isolation story in Vercel Sandbox for agentic code execution. The useful unit is not just the model call. It is the execution envelope around the call.
5. Audit what the model sent, not just what the API returned
The 2026 measurement work on remote MCP authentication is a warning shot. The paper found thousands of live remote MCP servers and reported widespread authentication weaknesses, including unauthenticated tools and OAuth deployment flaws in tested servers. I would not treat those numbers as a universal law, but I would treat the direction as credible: the ecosystem is moving faster than its governance habits.
For teams shipping MCP integrations, logs should answer these questions:
- Which prompt or task caused the tool call?
- Which user and workspace authorized it?
- Which tool arguments left the model boundary?
- Which external service received data?
- Which approval, if any, allowed the action?
- Which response came back into model context?
Do not log secrets casually. Redaction is part of the logging design. But no logging is worse. It leaves you unable to separate a model error from a server change, a permission bug, or a malicious prompt injection.
What I would ship first
For a new remote MCP integration, I would start with read-only tools, one official server, a narrow allowlist, approval required for every mutation, and a weekly review of tool-call logs. Then I would relax controls only after seeing real task traces.
That sounds slower than connecting every useful SaaS account in a day. It is. But agent integrations fail differently from normal API integrations. The model can combine benign tools in surprising ways, user-provided text can become instructions, and server-side tool descriptions become part of the operating surface.
The forward-looking bet is still positive. MCP gives teams a shared integration layer instead of a pile of bespoke tool adapters. The production opportunity is to make that layer inspectable, reversible, and boring enough that agents can use it every day without turning every connector into a new trust crisis.