Security presets

Use security.preset to select a coherent set of defaults instead of configuring each security control independently:

{ security: { preset: "personal" } } // default; use "corporate" for isolation-first defaults

Personal is the default trusted-operator/YOLO posture. It keeps unsandboxed execution and collaborative steering together. Normal messages are handled automatically; if they cannot steer, they queue quietly without asking the sender to resend them.

Corporate is an isolation-first starting point, not a compliance guarantee or tenant boundary. Configure an available sandbox backend before selecting it. A missing sandbox does not authorize falling back to host execution.

What the presets select

These are defaults for otherwise-unset fields. Explicit global settings, agent overrides, session settings, and mandatory host/role policies still apply.

Sandbox networking covers sandboxed commands, not every Gateway-hosted tool, browser, MCP server, plugin, or model request. Other backends retain their own networking controls. Sandbox commands do not gain a new per-command human approval step; ordinary host escalation uses the existing approval engine. See sandbox coverage and exec modes.

Presets do not change Gateway authentication, pairing, channel allowlists, operator roles, session members, public shares, credentials, model access, or host approval files. A personal preset is not an admin full session permission grant and cannot bypass a stricter host approval policy or required sandbox.

Precedence and explicit overrides

1. Existing mandatory host, role, access, and approval checks remain authoritative.
2. Normal explicit session/per-turn settings and per-agent overrides keep their existing precedence and clamping rules.
3. Explicit global settings override the preset's defaults.
4. The preset supplies only missing values; the default preset is personal.

An explicit legacy tools.exec.security/ask policy is kept as a whole; the preset does not add a competing mode. Arrays such as tool allow/deny lists are not rewritten.

For example, keep the personal execution posture but separate participants' turns:

{  security: { preset: "personal" },  messages: {    queue: { allowCollaborativeSteering: false, collaborativeSteeringFallback: "queue" },  },}

That override still works automatically and quietly. collaborativeSteeringFallback: "reject" is the explicit opt-in for refusing a blocked steer and requiring a fresh request. Automatic queue fallback does not emit queue-status messages. Genuine rejection, cancellation uncertainty, and queue overflow still have visible outcomes.

You can customize corporate defaults too. Consequently, the name corporate alone is not evidence that an execution is sandboxed: inspect its resolved settings and configure mandatory operator-role/host restrictions where enforcement is required. See session permission precedence.

Steering authority is execution-bound

With collaboration enabled, Bob's admitted message can influence Alice's running turn, including when Bob has fewer permissions. The turn keeps Alice's authority. Bob remains the message author; neither identical request text nor a model explanation securely attributes a later tool call to Bob. A higher-privilege steer likewise does not upgrade a lower-privilege incumbent. Tools that explicitly select an enrolled participant retain their existing requester-selection and authorization contract; that selection is not causal attribution to a message.

With collaboration disabled and quiet queue fallback selected, each sender gets a separate execution with their requester identity and current applicable policy. Distinct senders are not collected merely because both ask "Summarize report.txt". Message-ID deduplication is not semantic deduplication. Compatible messages from one requester may still collect when that mode is selected.

Explicit policy profiles constrain executions, not individual sentences in a blended conversation. Shared history can still influence later turns, and changing a preset cannot retract information the model already saw. Corporate strict steering does not isolate shared conversation history or outputs. Use separate trust boundaries for mutually untrusted users.

Existing installations and changes

• Existing explicit settings, including allowCollaborativeSteering: false, remain unchanged. That existing false value now queues quietly unless strict refusal is explicitly selected.
• Otherwise-unset settings resolve from the personal preset. This makes collaborative steering and unrestricted apply_patch consistent with the trusted full-access posture; choose corporate or explicit restrictions when that is not intended.
• Config reads do not rewrite your file. Preset expansion stays runtime-only, including after ordinary configuration writes. Switching the preset does not pin the previous preset's derived values into your file.
• Doctor keeps explicit true/false steering choices and no longer persists competing queue defaults. An older explicit value, even one persisted by an earlier Doctor, must be unset if the preset should control it.
• Changing presets uses the existing configuration publication/reload lifecycle for subsequent policy preparation. Already-started effects are not undone, retained work keeps its governing authority, and history is not rewritten.
• Corporate DM isolation changes the routing key for subsequent messages. Old sessions and history remain stored; they are not copied into the new peer-specific conversations or deleted.

Comparison with other agent products

Primary documentation and Codex source inspected on October 27, 2026. This is a design comparison, not a runtime security certification. "YOLO" does not mean the same thing across products, and approval suppression is not isolation.

These references do not establish secure causal attribution of actions after several principals' messages enter one model turn. OpenClaw's execution/requester boundaries must remain explicit rather than relying on a model to infer whose permissions apply.