How OrcaRouter inspects every request

The gateway sits between your agent and every model it calls. That makes it the single point that sees every call regardless of provider — every prompt, every response, every tool call, and every outbound request your agent routes through it — no matter which SDK issued the call. That choke point is where inspection and enforcement belong. (What it can’t see — a tool that runs entirely inside your process and never crosses the gateway — is covered in §4.) This page explains exactly what the gateway can and cannot see, how detection works, and how to close the gaps.

​

1. Why the gateway is the right inspection point

Most security controls live in the application: library wrappers, agent framework hooks, per-provider SDKs. Those controls have a fatal structural flaw — they break as soon as you add a second provider, swap frameworks, or let an agent self-install a new skill. The gateway has none of those seams. Every call your agent issues, regardless of model, provider, or how the tool capability arrived, transits a single point before anything reaches the upstream. That is the only layer where you can make a guarantee: if it happened, the gateway saw it. OrcaRouter uses that position for two distinct enforcement passes:

• Guardrails screen text — the prompt your agent sends and the response the model returns. A guardrail block returns HTTP 400 guardrail_blocked and costs no quota.
• The Firewall judges actions — the tools an agent calls, the MCP servers it reaches, and the network destinations it reports. A firewall deny returns HTTP 400 firewall_blocked on the inbound surface, or a tool error on the MCP surface, so the model sees the rejection and can reason about it.

Both layers are configured once in your workspace and attach to an API key. No redeploy. No SDK change. Your agent keeps calling https://api.orcarouter.ai/v1 exactly as before.

​

2. The four enforcement surfaces

The Firewall evaluates every tool call against exactly one surface — the point in the call lifecycle where the gateway sees it. Guardrails add two more text stages that layer on top of the surfaces above: input (the request prompt and messages) and output (the model’s response text). A single request can pass through all of them.

​

3. First-use detection

This means a novel tool lands in the Discovered tools view the moment it appears on a request, even if no rule names it. Turn on observe mode to record every tool call that has no matching rule as a coverage gap — that view drives policy authoring from real traffic.

​

4. What the gateway cannot see

The inspection guarantee covers calls that cross the gateway. It does not extend to a tool your agent runs entirely inside its own process — one that reads a local file, calls a library function, or executes a subprocess without ever sending a message to the gateway. That is an honest boundary, not a design flaw. The design goal is to make the gateway the audited path for the calls that matter — the ones with real-world consequences: If you have tools that run in-process today and have real-world consequences, the path to coverage is to register them as MCP servers behind the Firewall MCP gateway or to call the evaluate hook from your agent loop before dispatching.

​

5. Role gating on inspection data

Access to inspection surfaces is role-scoped within your workspace:

​

6. Where to go next

The gateway is the single inspection point for every call that crosses it — configure your policies once and every provider, every agent, and every tool call is covered.