Retrieved article excerpt
Open article · Retrieved 2026-10-05T23:34:33.940080+00:00
[← All posts](https://openclaw.ai/blog)
# OpenClaw Completes Security Audit Through OpenAI’s Patch the Planet Initiative
What OpenClaw learned from a broad Trail of Bits security audit through OpenAI's Patch the Planet initiative.
[Josh Avant](https://openclaw.ai/blog/authors/josh-avant "Josh Avant — Member of Technical Staff — OpenClaw Foundation")
[Josh Avant](https://openclaw.ai/blog/authors/josh-avant "Member of Technical Staff, OpenClaw Foundation")
Sep 21, 2026 · 4 min read
An illustrated lobster shell with one coral-colored replacement segment. An illustrated lobster shell with one coral-colored replacement segment.
Security at OpenClaw is an ongoing initiative, and part of that work is being transparent about what we find and fix along the way.
OpenClaw recently completed a broad security audit with [Trail of Bits](https://www.trailofbits.com/) through OpenAI’s [Patch the Planet](https://openai.com/index/patch-the-planet/) initiative, giving us a clearer view of where OpenClaw’s security boundaries needed enhancements. Today we’re sharing the results.
Summary:
- Trail of Bits submitted 27 private repository advisories and 3 standalone hardening pull requests.
- Of the advisory reports, 24 described severity-rated vulnerabilities. 23 were classified as confirmed vulnerabilities, although some were closed without publication because they were fixed before reaching a stable release. The remaining 1 concerned a vulnerability fixed before submission.
- Those 24 reports were rated 0 Critical, 2 High, 16 Medium, and 6 Low. The other 3 were classified as defense-in-depth findings and did not receive severity ratings because they did not cross a documented trust boundary.
- Every actionable issue has been repaired, and all 3 standalone hardening PRs were merged.
## How the Engagement Worked
Patch the Planet combines AI-assisted security research with human review. Trail of Bits used Codex-assisted workflows to search for issues and develop fixes, then checked the findings manually before sending them to us.
We reviewed each report against OpenClaw’s trust model and release history. We then fixed and tested the accepted issues while coordinating disclosure through private GitHub Security Advisories.
The review covered core permissions and the way OpenClaw handles user data across its features. Although the affected features varied, the same kinds of security challenges kept appearing.
## Permissions Must Follow the Request
The most common problem was losing permissions between steps. A request might enter OpenClaw with limited access, then start another piece of work that no longer carried those limits.
Sometimes the right fix was to carry the original permissions forward. In other cases, the follow-on work did not need access in the first place. A filename generator, for example, does not need tools.
Across OpenClaw, follow-on work must not gain access simply because it lost the context of the original request.
## Use One Name for One Thing
OpenClaw sometimes has more than one name for the same thing so older configurations keep working. Problems appeared when a security check saw one name but the system later used another.
This affected both user identities and feature names. The fix was to determine exactly what the system would use before applying the security policy.
## Check What Will Actually Be Used
Several reports found a gap between what OpenClaw checked and what it later used.
One archive check saw only part of an archive before the full contents were extracted. In another case, a file path changed after OpenClaw had already approved it. The checks looked reasonable on their own, but they did not cover the final operation.
The fix is to bind approval to the exact file, identity, or action that will be used. If anything changes afterward, OpenClaw needs to check again.
## Permissions Can Change While an Agent Is Working
Some features checked permission when they started but not when they ran later. Turning a feature off in configuration did not always reach work that was already running or cached.
We moved those checks closer to the moment of use. For work that takes time, OpenClaw may also need to check again before returning a result.
One finding showed how this could happen. An agent may keep working long after a request begins, so checking permissions only when it starts is not enough. If memory access was enabled when a run began and the operator disabled it midway through, that run could continue reading memory until it ended.
The fix was to make tools check the current setting whenever they act. The issue only affected a run that had already been given access, but it showed that permission changes also need to reach work already in progress.
## Lessons From the Engagement
Permissions and identity must follow a request for as long as OpenClaw is working on it. Security checks must apply to the exact resource that will be used, and turning access off must affect work that is already running. Tests need to exercise the real security boundary instead of stopping at the helper where a bug happened to appear.
Every issue has been repaired on `main` and is shipped in the 2026.8.1 and 2026.7.33 LTS stable releases.
Thank you to Samuel Judson, Lucas Bourtoule, the wider Trail of Bits team, and to OpenAI for building the Patch the Planet initiative. 🦞