MCP Gateway Security: Prove Every Tool Call Crosses the Gate

MCP gateway security is not established by putting a proxy in the architecture diagram. The defensible default is stricter: prove that each protected production tool call crossed the intended gateway, used the expected policy revision, carried a validated identity and least privilege scope, produced an audit receipt, and ended in a verified effect or an explicit waiting state . That distinction matters because “gateway” describes a placement, not an outcome. The current US search results mix gateway products, comparisons, architecture explainers, and security claims. Their common promise is a central control point between agents and MCP servers. The operational question is whether that point actually owned a particular call. The MCP Authorization specification defines authorization for HTTP transports, protected resource metadata, discovery, and scope selection. The protocol's security best practices require implementers to consider confused deputy risks, token audience validation, token passthrough hazards, consent, and auditability. Neither document turns the mere presence of an intermediary into proof that every route is controlled. Define the evidence contract before routing traffic Begin with a route manifest small enough to ship beside the gateway configuration: The manifest creates five testable assertions: 1. the request passed through the named gateway rather than a direct server URL; 2. the gateway validated a non secret workload or user identity; 3. the decision came from the expected, fresh policy revision; 4. the granted scope covered the selected tool without silently widening access; 5. the gateway emitted an audit receipt that can be joined to the downstream result. The route assertion is not theoretical. Cloudflare's current MCP server portals documentation describes an optional Gateway path for tool calls, while background synchronization connects directly to upstream servers. It also warns that a blocked user can still use an upstream server's direct URL unless authentication is enforced at that server. Those are legitimate product specific behaviors, not universal MCP rules, but they demonstrate why an inventory must include all paths rather than assuming a portal or gateway has eliminated side doors. Record one content free envelope per decision. It does not need prompts, tool arguments, result bodies, access tokens, or secrets: Opaque identifiers are enough to test route ownership, identity enforcement, policy freshness, scope coverage, approval state, and receipt continuity. Keep secret values at their source. If an incident requires content inspection, treat that as a separate, explicitly authorized workflow with its own retention boundary. Authorization and policy enforcement are related but not interchangeable. The MCP specification says authorization is optional for an implementation; when HTTP authorization is supported, the protected server acts as an OAuth resource server. A gateway therefore cannot manufacture proof by noting that a bearer token existed. It must validate the intended resource and identity, evaluate the relevant tool policy, and preserve enough non secret evidence to explain the decision. MCP security guidance explicitly identifies token passthrough as an anti pattern because it can bypass controls and damage accountability. Replay eight states that “allowed” conceals The accompanying fixture contains eight synthetic requests. Its classifier applies the gates in operational order: Run it locally: Each verdict demands a different bounded response: Verdict What the evidence says Next action GATEWAY BYPASS The protected call used another route or gateway identity Inventory client and upstream endpoints; close or separately govern the direct path IDENTITY NOT ENFORCED The route was central, but the caller was not validated Reject anonymous production calls and fix workload or user identity at the boundary POLICY DRIFT The decision used an old revision or stale evidence Reconcile the running gateway with the approved policy artifact before retrying AUTHORIZATION GAP The tool or its required scope did not match the decision Deny the call, reduce scope, and add a tool level regression case AUDIT GAP The call may have been allowed, but no joinable receipt exists Repair the logging/export path; keep the verdict unknown rather than green EFFECT UNCERTAIN Transport or tool completion did not prove the destination Read the destination before retrying, especially after a timeout WAITING A protected action has a named approval dependency Notify the owner and preserve the deadline; do not label the agent stuck HEALTHY Route, identity, policy, scope, audit, approval, and effect agree Retain the receipts through the incident review window The precedence prevents a convenient approval wait from concealing a bypass or stale policy. WAITING is available only after route, identity, policy, authorization, and audit gates pass. Likewise, a successful downstream effect does not excuse a call that bypassed the control path. The experiment is deliberately content free. It checks a normalized contract, not a live gateway product. Map your gateway's fields to the fixture rather than copying field names as though MCP standardized them. The protocol defines messages and authorization behavior; gateway policy revision identifiers, audit receipt shapes, and destination verifiers remain implementation choices. Separate permission from the resulting effect An allow decision proves only that a policy permitted an attempt. It does not prove that the tool ran once, changed the intended destination, or produced the requested deliverable. For a mutation, join the gateway receipt to a destination receipt: This is especially important after a timeout. Retrying because the gateway did not receive a response can duplicate an effect that the upstream system already committed. EFFECT UNCERTAIN instructs the operator to reconcile the destination first. A gateway can rate limit or authorize a retry, but the destination is usually the stronger source for whether the original effect exists. For read only tools, the outcome may be a schema check, freshness assertion, or deterministic comparison against the task's required fields. For writes, prefer an API read back, immutable object version, provider message ID, commit hash plus checks, or another destination owned receipt. A tool's JSON RPC success result is weaker when the promised outcome lives elsewhere. A practical rollout can stay narrow: 1. Choose one production MCP server and one high impact tool. 2. Enumerate every client endpoint and direct upstream URL that can reach it. 3. Pin a gateway identity and policy revision in deployment evidence. 4. Send one permitted probe and one denied probe with opaque request IDs. 5. Verify caller identity, required scope, tool decision, freshness, and an audit receipt for both. 6. Try the documented direct route and prove it is blocked or explicitly governed. 7. Exercise an approval required call and retain it as WAITING until a named owner decides. 8. Simulate a timeout after the upstream effect, then prove the runbook reads the destination before retrying. 9. Repeat the probes after gateway, identity provider, policy, client, or MCP server changes. There are limits. This fixture does not test a particular vendor's parser, DLP engine, prompt injection defenses, or vulnerability scanner. It does not prove that a central gateway is the right architecture for every local STDIO server. A local process may need host level controls instead of a network gateway. It also does not make Sidewisp a required model or tool gateway. Sidewisp's intended role is adjacent: bring reachability, progress, tools, outcomes, time, and budget evidence into an agent health view and preserve human authority around recovery. Sidewisp is currently in private preview. The live experience is an early access website and interactive demonstration; a production MCP gateway adapter, live monitoring engine, and automated recovery executor are not shipped. Use the enforcement receipt with your current gateway and destination systems rather than assuming Sidewisp currently monitors or fixes them. The resolution is concrete: inventory the routes, pin the gate and policy, verify identity and least privilege scope, require a joinable audit receipt, preserve legitimate waiting, and check the destination before declaring success. MCP gateway security becomes operational evidence only when the control path and the effect agree.