Guardrails

Workspace-level content guardrails — PII/secret redaction, blocked terms, moderation, injection detection.

Guardrails is one workspace-level content policy applied to every LLM call ByteChef makes. It redacts sensitive data out of prompts before they leave the instance, rejects blocked terms and prompt-injection attempts, and can scan the model's own reply on the way back.

The page lives at Settings → AI Agents → Guardrails in the Automation workspace and requires the admin role.

What each guardrail checks

Setting	What it does
Redact PII	Masks emails, phone numbers, SSNs, credit-card numbers, and IPv4 addresses in prompts before they leave ByteChef.
Redact secrets	Masks API keys, tokens, JWTs, and private-key blocks in prompts before they leave ByteChef.
Scan responses	Redacts PII and secrets out of the model's output before it is returned or logged. Non-streaming completions only, unless streaming response scanning is enabled by the operator.
Model-based moderation	Classifies a prompt as safe or unsafe using a moderation model. Inactive until the operator configures one.
Prompt-injection detection	Rejects jailbreak and instruction-override attempts, including instructions buried in quoted content. Requires a configured injection model.
Blocked terms	A comma- or newline-separated deny list; a prompt containing one of these terms is rejected.

Redaction always runs first, so the blocked-term, injection, and moderation checks all see already-redacted text. Each redaction substitutes a labelled placeholder rather than deleting the span — [REDACTED_EMAIL], [REDACTED_SSN], [REDACTED_CC], [REDACTED_PHONE], [REDACTED_IP], and [REDACTED_SECRET] — so the model still sees that a value was present.

Blocking mode

Blocking mode decides what happens when a blocking guardrail trips:

Block (the default) — the request fails with a category-only message. The offending content is never echoed back.
Redact and continue — the offending content is masked and the call proceeds.

Blocking mode governs only the three blocking guardrails — blocked terms, injection detection, and moderation. Redaction and response scanning always redact and continue regardless of the mode: there is no reason to fail a request over data the redaction step already masked.

The three blocking guardrails downgrade differently, because they identify different things:

Guardrail	Under Redact and continue
Blocked terms	Only the matched term is masked (`[REDACTED_BLOCKED_TERM]`).
Prompt injection	Nothing further is masked — the prompt proceeds with the PII/secret redaction it already had.
Moderation	The whole message is replaced with `[REDACTED_MODERATED]`, because a moderation verdict has no locatable span to mask.

Where the policy applies

Guardrails are not a per-feature toggle. One workspace policy covers every surface that calls a model:

Surface	What is covered
AI Gateway	Every chat-completion and embeddings request routed through the gateway.
Canvas AI Agent	Workflow runs using the AI Agent component, on top of any guardrail cluster elements configured on that node. A block fails the step like any other task failure, so `on-error` handling and error workflows apply.
AI Hub	Every AI Hub chat turn, including the specialist subagents a turn delegates to.

A run that cannot be attributed to a workspace — an embedded execution, for instance — falls back to the deployment-wide default policy. Guardrails are never skipped because attribution failed; only the scope is fail-open.

How the layers compose

Guardrails are additive. A narrower layer can switch a check on or add terms to a list; it can never switch one off.

Deployment-wide defaults, set by the operator as configuration.
Workspace settings, configured on this page — unioned with the deployment defaults.
AI Gateway per-project overlay, which can add further restrictions to gateway traffic only. The canvas AI Agent and the AI Hub have no project concept and see layers 1 and 2 only.

Because the workspace policy is a floor, it is evaluated ahead of any per-node guardrail cluster element on a workflow canvas — those elements can only add restrictions on top.

Operator configuration

The deployment-wide defaults, and the two classifier models the moderation and injection checks need, are configuration:

Property	Purpose
`bytechef.ai.gateway.guardrails.pii-redaction-enabled`	Deployment-wide PII redaction.
`bytechef.ai.gateway.guardrails.secret-redaction-enabled`	Deployment-wide secret redaction.
`bytechef.ai.gateway.guardrails.blocked-terms`	Deployment-wide deny list.
`bytechef.ai.gateway.guardrails.moderation-enabled`	Deployment-wide moderation.
`bytechef.ai.gateway.guardrails.moderation-model`	The model that classifies prompts for moderation. Without it, the moderation toggle has no effect.
`bytechef.ai.gateway.guardrails.injection-detection-enabled`	Deployment-wide injection detection.
`bytechef.ai.gateway.guardrails.injection-model`	The model that classifies prompts for injection. Without it, the injection toggle has no effect.
`bytechef.ai.gateway.guardrails.response-scan-enabled`	Deployment-wide response scanning.
`bytechef.ai.gateway.guardrails.response-scan-streaming-enabled`	Extends response scanning to streaming replies. Off by default.

These properties keep their ai.gateway prefix for compatibility, but they are not gateway-only — they are the deployment-wide floor for all three surfaces, and they apply whether or not the AI Gateway itself is enabled.

Metrics

Guardrail activity is counted in the bytechef_ai_guardrail meter, tagged by event and surface.

event — pii_redacted, secret_redacted, blocked_term, moderation_flagged, injection_flagged, response_redacted, and blocking_downgraded (recorded when Redact and continue converts what would have been a block).
surface — gateway, ai_agent, or ai_hub.

The surface tag is what makes the meter useful: it tells you which entry point a policy is actually catching things on, rather than only that the policy fired.