- The authoring console (Policies) — where admins create, toggle, and dry-run-test tenant policies.
- The runtime — a fixed set of built-in guardrails wired into the live turn pipeline, plus any guardrails a plugin declares.
What runs in the live pipeline today
The runtime evaluates guardrails at the same three stages the console describes — input, tool, and output — but from a fixed built-in set, not from your authored policies:PII redaction is off by default
The output-side PII redaction backstop is installed only when the deployment setsRUNTIME_PII_REDACTION_ENABLED (default off). Most deployments run
without it. When enabled, matches not in the source-aware allowlist are rewritten
to markers like [REDACTED_EMAIL].
All three built-ins are regex-based. Detection is deliberately conservative:
false negatives (a missed match) are possible, so these are a backstop, not a
guarantee.
Plugin-declared guardrails
Beyond the host built-ins, a plugin can declare its own guardrails scoped to a specific capability. Those fire only on the capability that declared them — not as universal rules across every tool. This is how a connector ships its own tool-level safety check without affecting unrelated capabilities.How this maps to the console
A UI feature flag (
enableGuardrails) exists but defaults off and gates
nothing structural; the tab’s visibility is governed by the guardrail.read
capability. There is no platform-wide GUARDRAILS_ENABLED switch. The only
runtime toggle that changes enforcement is RUNTIME_PII_REDACTION_ENABLED.