A policy is a choice.
Make the binding explicit.
Built-in MCIR memory brings relevant history. Skills define the job. Gateway Guardrails add the input and output checks you explicitly bind to a key. These are different responsibilities; none replaces application permissions.
No policy enforcement.
Per key. One bound policy. No silent fallback.
01try one controlled difference
Same input. Different binding.
The example starts unbound. Add an input-only policy, then an input-and-output policy. A second fixture shows an input denial stopping the path before a model call.
No gateway policy enforcement
Input reaching the model step
Prepare a release draft for release@example.test.
Final output in this example
{"status":"draft",}- No key binding to resolve.
- Input and authored output pass through unchanged.
Read the comparison without changing controls
- Unbound: the contact detail and malformed JSON pass through unchanged.
- Input-only binding: the example email is redacted; the malformed output is unchanged.
- Input + output binding: the email is redacted, then the authored JSON repair succeeds. Real repairs can fail and retain the original output.
- Instruction takeover fixture: either bound example policy denies the input before a model call. No binding means no gateway policy evaluation.
Authored example. Synthetic records, no live inference, and no network requests. These fixed outcomes explain phase and binding semantics; this is not a security test or the production evaluator.
02five documented evaluators
Specific checks, not a blanket safety claim.
| Evaluator | Phase / verdict | What it checks and what to remember |
|---|---|---|
pii_redactor | Input redact or flag | Known patterns for emails, phones, US Social Security numbers, Luhn-valid cards, and driver-license-shaped IDs. This is not detection of every kind of sensitive information. |
prompt_injection | Input deny or flag | Documented instruction-override, role-takeover, and prompt-exfiltration patterns. A pattern evaluator is not proof against every injection technique. |
json_repair | Output repair or flag | Detects malformed JSON and can request one repair attempt. If repair fails, the original buffer is retained. Always validate the result your application requires. |
max_length | Input and/or output truncate or flag | Applies a character cap or a token estimate based on characters per token. Truncation can remove useful context; it is not semantic summarization. |
profanity | Input and/or output flag or deny | Detects common profanity. The default flag records a match without blocking or changing the content. |
A flag is visibility, not prevention. Rules have allowed phases and verdicts; do not assume an input-only evaluator also screens output.
03when a rule fires
Handle the outcome, not just the happy path.
{
"error": {
"type": "invalid_request_error",
"code": "guardrail_violation",
"message": "Request blocked by your active guardrail policy.",
"request_id": "req_example"
}
}- Flag
- Records a match but leaves content unchanged. An application that needs to stop must not mistake a logged flag for a denial.
- Redact / truncate / repair
- Transform the evaluated buffer according to the rule. Check that the final content still satisfies your schema and task requirements.
- Input deny
- Returns
guardrail_violationbefore a model call. Explain the failure to the caller without automatically resubmitting around the policy. - Output deny
- Replaces the response content with a denial reason and drops artifacts. It is not the same as never having generated the output.
04an important display boundary
Streamed tokens can arrive before output checks.
The documented output-policy pass runs after the server has collected the token stream. A client displaying live tokens can therefore show raw, pre-guard text before the final guarded content arrives.
The final done.content is the guarded buffer. Rendering it replaces the displayed draft, but cannot undo a person having already seen an earlier token.
a deliberate rollout
Create. Test. Bind. Verify.
- 01
Define phases and outcomes
Start with the protections the task actually needs. Decide whether a match should be visible, transformed, or denied, and test those choices with synthetic inputs. - 02
Bind the intended key
A key binds to at most one policy; a policy can serve many keys. No organization or user default is silently inherited. Unbound keys and session-authenticated callers bypass Gateway Guardrails. - 03
Check both directions
Test an input denial and an output change. Check streaming separately. A policy that handles an email on input says nothing by itself about the final response. - 04
Verify the effective configuration
Inspect the binding and execution records after rollout. Clearing the binding means no enforcement, not a fallback to a different policy. Human approval and application access control remain your responsibility.
Make the policy visible in the path.
Create and test policies in the existing dashboard, then bind only the keys intended for enforcement. Verify the result before widening the rollout.