Guardrails¶

Guardrails are the safety layer every agent's inbound and outbound traffic passes through — the thing that keeps agents inside the boundaries your organization sets, whether they're running a skill you wrote or one you installed from the marketplace.

Configuration happens in two places: tenant-wide defaults that every agent inherits, and optional per-agent overrides for when one agent needs stricter (or looser) rules than the rest.

Tenant-wide defaults¶

Owners and admins manage organization-wide guardrail defaults from Organization → Guardrails. Settings here are the defaults every agent uses unless it has its own override:

Built-in detectors — PII scrubbing (emails, phone numbers, SSNs, credit card numbers are redacted, not blocked), secret/key detection (cloud credentials, tokens, and other credential patterns are blocked outright — scrubbing a live key would still mean it left your account), and a maximum request size.
Model guard — the model-based check for prompt injection and unsafe content. Choose the guard (Julia 1, the default, or Prompt Guard + Llama Guard), its mode (Shadow — checks and logs, never blocks — or Enforce — blocks), whether it is on, and its sensitivity. New workspaces start in Shadow. Turning the guard off or switching to Enforce asks you to confirm.
Override policy (owners only) — who may override a block from the model guard (Owner, Admin or Member), the lowest role that may use break glass, and how long an override may pause the guard for one conversation.
Embedding model — which embedding model is used to assemble context (memories, tools, skills) for a prompt. Leave blank to use the platform default.

Per-agent overrides¶

Each agent's Settings page has its own Guardrails section for overriding the tenant defaults:

Model guard — the same guard, mode, on/off and sensitivity choices as the tenant defaults, for this agent alone (owners and admins only).
Embedding model — pin a specific embedding model for this agent alone.
Built-in detectors — PII scrubbing and secret detection are each a three-way choice: inherit the tenant default, force on, or force off. A per-agent override only takes effect once you explicitly choose "On" or "Off"; leaving it on "Inherit tenant default" means changes to the tenant-wide setting keep applying to this agent automatically. The maximum request size can also be overridden per agent; leave it blank to inherit the tenant-wide value.
Egress allowlist — additional hostnames this agent is allowed to reach when it makes an outbound call, e.g. api.example.com. Single-label wildcards like *.example.com are supported. Entries here are added on top of the platform's baseline of always-allowed hosts: the list grants this agent extra destinations — it can't remove a host the platform already allows.

Saving either the tenant-wide defaults or a per-agent override takes effect on the agent's next invocation — not retroactively on a request already in flight.

Overriding a block¶

When the model guard blocks one of your messages, or an action an agent takes in a conversation you are part of, you may be able to override it:

Override — available if your role is at or above your organization's override role. You confirm and give a short reason.
Break glass — for roles below that, if your organization allows it. You re-enter your credentials, give a detailed reason, and every owner is notified; owners and admins review break-glass use afterwards under Organization → Guardrails → Overrides.

An override can cover just the blocked item, or briefly pause the model guard for that one conversation. It never bypasses the built-in detectors (secrets, PII, egress allowlist, size limits) or your own custom detectors, and an agent can never override a block by itself.

Decision log¶

Every agent's Audit tab includes a read-only Decision log — a record of guardrail decisions (allow, flag, block, redact) made on that agent's inbound and outbound traffic. Use it to see why a message was scrubbed or a call was blocked. Entries are retained for 30 days by default; your platform operator can configure a different retention window.

Code findings¶

Alongside runtime guardrails, Organization → Guardrails → Code Findings shows static-analysis results for every agent in your organization — issues caught by security and lint scanning before an agent's code ever runs, not traffic seen live. Each finding lists its severity, the scanner that raised it, the affected file, and where it came from (the platform's own security scans, your organization's CI, or a scheduled re-scan). Filter by severity, scanner, or source, or toggle between active and suppressed findings.

Owners and admins can suppress a finding that's a false positive or an accepted risk, and unsuppress it later — suppressing never deletes the finding, it just marks it suppressed, and the action is recorded for audit. An individual agent's own findings also appear on a Code findings tab on that agent's page, filtered to just that agent.