In-path gateways
A dependency you can see is still a dependency.
Routing every call through one intermediary gives a single place to intercept it. It also means that intermediary's uptime becomes part of your agents' uptime, and that every payload passes through it on the way. FaburAI decides who may reach what without carrying the call — so an outage on our side is never an outage on yours.
A rollout plan needs all three answered.
Interception, availability and data exposure sound like one architecture question from a distance. They are three separate trade-offs, and an in-path gateway answers all three at once with the same choice — its own position in the call — which means the two you did not ask about come bundled with the one you did.
Interception answers: can we see the call
A single place every request passes through, which makes governing it straightforward.
Availability answers: what happens if it's down
If the intermediary is unreachable, the calls routed through it are affected too — by construction, not by a bug.
Data exposure answers: what passed through it
Carrying the call means carrying the payload — the arguments sent and the data returned, not just the fact that a call happened.
Six questions, asked the same way every time.
Every cell below states what that category actually does for that row — not a checkmark, not an X, and not left out to make the comparison look one-sided.
| Criterion | In-path gateway | FaburAI |
|---|---|---|
| Discovery model | Governs what is routed through it. A call that reaches the tool by another path is invisible to it. | Governs what is registered and observed regardless of path — including a call that never touches a shared intermediary. |
| What it governs | Every request routed through the gateway — traffic and routing, not the data behind it. | Every call an AI actor makes to a tool, resource, or data system, down to the column. |
| When it acts | In line, on every request — the call cannot proceed until the gateway forwards it. | Continuously, at the moment of the call, without carrying the call itself. |
| What it produces | Traffic logs and routing decisions for what passed through it. | A decision record: the AI actor, the user role behind it, what it reached, the outcome, and the rule that decided. |
| Data residency | Request and response payloads pass through the gateway — through vendor infrastructure, when the gateway is vendor-operated. | Payloads never reach FaburAI. Only a payload-free decision record leaves the customer's environment. |
| Where enforcement happens | At the gateway itself, which makes the gateway's own availability part of the call's availability. | Inside the customer's environment, evaluated locally against policy already retrieved — the call does not depend on FaburAI being reachable. |
One call, carried through. One decision, made alongside.
Laid out side by side, the gap is what breaks when the intermediary does. A position in the call is a liability the call inherits — a position alongside it is not.
Addressed to the tool, but routed to the gateway first.
The call, and its payload, pass through the intermediary.
Only after the gateway has carried it the whole way.
The call goes straight to its destination — FaburAI is not a hop in it.
Locally, against policy already retrieved. Allow or deny.
A payload-free decision record, not the payload itself.
The trade is real, and worth stating plainly: staying out of the call means FaburAI never sees the payload, so it cannot inspect content the way an intermediary can. What it buys back is bigger — an outage on FaburAI's side never touches your agents, and your data never has a reason to leave your network in the first place. Deciding who may reach what does not require reading what they sent.
Turning FaburAI on does not mean turning your gateway off.
Enforcement mode is set per MCP server, so adopting FaburAI is not a migration of the request path — nothing already in place has to move before FaburAI can start recording what would happen.