Guardrails & DLP

Built-in guardrails

Deterministic rules over agent activity — large egress, destructive tool calls, budget caps, PII in output, blocked egress attempts, secrets in outbound payloads, and more. Each has a severity, an action (alert or alert + stop), routing to an admin, and an enable switch. Click any built-in to expand it: a plain-words explanation of how it works, a concrete example of data it would stop, and its tunable settings — the byte threshold for large egress, the keyword list for destructive actions, the data classes for sensitive egress. Every Security subtab is deep-linkable: /app/admin#security/guardrails opens straight here.

The guardrail constructor

New guardrail assembles a custom rule from the org’s real traffic:

• Watch outbound calls or tool calls.
• Specific hosts — picked from where your agents actually sent data.
• Payload larger than… — sized against your real traffic (percentile hints).
• Content detectors (DLP) — scan what actually leaves the sandbox: built-in detectors (email, phone, card numbers with Luhn, IBAN, API keys and private keys) plus your own regex or keyword lists.
• Narrow by call decision, data class of the connector, sessions whose result may leave the workspace, or specific people and groups.

Before enabling, backtest shows how many times the rule would have fired over the recent history, with example matches — so a noisy rule never reaches the alert queue blind.

Custom policies run in the same evaluation pipeline as the built-ins and land in the same Alerts queue.