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.
- Guardrail models — which Prompt Guard and Llama Guard model variants screen traffic, and which embedding model is used to assemble context (memories, tools, skills) for a prompt. Leave any of these blank to use the platform default.
Per-agent overrides¶
Each agent's Settings page has its own Guardrails section for overriding the tenant defaults:
- Guardrail models — pin a specific Prompt Guard, Llama Guard, or 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.comare 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.
Decision log¶
Every agent's Settings page 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.