Guardrails

#Overview

A guardrail is a safeguard that checks and validates the content flowing in and out of an agent. It inspects what a person sends to an agent before the agent acts on it, and what the agent produces before it reaches a person — so agents are used safely and stay within company policy.

An agent's prompt tells it how to behave, and a well-written prompt goes a long way. What a prompt cannot do is guarantee the outcome: it is guidance the agent follows, not a check applied to every message. A guardrail is that check. It sits on the boundary of the agent and looks at the actual content passing through it, every time, regardless of what the agent was asked or how it chose to answer.

Two things define a guardrail:

• How it detects content — by exact keyword, by regex pattern, or by semantic analysis that reads meaning and context.
• What happens when it is triggered — the flagged content is redacted, masked, or hashed, or the whole input or output is blocked.

Once created, a guardrail is attached where it is needed as an input guardrail, an output guardrail, or both. Because the same guardrail can be reused in many places, a safety or compliance rule can be written once and applied consistently — rather than being restated in every agent's prompt and hoped for.

#Key Capabilities

• Check content on the way in. Validate user input before an agent processes it, so an unsafe or manipulative request never reaches the agent.
• Check content on the way out. Validate an agent's output before it is returned, so sensitive or non-compliant material is not exposed.
• Detect content three ways. Match exact keywords, match regex patterns, or use semantic analysis that understands meaning and context rather than exact wording.
• Catch sensitive and policy-violating material. Flag content such as personally identifiable information (PII), unsafe language, or breaches of company policy.
• Decide how flagged content is handled. Redact it, mask it, hash it, or block the entire input or output and show an error message you write.
• Reuse one guardrail in many places. A single guardrail can be applied across agents and agent templates, on input, output, or both.
• Adjust handling per attachment. The guardrail carries a recommended handling approach, and that approach can be changed for each specific place it is used.
• Stack as many as the work needs. There is no limit on the number of guardrails attached to a single agent or agent template.

#How it Works

Guardrails are created in the Guardrails section of the platform. Creating one is two decisions: how it detects content, and what happens when it is triggered.

1. Choose a detection method. Detection can be done in one of three ways:

• Keyword Matching — matches exact words or phrases. For example, detecting curse words.
• Regex Pattern — uses regular expressions to find more complex patterns. For example, detecting email addresses.
• Semantic Analysis — uses a lightweight language model to detect meaning and context rather than exact matches. For example, detecting PII, or content that violates a company policy.

Keyword and regex matching are precise and predictable: they find exactly what you describe, and nothing else. Semantic analysis is the one to reach for when the thing you are guarding against cannot be written down as a list or a pattern — a policy breach, or an attempt to talk an agent out of its instructions.

2. Choose how flagged content is handled. Each guardrail defines a recommended approach for the content it flags:

• Redact — replaces the flagged content with a placeholder, for example [REDACTED].
• Mask — masks the characters of the flagged content, with the option to reveal the first or last few characters, for example a credit card shown as ****1234.
• Hash — replaces the flagged content with a cryptographic hash to ensure uniqueness.
• Block — blocks the entire input or output and displays an error message you specify instead.

The first three let the exchange continue with the sensitive part removed or obscured. Blocking stops it altogether, which is why the error message matters: it is what the person sees in place of the response, so write it as an explanation rather than a rejection.

3. Attach it as an input guardrail, an output guardrail, or both. A guardrail has no effect until it is attached. Attach it to:

• An agent — so every message that agent receives, or every response it returns, is checked. See Agents.
• An agent template — so the same safeguards apply consistently wherever the template is used, and agents created from it start out protected. See Agent Templates.

Guardrails can also be attached to a space, a task, or a flow (on each step). See Spaces, Tasks, and Flows.

4. Adjust the handling approach for this particular use. The guardrail's recommended approach is applied as the initial handling method wherever it is attached, and you can change it for that specific instance. The same PII guardrail can mask in one place and block in another, without maintaining two versions of it.

#Additional Notes

• Input and output guard against different risks. Input guardrails deal with what people send an agent — unsafe requests, or attempts to manipulate it into ignoring its instructions. Output guardrails deal with what the agent produces — PII, secrets such as keys and tokens, or confidential internal content. Most agents that matter need both.
• Match the detection method to the risk. If you can list the words or write the pattern, keyword matching or a regex pattern is the precise choice. If the risk is about meaning — a policy breach, a prompt-injection attempt, an unexpected shape of PII — semantic analysis is what catches it.
• Blocking is the strongest response, and the bluntest. It stops the entire input or output, not just the flagged fragment. Where the rest of the content is still useful, redacting, masking, or hashing keeps the work moving while removing what should not be there.
• Guardrails complement permissions; they do not replace them. Access controls decide who is allowed to use an agent. Guardrails decide what content is allowed through once someone is using it. Governed agents need both. See Governance.
• A guardrail is a resource, so it is governed like one. Changes to a guardrail are recorded, and the organization-wide record of those changes is the audit log — useful when you need to show when a control was introduced or altered. See Audit Log.
• Attach guardrails to templates for consistency at scale. Building them into an agent template means every agent created from it starts with the same protections, instead of relying on each builder to remember. See Agent Templates.
• Guardrails matter more once an agent can act. An agent that only answers questions carries less risk than one calling tools and connectors against live systems. See Tools and Connectors.
• Short definitions of the terms used here are in one place: Glossary.

#Related Features

• Agents — The digital workers guardrails are attached to; input and output guardrails check the content flowing into and out of an agent. Agents
• Agent Templates — Reusable agent setups that can carry guardrails, so the same safeguards apply wherever the template is used. Agent Templates
• Spaces — The operational environment guardrails can also be attached to, so they apply to the work done there. Spaces
• Tasks — Work an agent runs on its own; guardrails can also be attached to a task. Tasks
• Flows — Multi-step processes; guardrails can also be attached to a flow, on each step. Flows
• Governance — The platform-wide model of permissions, versioning, approvals, and auditability that guardrails complement with content-level safety and policy control. Governance
• Audit Log — The organization-wide record of what changed and who changed it, including changes to guardrails. Audit Log
• Access & Permissions — The full access model behind plans, role permissions, and per-resource permissions. Access & Permissions