OpenClaw Security Audit: What Trail of Bits Found and Fixed

OpenClaw has completed a broad independent security audit with Trail of Bits through OpenAI’s Patch the Planet initiative. The engagement produced 27 private repository advisories and three standalone hardening pull requests. Of the 24 severity-rated reports, OpenClaw lists zero critical, two high, 16 medium, and six low findings.

OpenClaw says 23 reports described confirmed vulnerabilities, one concerned a vulnerability fixed before submission, every actionable issue has been repaired, and all three hardening pull requests were merged. The fixes are reported as shipped in OpenClaw 2026.8.1 and the 2026.7.33 LTS stable release.

Source note: This article is based on OpenClaw’s official audit recap published September 21, 2026. The public recap summarizes the engagement but does not disclose every private advisory. Review current OpenClaw releases, security advisories, and documentation before making production decisions.

OpenClaw security audit at a glance

How the audit worked

OpenClaw describes Patch the Planet as a combination of AI-assisted security research and human review. Trail of Bits used Codex-assisted workflows to search for issues and develop fixes, then manually checked findings before submitting them.

OpenClaw reviewed each report against its trust model and release history, repaired accepted issues, tested the changes, and coordinated disclosure through private GitHub Security Advisories. That workflow matters because an AI tool can expand coverage and accelerate investigation, but the severity, exploitability, remediation, and disclosure decisions still require experienced security judgment.

The engagement examined core permissions and how OpenClaw handles user data across multiple features. The affected features varied, but the official recap groups the lessons around four recurring security patterns.

The most important finding: permissions must follow the request

OpenClaw reports that the most common problem was losing permission context between steps. A request could enter the system with limited access and then start follow-on work that no longer carried those same limits.

This is a fundamental agent-security problem. A system may correctly authorize the initial action but accidentally give a later tool, background task, helper, or delegated operation broader access. The safe design is to preserve the original authority through every downstream step—or remove access entirely when the later step does not need it.

For example, a filename generator does not need tool access. A background worker processing a restricted request should not inherit a general service credential merely because it runs outside the original request handler. Agent permissions should be explicit, minimal, and traceable across the full workflow.

Identity aliases must resolve before policy is applied

OpenClaw supports older configuration names for compatibility. The audit found that security checks could see one name while the system later used another equivalent identity or feature name.

That creates a gap between the object that policy evaluated and the object that actually executed. The reported fix is to determine the canonical identity or feature first and then apply security policy to that exact value.

Operators should use the same principle in custom plugins and integrations. Normalize account IDs, channel identities, paths, feature aliases, and provider names before applying allow-lists or permission checks. Do not authorize an unverified label and resolve it to a different resource later.

Validate the exact resource used at execution time

Several reports involved a difference between what OpenClaw checked and what it later used. The recap gives two examples: an archive check inspected only part of an archive before full extraction, and a file path changed after approval.

Both are variations of a time-of-check versus time-of-use problem. A security check can look correct while still protecting the wrong resource. Approval must bind to the exact file, identity, archive contents, destination, or action that will be used. If the target changes, the system needs to validate it again.

For agent operators, this means testing more than the happy path. Include archive traversal, symbolic links, path normalization, renamed resources, redirected downloads, changed browser targets, stale identifiers, and operations that continue after the original request returns.

Permission changes must reach work already in progress

One finding described a run that already had memory access. If an operator disabled memory while that run was still active, the existing run could continue reading memory until it ended.

OpenClaw says the fix moved checks closer to the moment of use, so tools read the current setting whenever they act. For longer work, the system may also need to check permissions again before returning a result.

This is an important operational lesson: revocation is not complete if it only affects new sessions. When access is removed, teams should know whether active runs, cached credentials, queued jobs, subagents, browser sessions, and background workers observe that change immediately.

What the severity numbers do—and do not—prove

The reported result is meaningful: no critical finding, two high-severity findings, a larger group of medium findings, and completed remediation. It is evidence that the project subjected important trust boundaries to expert review and acted on the results.

It is not a guarantee that every OpenClaw installation is secure. The audit snapshot covers a particular codebase and scope. Real deployments add plugins, credentials, messaging channels, model providers, browser profiles, remote nodes, schedules, network exposure, and administrator choices.

A secure upstream release can still be deployed unsafely. Conversely, a private advisory that was fixed before a stable release may never have affected an operator who only installed stable builds. The right conclusion is to verify the exact version, configuration, and exposure of the installation in front of you.

Practical checklist for OpenClaw operators

First, confirm the version and release channel:

openclaw --version
openclaw gateway status
openclaw doctor
openclaw security audit

Review Doctor’s proposed changes before accepting repairs. Then verify the installation in layers:

1. confirm the deployed version includes the audit fixes;
2. inventory plugins, tools, model providers, channels, paired nodes, browser profiles, and scheduled jobs;
3. rotate credentials if the deployment history or exposure is uncertain;
4. test that a restricted request remains restricted through delegated and background work;
5. disable one nonessential permission during a harmless active test and confirm the running operation loses access;
6. verify archive extraction, file destinations, symbolic links, uploads, and downloads stay inside intended boundaries;
7. confirm canonical identities are used for users, channels, features, and resources;
8. review public network exposure, reverse-proxy rules, TLS, authentication, and rate limits;
9. inspect logs for sensitive data and retain enough evidence to investigate failures;
10. maintain a verified backup and recovery procedure before security-related upgrades.

Do not run destructive or consequential tests against production data. Use a controlled environment and non-sensitive test accounts, then repeat a small set of harmless acceptance checks on the production path.

What this means for teams building AI agents

The audit’s lessons extend beyond OpenClaw. Agent systems combine long-running work, changing state, delegated tools, background tasks, and multiple identities. Traditional request-level authorization is often too early and too narrow.

A production agent platform should carry authority with the work, resolve identities before checking policy, bind approvals to exact resources, re-check access near the action, propagate revocation to active work, and test the complete trust boundary. These controls belong in the application architecture rather than in prompts alone.

The Hermes and OpenClaw agent setup project reflects the same operating model: isolated environments, scoped credentials, explicit permissions, monitoring, backups, and end-to-end verification.

How I can help secure an OpenClaw deployment

I provide OpenClaw setup and security support for installation reviews, Gateway architecture, model providers, channels, plugins, browser access, credentials, backups, monitoring, upgrades, and acceptance testing.

For custom systems, I also offer AI consulting, workflow automation, SaaS product engineering, and website development.

Book a free strategy call if you need to verify an existing OpenClaw environment or design a safer agent workflow from the start.

Official sources

• OpenClaw: Trail of Bits audit recap
• OpenClaw security documentation
• OpenClaw GitHub security advisories
• OpenAI: Patch the Planet