Back to the episode map

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

Aug 4, 20265 min readBy Dalton Anderson

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

SurfaceRiskMinimum control
Direct messagesUnknown sender triggers the agentPairing or explicit allowlist
Group roomsUnapproved member or room triggers workGroup and room allowlists with mention gating
Gateway networkRemote control-plane accessLoopback first, strong auth, rate limits, exposure runbook
Tool executionPrompt injection becomes actionMinimal tools, sandbox, approvals, filesystem limits
Browser controlRemote access to authenticated sessionsDisabled unless required, authenticated and isolated
PluginsThird-party code and capabilitiesExplicit allowlist, pinned source, review, removal path
NodesOperator-level remote-device capabilityDeliberate pairing, command policy, node approvals
SecretsCredential extractionSecretRefs, restrictive permissions, no agent-readable source
Sessions and logsPrivate context disclosurePer-sender scope, retention, restricted storage
UpdatesReviewed behavior changes after upgradeVersion 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.

  1. application quick startdocs.discord.com
  2. pairing guidedocs.openclaw.ai
  3. Gemma 4 model overviewai.google.dev
  4. OpenClaw release 2026.7.1github.com
  5. `2d2ddc4`github.com
  6. OpenClaw getting-started guidedocs.openclaw.ai
  7. OpenClaw security guidedocs.openclaw.ai
  8. Gemma documentationai.google.dev
  9. secrets guidedocs.openclaw.ai
  10. Developer Policysupport-dev.discord.com
  11. local-model guidedocs.openclaw.ai
  12. Ollama provider guidedocs.openclaw.ai
  13. OAuth2 and permissions guidedocs.discord.com
  14. official Discord guidedocs.openclaw.ai
  15. OAuth2 referencedocs.discord.com
  16. Gateway documentationdocs.discord.com
  17. Gemini API pricing pageai.google.dev
  18. Gemma 4 library recordollama.com
  19. session guidedocs.openclaw.ai
  20. Gemma 4 model cardai.google.dev
OpenClaw