Guardrails

Guardrails are the controls that keep an agent's autonomy bounded: what it's allowed to touch, what it's allowed to say back, and when it has to stop and ask a human first. They sit around every run regardless of which tools an agent uses.

Allow/deny lists

You can restrict which tools an agent is permitted to use, and which outbound domains its api_call tools are permitted to reach. An allow list limits an agent to a specific set of approved tools/domains; a deny list blocks specific ones while leaving everything else open. This matters because an agentic loop chooses its own next step at run time — a list is how you bound the space of choices it's allowed to make, rather than relying on the model to infer boundaries you never wrote down.

Both policies are off by default — an agent with no guardrail configuration behaves exactly as it always has. When a tool policy is set, a denied (or not-allowed) tool is never offered to the model in the first place; the model can't ask to use a tool it can't see. When a domain policy is set, it's checked against the resolved destination URL of every api_call right before it fires — matching is hostname-based and subdomain-aware, so listing example.com also covers api.example.com. A blocked call fails that single tool step with a clear error; it does not fail the whole run.

PII and secret output redaction

Before a response reaches the user, it's checked for patterns that shouldn't be exposed and redacted if found. This covers:

• Credit card numbers, validated with a Luhn check so redaction targets real card-shaped numbers rather than any 16-digit string.
• Prefixed API tokens — the kind of secret that carries a recognizable prefix (a key or token format), redacted before it can leak out through a response.
• Social Security numbers.
• Email addresses.

This matters because an agent's output is generated text — it can reproduce something sensitive it encountered while running (a tool result, a document from knowledge_search) without meaning to. Redaction is a backstop that catches this at the boundary, rather than trusting every upstream tool to never surface something it shouldn't.

Prompt-injection defenses

Content an agent receives — a user message, a webhook payload, a document, an API response — isn't necessarily trustworthy, and it can contain text crafted to look like an instruction ("ignore your previous instructions and…"). An opt-in input scan checks the run's raw input against a set of common injection phrasings (e.g. "ignore previous instructions," "disregard the system prompt," "reveal your instructions," "developer mode") before the agentic loop starts, including a defense against splicing zero-width characters into a keyword to dodge the check.

This scan is off by default — it only runs when an agent's guardrails explicitly enable it. When enabled, you choose what happens on a match: block fails the run before it starts (the same clear failure path as any other blocked run), or warn lets the run proceed exactly as if the scan weren't there. It's a heuristic, regex-based first line of defense over the run's initial input — not a claim that every injection attempt, or one buried in a document/tool result pulled in mid-run, is caught.

Human-in-the-loop approval gates

Any step that performs a destructive or consequential action can be placed behind an approval gate. When the run reaches a gated step, it halts before executing and asks a human to approve or reject the action — nothing happens until someone decides. This is the same gate described in tools and capabilities: it's what keeps an autonomous, multi-turn loop from taking an irreversible action on its own.

This matters most for anything you can't undo — sending a message, moving money, deleting a record. The rest of a run can move quickly and autonomously; approval gates are where you deliberately slow it down.

Why these work together

No single guardrail covers every failure mode. Allow/deny lists bound what an agent can attempt in the first place. Redaction catches sensitive content that shouldn't leave the run. Prompt-injection defenses stop untrusted input from hijacking the agent's behavior. Approval gates stop irreversible actions from happening without a person in the loop. Together, they let an agent operate with real autonomy — picking its own tools and steps through the agentic loop — while keeping the actual risk of that autonomy bounded and visible.