Skip to main content
You do not have to author a single firewall rule to get protected. The autonomy control — also called the Secure Agents baseline — applies a complete zero-trust posture to your workspace in one transaction: Firewall and Guardrails, together, with one-click undo. This is the fastest path to a meaningful security posture. Author rules later to tune; start here.
The Secure Agents baseline is the autonomy control — there is no separate “baseline” object. Applying an autonomy level atomically writes a firewall policy and a guardrail (named for the level) and makes them your workspace’s live posture, in one transaction. You can open and edit those afterward. One-click undo restores the prior state from an audit snapshot.

​
1. What the autonomy control does

Three levels, each covering the same two layers:
LevelFirewall postureGuardrailsObserve mode
tightDefault-deny; destructive shell and fetch-shaped tools (SSRF vector) deniedPII Shield + Secrets Blocker enforcedOff
balancedAudit by default; destructive shell deniedPII Shield in audit-only mode (flags PII)Off
permissiveNo enforcing policyNo guardrailsOn — every tool call is logged as a coverage gap
balanced is the recommended starting posture. It audits everything your agents do and flags PII, while still denying the most destructive actions (destructive shell) — so you see your agents’ real behavior before deciding what else to restrict. For a pass that blocks nothing, start at permissive. tight is the right target once you understand your agent’s normal behavior. It enforces a default-deny posture out of the box: destructive shell denied, fetch-shaped tools (the SSRF vector) denied, and both PII Shield and Secrets Blocker guardrails active (screening your requests for PII and secrets). permissive turns off all enforcement but leaves observe mode on, so every tool call is still logged. Use it to audit a brand-new agent with no risk of accidental blocks — then move to balanced or tight once you know what it does.

​
2. How to apply a level

1

Preview the change (optional but recommended)

Simulate the level before applying it. The console Simulate view (under Firewall → Posture) or the API shows exactly what rules and guardrails would be active — nothing changes.
# Simulate tight — returns the full policy diff, nothing is applied
GET /api/workspace/firewall/simulate?level=tight
Role: Member (read-only, no change).
2

Pick a level in the console

Go to Firewall → Posture in the console. Select balanced, tight, or permissive from the autonomy level control and confirm. The change takes effect on the next tool call — no redeploy.Role: Developer+ required to apply.
3

Or apply via the API

POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
The response includes an audit_id — hold on to it. You need it for undo.Role: Developer+.
4

Watch events and matches

After applying, go to Firewall → Events / Runs to see tool-call verdicts and Guardrails → Matches to see content-policy hits. Both feeds update in real time. If something fires that you didn’t expect, review it before tightening further.
5

Undo if needed

Any autonomy change can be undone with one call. The undo restores the exact prior state — policies, rules, guardrails, settings — from the audit snapshot, not a generic reset.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Role: Developer+.The audit_id is returned when you apply the level (Step 3) and is also visible in Firewall → Audit.
Start balanced → simulate tight → watch → tighten.
  1. Apply balanced — you get a full audit trail; only destructive shell is denied, everything else is audited. Run your agents normally for a day or two.
  2. Simulate tight — run GET /api/workspace/firewall/simulate?level=tight and compare what would be denied against what you saw in the Events feed. If destructive-shell calls or SSRF-style outbound requests are part of your normal traffic, fix those in the agent first.
  3. Watch Events and Matches — Firewall → Events shows every tool-call verdict; Guardrails → Matches shows content-policy hits. Both are filterable by verdict, tool, run, and session.
  4. Apply tight — once the simulate output contains no surprises, apply tight. Undo is one call away if something breaks in production.
  5. Tune with rules — use Firewall rules to carve out exceptions or add controls the preset levels don’t cover. The autonomy level is your floor; custom rules add precision.

​
4. Role requirements

ActionMinimum role
Simulate a level (GET .../simulate)Member
Read the audit trailMember
View guardrail MatchesMember
View firewall Events & RunsDeveloper+
Apply an autonomy levelDeveloper+
Undo an autonomy changeDeveloper+

​
5. What this is not

  • Not a black box. Applying an autonomy level writes a real firewall policy and guardrail (named for the level) and makes them your workspace’s live posture. You can open, inspect, and edit them afterward — it’s a fast starting point, not a locked preset.
  • Reversible, within limits. One-click undo restores the prior Firewall and Guardrails state from an audit snapshot. For a very large workspace whose snapshot exceeds the audit-log size limit, the apply still succeeds but undo isn’t available for that change — you re-apply the level you want instead. Rare, but worth knowing.
  • Not a substitute for scoped keys. The autonomy control sets the workspace’s default posture. Individual API keys can still be attached to specific policies for finer control. See Guardrails vs. Firewall for how the layers compose.
The autonomy control is designed for the first 30 minutes — get protected fast, understand your agents’ real behavior, then tighten from a position of visibility rather than guesswork.

Quickstart

Full zero-trust setup in 5 minutes, including scoped keys and guardrails.

Firewall

Rule-level detail — verdicts, surfaces, argument predicates, and HITL approval.