OpenClaw Incident Response: What to Do in the First Hour

Published June 28, 2026 · OpenClawBlog Team. Sources checked September 13, 2026.

A suspicious tool call, an unknown sender, or a credential appearing in a transcript can make an OpenClaw installation feel impossible to reason about. The first hour is not the time to prove every detail. It is the time to stop any path that can still act, preserve enough evidence to understand the scope, and invalidate credentials that may have escaped.

This runbook follows OpenClaw's official operator incident-response guidance, with supporting documentation on storage, access control, logging, and Gateway exposure. It is not a report of a specific breach, and it does not claim that a local incident was reproduced. The commands marked as proposed checks should be run by the operator in a controlled environment.

The decision that changes the sequence

Start with one question: can an outside sender, remote client, agent, plugin, or still-running process cause another side effect right now? If the answer might be yes, contain first. If the concern is only that a secret may have appeared in a log or transcript, treat the secret as compromised while keeping the evidence in a restricted location.

The last distinction matters. OpenClaw's security policy assumes a trusted operator boundary for each Gateway. A prompt can still be dangerous, but a suspected compromise report should identify the authority that was actually reached, not just the text that tried to manipulate the model.

0–5 minutes: stop the path that can still act

The documented containment sequence is short. Stop the macOS app if it supervises the Gateway, or stop the openclaw gateway process. Close exposure by returning gateway.bind to 'loopback', or disable Tailscale Funnel or Serve until the situation is understood. Freeze risky DMs and groups with dmPolicy: 'disabled' or a strict mention requirement, and remove any wildcard allow-all entry.

If a tool boundary is the concern, take the Gateway out of service before asking it to investigate itself. A running agent may still have the same tools, credentials, or session visibility that are under review. This is a proposed operating rule, not a claim from a local test: host-side containment is easier to reason about than a diagnostic conversation conducted through the suspected path.

Do not assume that a session label or a friendly channel name limits the damage. OpenClaw documents one trust boundary per Gateway. Authenticated Gateway callers are treated as trusted operators, and session keys select routing or context rather than acting as per-user authorization. If the suspected credential could call the Gateway, scope the review to the whole Gateway cell.

5–15 minutes: freeze a safe evidence snapshot

Record the time in UTC, Gateway host, operating system, OpenClaw version, active profile, state directory, exposure pattern, affected channel or client, suspected credential family, and the last known-good time. The incident-response page specifically asks for the timestamp, host OS and version, attacker input and agent action, relevant transcripts and log tail, and whether the Gateway was exposed beyond loopback.

Collect from the host rather than from the agent. The documented log command is openclaw logs; the default rolling file is under /tmp/openclaw/, with a date-based filename unless logging.file changes it. Relevant transcripts are under ~/.openclaw/agents/<agentId>/sessions/*.jsonl. If a named profile is involved, use the profile-specific form documented by OpenClaw.

Make two evidence lanes. Keep the original material in a restricted forensic location. Create a separate support copy containing only the fields needed to reconstruct the sequence. OpenClaw's storage guidance says that session transcripts may contain pasted secrets, file contents, command output, and links. Its logging documentation says redaction is always enabled, but redacted logs can still contain sensitive summaries, URLs, and operational context. A redacted file is safer to review; it is not automatically safe to publish.

For a quick status view, openclaw status --all is the preferred pasteable surface in the storage guidance. Do not paste a raw transcript into a team chat to make the investigation faster. If the evidence itself contains a live secret, restrict access and begin rotation before sharing a wider copy.

15–30 minutes: rotate the whole credential family

Rotating one visible token is not enough if the Gateway could reach several credential stores. Use the incident-response sequence as a checklist:

1. Rotate Gateway authentication, including gateway.auth.token or gateway.auth.password.
2. Rotate remote client secrets, including gateway.remote.token or gateway.remote.password, on every machine that can call the Gateway.
3. Rotate provider and channel credentials, including WhatsApp credentials, Slack or Discord tokens, model and API keys stored in agent auth databases, and encrypted secret payload values where those are in use.

The auth change has an operational detail that is easy to miss. OpenClaw says a Gateway-auth rotation hot-applies only when the effective auth mode stays the same. An auth-mode change, or an updated process-environment credential such as OPENCLAW_GATEWAY_PASSWORD, requires a restart. Treat a successful configuration write as incomplete until the running process has adopted the new value.

Use the provider or channel's own revocation and rotation controls, then update the protected OpenClaw secret source. Never record the replacement value in the incident ticket, command history, screenshot, or evidence archive. The purpose of the note is to record which credential class changed and when, not to create another copy.

If a plugin, browser profile, paired node, or agent-to-agent route was involved, include it in the same scope decision. OpenClaw's security policy treats installed plugins as trusted code running in the Gateway environment. A tool denial can reduce future calls, but it does not prove that a trusted plugin or a previous tool invocation left no files, processes, or external changes behind.

30–45 minutes: map the blast radius without guessing

Once active access is contained and the main credentials are being rotated, answer four questions.

• Who could reach the Gateway? Check loopback, LAN, tailnet, reverse proxy, Funnel or Serve, remote clients, enabled channels, DMs, groups, and webhooks.
• Which agent and tools were reachable? Record the effective tool profile, sandbox mode, elevated execution policy, browser or node access, plugins, and agent-to-agent settings.
• What data was available? Review configuration, credential directories, model-auth databases, shared state, transcripts, workspaces, and any mounted or synced directories.
• What changed? Look for configuration edits, new or changed plugins, allowlist changes, unexpected processes, file writes, provider activity, messages, and other external side effects.

The security audit reference gives names to several high-signal findings. World-writable state or configuration can let other users modify the trust boundary. Readable auth profiles can expose API keys or OAuth tokens. gateway.bind_no_auth identifies a remote bind without the expected shared secret. These findings describe the current installation; they do not reconstruct everything that happened before containment.

Run the documented checks from the host after the urgent containment step:

openclaw security audit
openclaw security audit --deep

The plain audit covers the normal configuration and filesystem checks. The deep form also includes plugin and skill code scans and live Gateway probe checks. Read each finding and its fix path instead of treating a clean exit as a historical all-clear. A proposed external denial test is still useful: from a separate client or network, verify that the old route no longer answers and that the new auth path is the only intended route. That test was not performed for this article.

Keep content in scope too. OpenClaw's prompt-injection guidance treats webpages, emails, documents, attachments, pasted logs, and search results as potentially hostile input. An approved sender can still forward a poisoned document. If the agent read untrusted content before the event, review what it could call rather than limiting the investigation to the sender identity.

45–60 minutes: rebuild a smaller, observable path

Do not reopen the original broad configuration simply because the credentials changed. The Gateway exposure runbook recommends widening one control at a time. Its starting shape keeps the Gateway on loopback with token authentication, uses session.dmScope: 'per-channel-peer' for multi-user DMs, puts non-main sessions in a sandbox, uses a narrow messaging profile, disables elevated tools, and denies host execution unless a separately reviewed exception is required.

That baseline is a design reference, not proof that it fits every deployment. The same documentation notes that tools.exec.security: 'deny' blocks even benign diagnostic commands. Run host diagnostics outside the agent path, then add only the tool and sender permissions needed for the next controlled step.

Recovery checks should be boring. In a disposable or maintenance lane, use synthetic content and a read-only request. Confirm the intended agent, workspace, session scope, tool policy, and log path. Verify that an unknown DM remains blocked, that a remote route not intended for use remains unreachable, and that the replacement credential works without re-enabling unrelated channels. These are proposed checks, not hands-on results.

After the evidence is preserved, compare the installed component versions with current OpenClaw advisories and apply the relevant supported update. Updating is part of recovery when a boundary failure is version-specific, but it does not erase prior access or prove that a credential was never used.

Failure paths that look like recovery

• Changing the file but not the process: an auth-mode change or process-environment credential may require a restart. The running Gateway is the authority that matters.
• Rotating only the Gateway token: remote client secrets, provider keys, and channel credentials may remain usable.
• Disabling DMs while leaving another route open: groups, webhooks, Control UI access, proxies, and remote clients have separate exposure decisions.
• Trusting redaction too much: redaction masks values before output, but state files and transcripts remain sensitive and must keep filesystem protection.
• Treating a green audit as a clean history: an audit reports the state it can inspect now. It does not prove that a previous tool call, message, or provider request did not occur.

The practical boundary is narrower than the word compromise. If you have only an injection attempt and no evidence that policy, authentication, sandboxing, or a tool boundary was crossed, record it as a suspicious input and keep the conclusion open. If a secret, external action, or unauthorized route is confirmed, move from suspicion to incident handling and keep the affected credential family revoked or rotated until the scope is understood.

What to hand off, and what not to claim

A useful report contains the event time, host and OpenClaw version, exposure pattern, affected channel or client, suspected input, observed agent action, redacted log tail, relevant transcript references, configuration changes, credential families rotated, current containment state, and unresolved questions. The report should identify what was documented by OpenClaw, what was observed on this installation, and what remains a proposed test.

If the evidence suggests a product vulnerability rather than a risky deployment or trusted-plugin behavior, use the private disclosure path in OpenClaw's security policy. Do not publish an unpatched exploit path, secret, or sensitive proof of concept in a public issue. The first-hour goal is a controlled boundary and an honest record. That is enough to decide the next investigation step without pretending the incident is already fully explained.

Sources

• OpenClaw operator incident response. Accessed 2026-09-13.
• OpenClaw Gateway exposure runbook. Accessed 2026-09-13.
• OpenClaw access control and allowlists. Accessed 2026-09-13.
• OpenClaw secrets, storage, and logs. Accessed 2026-09-13.
• OpenClaw security audit checks. Accessed 2026-09-13.
• OpenClaw Gateway logging. Accessed 2026-09-13.
• OpenClaw prompt injection guidance. Accessed 2026-09-13.
• OpenClaw security policy. Accessed 2026-09-13.