Guardrails on Every Request, Not Gated Behind Enterprise

A guardrail that runs "sometimes" is not a guardrail — it's a false sense of security. The whole value of content safety is that the one request that would have leaked a customer's SSN or executed an injected instruction is the one that gets caught. That only works if the check is on the hot path of every call.

This post covers how NemoRouter applies guardrails inline, why they're free on every tier, and how scope precedence lets a strict per-key policy override a loose org default.

What does a guardrail actually do?

When enabled, a guardrail inspects request (and optionally response) content and can redact, block, or flag it. NemoRouter ships several kinds:

Redaction happens before the prompt reaches a provider, so the sensitive substring never leaves the gateway. A block stops the call entirely and returns a structured error the client can surface.

Why inline, and why on every tier?

Two deliberate choices:

Inline. Guardrails run in the request path, not as an after-the-fact log scan. A post-hoc scanner can tell you that you leaked PII yesterday; an inline guardrail prevents the leak today. The cost is a few milliseconds of pre-flight work, which is a trade every security-conscious team makes happily.

How does scope precedence work?

Guardrails attach at three scopes, and a request resolves the most specific one: key > team > org.

org policy:   redact-pii = on,  block-injection = on    (the floor)
team policy:  (inherits org)
key policy:   block-injection = on, blocklist = ["internal-codename"]
              → this key ALSO blocks a codename the org doesn't

The precedence is "most specific wins" so that a sensitive key — say, one used by a customer-facing chatbot — can be locked down harder than the org baseline without loosening anything globally. You raise the floor at the org and add stricter ceilings per key; you never have to weaken the default to make one key stricter.

This mirrors how the rest of the gateway scopes resources (org → team → key), so there's one mental model for budgets, rate limits, and guardrails alike.

What does a block look like?

A blocked request returns a structured, machine-readable error so clients can react deterministically instead of guessing:

{
  "error": {
    "type": "guardrail_blocked",
    "guardrail": "prompt-injection",
    "message": "Request blocked by guardrail policy",
    "scope": "key"
  }
}

A redaction is invisible to the client by design — the call succeeds, but the provider received [REDACTED] where the PII was. The redaction is recorded in the guardrail log so you have an audit trail of what was caught without storing the sensitive value.

Logging without re-leaking

There's a subtle trap: a guardrail that logs the exact thing it caught has just moved the leak from the provider to your log store. NemoRouter's guardrail logs record the event (which guardrail fired, on which scope, what action) but not the raw sensitive payload. You can answer "how often did the PII guardrail fire on this key" without any log row containing a customer's actual SSN. (See the data-policy and logging docs for the full retention and redaction model.)

Guardrails are part of the four-ceiling pre-flight

Guardrails are the content ceiling in the four checks every request passes: a call can be perfectly affordable and within every rate limit and still be stopped here, because cost and safety are orthogonal. A request only ships when it's both within budget and allowed.

The takeaway

Content safety is only as good as its coverage. Run guardrails inline so the dangerous request is caught before it leaves, scope them key > team > org so the strict cases can be strict without weakening the defaults, and log the event without re-storing the secret. Then "we redact PII" is a property you can prove on every call — not a checkbox on an enterprise quote. Configure them in the dashboard, free on every tier.