Trace one call through it. The application posts to the gateway rather than to the provider, and the gateway runs input guardrails, then authentication and policy, then model routing, then the upstream call, then output guardrails on the way back [4]. The ordering is where the value sits. Policy evaluates before routing, so a rule cannot be dodged by pointing a client at a different model [4]. The return path exists for the reverse failure, where the model itself emits sensitive information or malformed structured data [12].
The duplication argument survives arithmetic, which is more than most architecture arguments manage. The write-up's team ships six controls in a single application [1], and its drift scenario spans 30 services [7]. That is 180 enforcement points which all have to agree [1]. Consolidated, the same six controls are six rule definitions, a thirtieth of the surface to keep in sync [2]. The inline version it starts from is four lines: test `contains_secret(prompt)`, raise `SecurityError`, otherwise call `llm.chat` [15]. Four lines is easy to write, and just as easy to forget once thirty teams are each maintaining their own copy.
Where the TLS comparison [2] stops being load-bearing is the nature of the check. Terminating TLS is deterministic and local. Detecting prompt injection is, by the author's own account, harder than matching a credit-card regex and may require specialised classifiers or external guardrail services [10]. That is a network call with a tail latency, sitting in the path of every turn. Bifrost's answer is per-rule sampling and timeouts alongside CEL scoping [8]. Sampling is the honest option for a detector you are still calibrating, though a rule that runs on a fraction of traffic is measurement rather than enforcement. The source does not say what happens when the timeout fires, and that default is what decides whether the classifier is advisory or a hard dependency of every chat turn.
Treat the 30-service estate as a description of someone else's shape. For the arithmetic to transfer, you need more than one provider live in production, and you need rules that are genuinely shared policy rather than per-product judgement. The CEL scoping matters at that point [9], because without request-context conditions you get a gateway deployment per rule set, and the duplication has moved one hop rather than gone away. Same for the rule assignments the article sketches: a customer chatbot gets injection, PII and content checks, an internal coding assistant gets secrets and credential detection [14]. The distinction between the two is policy, not platform.
In my context the service count is still low enough that a shared library lands everywhere on upgrade, and that is the only reason I have not moved the checks out. The moment agents start opening provider connections that nobody registered, the library stops being the boundary and the gateway becomes the cheaper answer [16].
