Research Note
OpenClaw Security Research Note
OpenClaw 2026.7.1 uses a personal-assistant trust model. One gateway assumes one trusted operator boundary. It is not a hostile multi-tenant boundary for mutually untrust
OpenClaw Security Research Note
OpenClaw 2026.7.1 uses a personal-assistant trust model. One gateway assumes one trusted operator boundary. It is not a hostile multi-tenant boundary for mutually untrusted users, even when conversations use separate session keys.
This note preserves the security facts that control the E111B package and future OpenClaw content. It is not a public installation guide.
Trust boundary
The gateway is the control plane for authentication, routing, sessions, tools, plugins, nodes, and operational interfaces. A caller authenticated as an operator is trusted at gateway scope. A session key selects context and does not authorize a user.
Different trust boundaries require separate gateways and preferably separate OS users or hosts. Per-sender sessions prevent conversational crossover but do not isolate host tools, configuration, credentials, or the gateway control plane.
The current authority is the OpenClaw security guide.
Exposure model
| Surface | Risk | Minimum control |
|---|---|---|
| Direct messages | Unknown sender triggers the agent | Pairing or explicit allowlist |
| Group rooms | Unapproved member or room triggers work | Group and room allowlists with mention gating |
| Gateway network | Remote control-plane access | Loopback first, strong auth, rate limits, exposure runbook |
| Tool execution | Prompt injection becomes action | Minimal tools, sandbox, approvals, filesystem limits |
| Browser control | Remote access to authenticated sessions | Disabled unless required, authenticated and isolated |
| Plugins | Third-party code and capabilities | Explicit allowlist, pinned source, review, removal path |
| Nodes | Operator-level remote-device capability | Deliberate pairing, command policy, node approvals |
| Secrets | Credential extraction | SecretRefs, restrictive permissions, no agent-readable source |
| Sessions and logs | Private context disclosure | Per-sender scope, retention, restricted storage |
| Updates | Reviewed behavior changes after upgrade | Version pin, test, approval, rollback |
Identity before model
OpenClaw's stated order is identity, scope, then model.
Identity determines who may send a request. Scope determines which rooms, tools, files, services, and nodes the request can reach. Model choice affects how reliably the system interprets instructions and resists manipulation.
A stronger model does not fix an open channel or unrestricted shell. An allowlist does not make untrusted documents safe. The controls compose.
Prompt injection
Prompt injection can arrive from an approved operator through a page, attachment, email, document, quoted message, tool result, or copied log. Sender allowlists do not sanitize content.
System prompts are guidance. Harder boundaries come from tool policy, sandboxing, execution approvals, filesystem restrictions, separate agents, and separate hosts.
OpenClaw warns that smaller, older, and heavily quantized models can be more susceptible to instruction hijacking in tool-enabled workflows. Small local models should be limited to trusted text or narrow read-only tasks unless stronger containment exists.
Secrets and state
OpenClaw supports SecretRefs for many credential fields. References may resolve from environment, file, or approved command providers.
Plaintext remains a risk when stored in openclaw.json, auth profiles, .env, generated model configuration, prompts, or logs. A SecretRef reduces exposure only when the agent cannot read the source.
The state directory can contain configuration, pairing approvals, sessions, logs, identifiers, and credentials. It should not be group-readable, world-readable, or stored in an unreviewed cloud-sync directory.
The current authority is the secrets guide.
Audit sequence
Run the security audit after installation, after every meaningful configuration change, and before network exposure.
openclaw security audit
openclaw security audit --deep
openclaw security audit --json
Use --fix only after reviewing the named remediations. It does not certify the gateway.
Run the secret audit before and after moving credentials to supported references.
openclaw secrets audit --check
openclaw secrets configure --apply
openclaw secrets audit --check
Retain the version, config hash, timestamp, findings, remediations, and effective tool inventory with the audit record.
Discord-specific boundary
Discord bot tokens are passwords. Discord recommends minimum permissions. The current OpenClaw text baseline does not require Administrator.
Message Content Intent is required for the documented integration. Server Members Intent is needed for certain member and role operations. Presence is optional.
Discord direct messages default to OpenClaw pairing in the current release. Pairing approval does not authorize every guild, channel, command, or tool. Guild and channel allowlists remain separate.
The current authorities are the OpenClaw Discord guide and Discord's permissions guide.
Incident path
An exposed Discord token must be regenerated. An exposed model-provider key must be rotated through that provider. A gateway credential mismatch should be reconciled across the active gateway and client, not bypassed.
When an agent performs an unexpected action, stop the gateway or supervisor, isolate the host when necessary, preserve relevant logs and state, revoke affected credentials, inspect tool and channel policy, and rebuild from a known version when integrity is uncertain.
The operator should test the stop, revoke, unpair, plugin-disable, and restore paths before enabling high-impact tools.
E111B corrections
The recording's Administrator permission, permissive installer mode, plaintext token handling, and timeout-disable suggestion remain narrative evidence only. They are excluded from public guidance.
The local model's direct response did not prove the complete Discord path. The online bot did not prove routing or delivery. The dashboard's unauthorized response did not justify disabling authentication.
The editorial CLI test used a clean temporary state directory and stopped at the supported Node version check. It made no external or persistent configuration changes.
Refresh triggers
Refresh this note when OpenClaw changes its trust model, gateway authentication, session defaults, pairing storage, tool profiles, sandboxing, secrets, audit checks, Discord configuration, node policy, or supported runtime versions.
Refresh before any public OpenClaw tutorial is published, even if the scheduled review date has not arrived.
Sources
Follow the evidence.
- application quick startdocs.discord.com
- pairing guidedocs.openclaw.ai
- Gemma 4 model overviewai.google.dev
- OpenClaw release 2026.7.1github.com
- `2d2ddc4`github.com
- OpenClaw getting-started guidedocs.openclaw.ai
- OpenClaw security guidedocs.openclaw.ai
- Gemma documentationai.google.dev
- secrets guidedocs.openclaw.ai
- Developer Policysupport-dev.discord.com
- local-model guidedocs.openclaw.ai
- Ollama provider guidedocs.openclaw.ai
- OAuth2 and permissions guidedocs.discord.com
- official Discord guidedocs.openclaw.ai
- OAuth2 referencedocs.discord.com
- Gateway documentationdocs.discord.com
- Gemini API pricing pageai.google.dev
- Gemma 4 library recordollama.com
- session guidedocs.openclaw.ai
- Gemma 4 model cardai.google.dev