Safety Rules

Safety Rules (internally policies) are how RondoFlow keeps Assistants (agents) inside the lines. A rule can block dangerous commands, require your approval before a tool runs, and cap timeouts, file sizes, and spend.

The guiding principle is simple: the most restrictive setting always wins. You can layer rules without fear that a permissive layer will quietly loosen a stricter one.

The three layers

Safety Rules attach at one of three levels. The resolver loads all of them and merges them from least specific to most specific.

Load order is global → Assistant → Conversation. Because every merge step can only tighten a value, a more specific rule can never relax a broader one.

How resolution works (most restrictive wins)

When the resolver computes the effective rule for an Assistant, each field merges with its own strategy:

For permissionMode, restrictiveness is ranked (most to least): default > plan > acceptEdits > dontAsk. Any single layer asking for default forces default for the whole run.

Rule fields

Every Safety Rule stores a rules object. All fields are optional — only what you set participates in the merge; anything omitted falls back to the built-in default.

permissionMode vs an Assistant’s Mode

permissionMode on a Safety Rule is distinct from an Assistant’s own Mode (Plan / Default / Edit / Full). An Assistant’s Mode maps to a CLI permission string first, then any Safety Rule permissionMode is merged on top toward stricter:

bypassPermissions ranks below every policy mode, so any rule-set permissionMode overrides a Full Assistant toward stricter. Note that several headless run paths (chains, the Director/Planner/Advisor passes, loops, discussions, the Structurer, scheduled runs) hardcode bypassPermissions and skip the merge entirely — see What enforces what.

How patterns are matched

blockedCommands and requireApproval patterns are matched against the command an Assistant wants to run:

• For the Bash tool, RondoFlow matches against the actual command string.
• For every other tool (such as Write or WebFetch), it matches against the tool name.

Matching is case-sensitive. A pattern matches if the subject equals it, contains it, or starts with it. So a blocked pattern of git push matches git push origin main, and a pattern of rm matches both rm file.txt and npm — keep patterns specific to avoid false positives.

Evaluation order per tool call:

What enforces what

This is the most important thing to internalize about Safety Rules: command blocking and the human-approval gate are interactive-only.

The headless run paths spawn the CLI with permissionMode: 'bypassPermissions' and never call the policy checker, so a blockedCommands or requireApproval pattern has no effect on a Workflow run, a Loop, a Discussion, or a scheduled task. Their enforced guardrails are the budget cap and the spawn idle / wall-clock timeouts.

The budget cap

maxBudgetUsd is the one guardrail enforced across every run mode and every provider. It is passed straight to the CLI as --max-budget-usd, a real spend ceiling the CLI enforces itself — distinct from RondoFlow’s own analytics cost estimates.

The global per-run budget (the “Max Budget” control) does not live in the Safety Rules API. It is stored on a single canonical global Policy row and managed through its own endpoints:

Human approvals

When a tool call matches a requireApproval pattern on an interactive run, the run pauses (the Assistant goes to waiting_approval) and RondoFlow surfaces an approval dialog (“Action Required”). The Assistant cannot proceed until you respond.

The dialog shows:

• The Assistant name and the tool being requested.
• A plain-language description of what it wants to do.
• The exact command, with an automatic risk badge (high / medium / low) computed purely from the command string by regex, independent of which policy pattern matched.
• A countdown to auto-dismiss.

Risk tiers are assigned like this:

You have three choices:

Worked example: resolution in action

Suppose two layers apply to one Assistant run (global + Assistant — the layers that actually take effect on interactive runs):

// Global Safety Rule
{
  "maxBudgetUsd": 200,
  "blockedCommands": ["rm -rf /"],
  "permissionMode": "dontAsk"
}
// Assistant Safety Rule
{
  "maxBudgetUsd": 100,
  "blockedCommands": ["DROP TABLE"],
  "requireApproval": ["git push"],
  "permissionMode": "default"
}

The resolved rule the Assistant runs under is:

{
  "maxBudgetUsd": 100,
  "blockedCommands": ["rm -rf /", "DROP TABLE"],
  "requireApproval": ["git push"],
  "maxTimeout": 300000,
  "maxFileSize": 10485760,
  "permissionMode": "default"
}

Why:

• Budget → minimum of 200 / 100 = 100.
• Blocked commands → the union of every layer’s list.
• Require approval → the union of all patterns (no layer set true, so it stays a list).
• Timeout / file size → no layer set them, so the defaults stand.
• Permission mode → the Assistant rule asked for default, which is the most restrictive, so it wins even though the global layer said dontAsk.

A session-level layer would merge into this the same way (minimum / union), but as noted above it is not passed at run time today, so it would not actually affect a live run.

The Global Safety panel

The Global Safety Rules panel previews workspace-wide guardrails: a default safety level (Cautious / Balanced / Autonomous), a Blocked Commands list, a Require Approval list, and a default timeout.

The lists you see in the panel mirror the canonical global Policy row that RondoFlow seeds — a global-level Policy named “Default Safety Rules” with:

• blockedCommands: rm -rf /, DROP TABLE, FORMAT
• requireApproval: rm, git push, npm publish, docker rm
• maxTimeout: 300, permissionMode: default

That row is created or updated whenever the global budget is set via PUT /api/settings/budget; the budget value is stored alongside these rules on the same Policy.

The Safety Rules API

Safety Rules are managed under /api/policies. Responses use the standard envelope ({ success, data?, error? }).

A create request validates name (1–100 chars), level (global / agent / session), the rules object, and optional agentId / sessionId.

curl -X POST http://localhost:3001/api/policies \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Org guardrails",
    "level": "global",
    "rules": {
      "blockedCommands": ["rm -rf /", "DROP TABLE"],
      "requireApproval": ["git push", "npm publish"],
      "maxBudgetUsd": 50,
      "permissionMode": "default"
    }
  }'

curl "http://localhost:3001/api/policies?level=agent&agentId=AGENT_ID"

Tips

• Block, don’t just approve. blockedCommands is a hard stop; requireApproval still lets the command run after a click. Use blocking for anything truly catastrophic — on interactive runs.
• Use the budget cap for headless runs. Since command gating does not apply to Workflows, Loops, Discussions, and scheduled tasks, the maxBudgetUsd cap and the spawn timeouts are your real guardrails there. Set a sensible global budget.
• Start global, tighten per Assistant. Put your non-negotiables (a hard budget cap, a stricter permissionMode) at the global level, then add Assistant rules where you need more restriction. (The Conversation layer is reserved.)
• Be specific with patterns. Because matching includes substring and prefix checks and is case-sensitive, an overly short pattern (like rm) can match more than you intend.
• Mind the approval timeout. Approvals auto-reject after ~5 minutes, so long-unattended interactive runs that hit an approval gate will stall and then fail safe.

Related