Guardrails as a perimeter

Where PII, injection, geo, and spend checks sit relative to your app, and why enforcing them at the gateway beats enforcing them in application code.

The question teams usually ask is "should we check for PII in our app, or rely on the gateway?" The answer is: put the check at the gateway, because that's the one place every request — from your app, from an agent, from a third-party plugin you didn't write — is guaranteed to pass through.

Why the perimeter, not the app

• Every caller shares one enforcement point. Application-level checks have to be reimplemented in every codebase that calls a model — a Python backend, a browser extension, an agent runtime. A gateway-level guardrail is written once and applies to all of them automatically.
• A guardrail can't be routed around by mistake. If PII redaction lives in a middleware function, a new code path (a background job, a script someone wrote for a one-off task) can easily skip it. At the gateway, there's no request that doesn't pass through the check — including key-scoped requests coming from agents you don't directly control.
• Policy changes don't require a deploy. Turning on a new geo restriction or lowering a spend cap takes effect the next request, not the next release cycle.
• The failure mode is visible, not silent. A blocked request returns 403 policy_violation with the specific rule that fired — see Guardrails — rather than failing in an app-specific way that's hard to distinguish from a bug.

What still belongs in your app

Guardrails cover request-level policy: PII, injection, geo, spend, and model allowlists. They don't replace domain-specific validation — checking that a generated response fits your product's schema, or that a tool call an agent wants to make is one your business logic actually permits. Put the gateway between your app and every provider; keep the app-specific judgment calls in your app.