Content Safety, PII & Guardrails

TL;DR: The four-stage governance chain and the gateway safety scanners are enabled on this deployment. Requests pass jailbreak heuristics, 34 secret patterns with an entropy backstop, and PII detection (email, credit card, SSN, phone). Buffered responses can be blocked outright; streamed responses are scanned audit-only; transcripts redact detected values at display time. The category set and each category's block-vs-audit disposition are configurable per deployment.

The governance chain is on

Every call runs the four-stage synchronous chain — scope check → secret scan → blocklist → rate limit — first-deny-wins, with every decision audited with trace linkage. The chain itself is covered in depth in MCP, Tool Governance & Distribution; this page covers the content-safety scanners layered on the gateway.

What the scanners check

The shipped default category set:

Category	What it catches
Jailbreak heuristics	Prompt patterns attempting to subvert model instructions
Secrets	34 known credential patterns (API keys, tokens, private keys) plus a high-entropy-string backstop for secrets no pattern names
PII	Email addresses, credit card numbers, US Social Security numbers, phone numbers

This set is the sensible default, not a fixed contract — categories and their block-vs-audit disposition are configurable, so a deployment enforces exactly the policy its owners require. A PHI taxonomy (health identifiers) is not yet part of the set — see the roadmap.

Blocking vs. auditing: why streaming differs

Enforcement depends on how the response is delivered:

• Buffered responses are held until scanning completes, so a detection can block the response before the caller sees a byte.
• Streamed responses are scanned audit-only: tokens are already on the wire as they are generated, so retroactively blocking them is impossible without breaking streaming entirely. Detections are recorded and alertable, but the stream completes.

This is a deliberate design, not a gap: the alternative — buffering every stream — would destroy the latency profile streaming exists to provide. Where blocking matters more than latency, use non-streaming calls.

Note also that in-flight enforcement blocks rather than redacts — a flagged buffered response is refused whole, not rewritten with masked values. In-flight redaction (masking values instead of refusing the response) is planned — see the roadmap.

Display-layer redaction

Transcripts shown in the admin UI apply display-layer redaction: values the scanners flagged (secrets, PII) are masked when a conversation is rendered, so reviewing an audit trail does not itself re-expose the sensitive data that triggered the detection.

Where detections go

Every scanner decision is an audit row on the same spine as everything else — reachable from /admin/entities/traces and systemprompt infra logs trace list, alertable to Slack, and attributable to the actor via the trace chain described in Audit Trail, Traceability & Observability.

Verified evidence

Every capability on this page is proven by tagged end-to-end tests run against a seeded instance. To replicate: just start, then just e2e-seed --reset, then the command in the table. Screenshots regenerate with just e2e-screens.

Ref	Verified behaviour	Replicate with
REQ-030	The enabled safety chain flags jailbreak patterns and PII, blocks a flagged buffered response, and audits a streamed one	just e2e-req REQ-030
REQ-036	Secret patterns and the entropy backstop catch credential egress, and transcripts render detected values redacted	just e2e-req REQ-036

Deeper gateway-level checks for these behaviours also run in the platform's integration suite (just test-integration).

Screenshots