Guardrails

Guardrails screen model input, output, retrieved chunks, memory, persona text, and tool arguments at their governed entry points. Policies resolve in two steps — first the PARENT is selected, then the organization tightens it:

parent      = the application's policy, when that application defined one
              the engine baseline, otherwise

effective   = parent + organization override + optional agent policy

The engine baseline is the fallback parent, not a mandatory floor. An application that defines its own policy REPLACES the baseline for every organization it owns — the two are not merged, and the application's policy may be weaker: it may disable a check the baseline enables, choose a less restrictive action, drop entities or categories, or govern one direction only.

Below the parent nothing changes. An organization override may only tighten whichever parent was selected, and the per-agent policy remains an additive layer that runs around the ordinary screening rather than replacing it.

Available checks

Configured actions are:

allow is a runtime decision, not a configurable enforcement action.

Engine baseline

The engine-wide policy every organization falls back to when its application has defined none.

GET /v1/admin/guardrails/baseline
PUT /v1/admin/guardrails/baseline

Example policy fragment:

{
  "checks": {
    "safety": {
      "enabled": true,
      "action": "block",
      "categories": ["hate", "violence", "sexual", "self_harm"],
      "threshold": "medium"
    },
    "pii": {
      "enabled": true,
      "action": "redact",
      "entities": ["email", "phone", "credit_card", "iban", "ssn"]
    },
    "injection": {
      "enabled": true,
      "action": "monitor"
    }
  }
}

Read the current resource first and preserve its version/conditional-update contract when writing. Policy changes are audited.

Application policy

An application manages the policy its own tenants resolve against, with its own credential. Self-scoped: the credential names the application, so there is no id in the path and no way to read or change another application's policy.

GET /v1/application/guardrails
PUT /v1/application/guardrails
DELETE /v1/application/guardrails

GET returns the parent as it stands, and says where it came from:

{
  "source": "application",
  "version": 2,
  "config": {
    "checks": { "pii": { "enabled": true, "action": "monitor", "entities": ["email"] } },
    "apply_to": { "input": true, "output": true }
  }
}

source is "application" when this application defined the policy — in which case the engine baseline is not consulted for its tenants at all — and "platform" when it has not, in which case the returned config IS the engine baseline.

PUT takes one complete policy and replaces the previous one whole: an omitted check is absent, never inherited from the previous version or from the baseline. It is validated structurally (known checks, known actions, at least one direction, lists of at most 256 entries, RE2-compilable patterns) and not against the engine baseline — a weaker policy is accepted. version starts at 1 and increments on every replacement.

DELETE removes the policy. The engine baseline resumes as the parent on the very next governed request, with nothing to invalidate, and organizations keep their own overrides exactly as they were. Deleting when there is no policy answers 404.

Both mutations are audited as guardrail.application.set and guardrail.application.delete, recorded against the application rather than a person, and carrying no policy content.

Organization policy

Platform operators can manage a specific organization:

GET /v1/admin/orgs/{org_id}/guardrails
PUT /v1/admin/orgs/{org_id}/guardrails

Organization administrators manage their own override:

GET /v1/guardrails
PUT /v1/guardrails
GET /v1/guardrails/effective

The effective endpoint is the best way to verify that an override tightens the parent as intended — and it resolves through exactly the same code the runtime does, so what it reports is what the next request will obey. An override that would weaken the selected parent is refused with 409, whichever parent that is: an organization of an application with a monitor-only policy may set monitor, while an organization whose parent is a redact baseline may not.

Provision the classifier

Safety classification can be supplied by a kind: "guardrail" connector or an environment-configured compatible endpoint. A registered connector takes precedence.

With no classifier provisioned, classifier-backed screening is off. Once a classifier is registered, its failure returns 503 for affected calls instead of silently allowing unscreened content.

Deterministic PII and topic checks still follow their configured policies. Built-in English/French injection signatures provide explainable evidence, but the semantic classifier confirms them before enforcement; organization-authored injection patterns remain authoritative.

Both provisioning paths — the environment endpoint and the connector that overrides it — are covered end to end by the acceptance suite, including which one answers when both are present.

Measure the classifier before enforcing

Injection detection combines explainable English/French signatures with a semantic classifier that owns the built-in verdict and generalizes to other languages and paraphrases. Before tightening injection to block, measure the classifier you actually deployed:

GUARDRAIL_URL=… GUARDRAIL_TOKEN=… make guardrail-eval

It scores a balanced 240-sample French, German, Dutch, and English corpus — 20 direct injections, 20 injections hidden inside retrieved content, and 20 hard-negative benign samples per language — and prints recall and false-positive rate per language. It uses the engine's own classifier prompt and verdict parser, so the numbers describe the endpoint the engine talks to. Pass -min-recall and -max-false-positive-rate to gate a release on the conservative 95% confidence bounds rather than the point estimates.

Retrieval and agent behavior

• retrieved chunks with prompt-injection findings are discarded even when the policy action is monitor;
• an agent policy is additively screened around every governed turn;
• blocked tool arguments are never executed;
• guardrail events contain check/category summaries, not the screened content;
• mid-stream blocking does not emit a false clean terminal event.

Test policies with representative safe, unsafe, multilingual, and adversarial examples before enforcement. Start new classifier-based policies in monitor mode, inspect audit results, then move to redact or block with an explicit change record.