docs(security): clarify host-side exec trust model defaults

SECURITY.md

@@ -88,6 +88,10 @@ OpenClaw does **not** model one gateway as a multi-tenant, adversarial user boun
 - Recommended mode: one user per machine/host (or VPS), one gateway for that user, and one or more agents inside that gateway.
 - If multiple users need OpenClaw, use one VPS (or host/OS user boundary) per user.
 - For advanced setups, multiple gateways on one machine are possible, but only with strict isolation and are not the recommended default.
+- Exec behavior is host-first by default: `agents.defaults.sandbox.mode` defaults to `off`.
+- `tools.exec.host` defaults to `sandbox` as a routing preference, but if sandbox runtime is not active for the session, exec runs on the gateway host.
+- Implicit exec calls (no explicit host in the tool call) follow the same behavior.
+- This is expected in OpenClaw's one-user trusted-operator model. If you need isolation, enable sandbox mode (`non-main`/`all`) and keep strict tool policy.
 
 ## Out of Scope
 
@@ -100,6 +104,7 @@ OpenClaw does **not** model one gateway as a multi-tenant, adversarial user boun
 - Any report whose only claim is that an operator-enabled `dangerous*`/`dangerously*` config option weakens defaults (these are explicit break-glass tradeoffs by design)
 - Reports that depend on trusted operator-supplied configuration values to trigger availability impact (for example custom regex patterns). These may still be fixed as defense-in-depth hardening, but are not security-boundary bypasses.
 - Exposed secrets that are third-party/user-controlled credentials (not OpenClaw-owned and not granting access to OpenClaw-operated infrastructure/services) without demonstrated OpenClaw impact
+- Reports whose only claim is host-side exec when sandbox runtime is disabled/unavailable (documented default behavior in the trusted-operator model), without a boundary bypass.
 
 ## Deployment Assumptions