Disclosure: BlueBear sells a platform that is an MCP gateway, so we have a commercial interest. That is a direct conflict of interest on this topic, so the article sticks to operational properties you can verify yourself, including on a gateway you build.
The thing that makes it valuable makes it dangerous
A gateway is worth having for one reason: it is the single place where a rule can be applied to every agent, every tool call and every credential at once. Enforce something there and it is enforced everywhere. That is a genuinely strong position and the reason the pattern keeps appearing.
It also means every agent action depends on it, every credential passes through it, and its failure is not one service degrading but the whole agent estate stopping or, worse, continuing without controls. Once agents matter, the gateway is a load-bearing dependency, and it should be operated like one rather than like the internal proxy it usually started as.
This article assumes the argument for having one is settled and deals with what changes when it is real. It deliberately does not re-cover credential scoping, which is a decision in its own right.
Check per call, not per session
The most common gap is authorising at session start and trusting the session thereafter. That authorises the plan the agent presented, which is not necessarily the plan it executed -- agents revise as they go.
Per-call checks against the presented credential are the only version that describes what actually happened. This is also what makes the record defensible: an entry saying the call was allowed, on this basis, against this system, is evidence. An entry saying the session was approved earlier is context.
Decide what happens when the gateway is down
This deserves an explicit decision, because the default is usually accidental.
Fail open means agents keep working during an outage with no policy enforcement and nothing recorded. It is the option that keeps the demo running and produces exactly the gap you do not want in the window where something is already wrong. Fail closed means agents stop, which is disruptive and honest.
Closed is right in almost every case. The consequence is that gateway availability becomes a real requirement, with the redundancy and on-call posture that implies. Teams that pick open usually have not framed it as a choice at all.
The failure modes that only show up under load
Three are worth anticipating, because each is invisible in testing:
Timeouts that outlive the work. A long default timeout on an upstream that hangs means requests pile up holding connections. Agents retry, which multiplies the pileup. A bounded timeout is worth more than a generous one, because the failure you can see is cheaper than the one you cannot.
Retries without idempotency. An agent retrying an action that already partially succeeded produces duplicates -- duplicate orders, duplicate messages, duplicate charges. If the gateway does not require an idempotency key for actions that are not naturally repeatable, retry safety is left to whichever agent author thought about it.
Credential refresh under concurrency. Short-lived credentials are correct, and their refresh path is often the least-tested code in the system. When many agents notice expiry simultaneously, a naive implementation stampedes the identity provider and every agent fails at once.
Record the decision, not the payload
The gateway is the natural place to write the authorisation record because it is the only component that sees the identity, the target and the decision together. Capture the acting identity and who it acted for, the target system, the operation, the decision and its basis, an idempotency key where relevant, and the outcome.
Not the payload. A gateway that logs request bodies becomes a copy of everything flowing through it, which is a different and larger problem than the one it was solving.
Four checks
- Stop the gateway in a test environment. What do the agents do? If they keep working, you are failing open, whether or not anyone chose that.
- Is authorisation evaluated per call? If it happens at session start, your records describe intent rather than action.
- Replay a write twice with the same idempotency key. Two effects means retries are unsafe and will eventually be exercised.
- Expire many credentials at once. If refresh stampedes, you have found your next incident before it found you.
What this costs
Per-call authorisation is a design decision with a small latency cost, usually a few milliseconds against calls measured in hundreds. Idempotency requires a contract with agent authors, which is coordination rather than code. Availability is the expensive one, because fail-closed means the gateway inherits the uptime requirement of everything behind it.
What to watch once it is load-bearing
A gateway that works is easy to stop looking at. Four signals tell you it is degrading before an agent does, and none of them are CPU or memory.
Authorisation denials by tool. A rising denial rate on one tool usually means a legitimate workflow changed and nobody updated the grant — the agent is being blocked from work it should be doing. A denial rate of zero across everything is equally informative: it usually means the policy is permissive rather than that behaviour is perfect.
Time to first byte, per provider. This is the number that catches slow degradation, and it matters more than total duration because most deadlines in this path are first-byte deadlines. A provider drifting from two seconds to twenty will not fail anything until it crosses a timeout, and then everything fails at once.
Credential age. If short-lived credentials are working, age stays flat. A creeping maximum age means refresh is failing somewhere and the system is running on credentials that should have expired.
Retries per successful action. Rising retries mean either a flaky upstream or an agent that has learned a failing pattern. Either way it is spend you are not getting work for.
The failure you should rehearse
Pick a quiet window and stop the gateway deliberately. Watch what the agents do, what the operators see, and how long it takes anyone to notice.
Almost every team discovers something in that ten minutes: an agent that retries hard enough to make recovery slower, an alert that never fires because it monitors the gateway process rather than agent success, or an operator runbook that assumes a person is watching. Finding those while you chose the timing is considerably cheaper than finding them otherwise.
BlueBear Production MCP Gateway Acceptance Runbook
A gateway is ready only when operators can prove both allowed work and safe failure. Run the cases below against one real MCP-backed workflow before increasing production scope.
| Test | Expected behavior | Evidence to retain |
|---|---|---|
| Allowed action | The assigned tool runs with the scoped credential and returns a correlated receipt. | Actor, workspace, policy, credential reference, tool call, result, and outcome. |
| Unassigned tool | The request is denied before connector execution. | Requested capability, effective assignments, denial code, and no downstream call. |
| Audience mismatch | A token or credential intended for another resource is rejected. | Issuer/audience validation result without exposing secret material. |
| High-impact action | Execution pauses for the named approval authority; expired or changed approvals fail closed. | Action fingerprint, reviewer, decision, reason, expiry, and post-approval receipt. |
| Timeout and retry | Retries follow the declared policy, avoid duplicate side effects, and preserve the originating request. | Attempt numbers, idempotency key, tool statuses, latency, and terminal state. |
| Emergency containment | Operators can disable a connection or capability and identify affected sessions. | Control change, actor, time, impacted workflows, and recovery approval. |
BlueBear can provide the workspace, policy, approval, credential, and session evidence around the gateway. The customer still owns tool risk classification, downstream authorization, retention, incident command, and the final production acceptance decision.
Questions people actually search for
- what makes an mcp gateway production ready
Three properties beyond working correctly. It enforces authorisation per call rather than trusting the caller, so a compromised agent cannot exceed its grant. It records enough per call to answer who did what against which system afterwards. And it has a defined behaviour when it is itself unavailable, because a gateway that fails open silently removes every control it was providing.
- should an agent gateway fail open or fail closed
Closed, in almost every case, and the decision should be explicit rather than emergent. Failing open means that during an outage every agent operates with no policy enforcement and no recorded evidence -- the exact window in which you would most want both. The cost is that agents stop when the gateway stops, which is why the gateway needs to be operated as a critical dependency rather than a convenience.
- where should authorization happen for ai agent tool calls
At the gateway, per call, against the credential presented -- not in the agent and not only at session start. Checking at session start authorises a plan; checking per call authorises what actually happened. Since agent plans change during execution, the two are not equivalent, and only the per-call check is defensible after the fact.
- what should a gateway record for every agent tool call
The acting identity and who it acted for, the target system, the operation, the authorisation decision and its basis, an idempotency key where the action is not naturally repeatable, and the outcome. Deliberately not the payload. That set answers the questions asked after an incident without turning the record store into a copy of the data.