OpenClaw and Hermes Security: Test the Permissions You Grant

Review instructions, tools, approvals, isolation, credentials, and data flows as separate boundaries. Includes a runnable synthetic permission lab.

2026-07-24 · 6 min read

Before widening an agent's access, write down what it must read, change, execute, and send. Then test those boundaries with dummy data. A skill description, a tool allowlist, an approval prompt, and an operating-system sandbox each answer a different question. None should be assumed to provide the others.

This checklist covers OpenClaw and Hermes workflows without treating their configuration as interchangeable. Check the documentation for the version and backend you actually run. The included lab models decisions in memory; it does not configure either product or verify a real sandbox.

Separate instructions from enforcement

An OpenClaw skill contains a SKILL.md instruction file with frontmatter. Runtime requirements in its metadata help determine eligibility; they are not a complete permission manifest. OpenClaw also explicitly distinguishes skill allowlists from shell authorization. A visible-skill restriction does not stop an otherwise permitted shell from accessing resources available to its process. See the official skills reference and skills configuration documentation.

In Hermes, approval of skill changes and scanning skill contents are separate controls. Review their current behavior in the Hermes skills documentation. An accepted instruction file still does not demonstrate that every future tool action is appropriate.

For each workflow, document five things: the instructions presented to the model, the tools available, which actions require approval, what the runtime can actually reach, and the credentials it receives. A mismatch between those layers is an actionable finding.

Build a capability worksheet

Run the educational scope lab

Read and download our synthetic security-boundary tests, then run the saved file with Node.js 22 or newer:

node --test security-boundaries.test.mjs

The twelve tests need no external dependencies, network, disk access, shell, or credentials. The four scope: tests model a virtual project root, read-only tool access, and an exact allowed URL origin. They verify that a sibling path, parent-directory traversal, a write request, an unlisted capability, and a lookalike network host are denied by that model.

These are intentionally small policy examples. Lexical path checks do not resolve symlinks, secure mount points, prevent races, or isolate a process. Comparing a URL's origin does not handle redirects, DNS changes, or enforce real network restrictions. Passing these tests teaches what to ask; it does not establish that your installed agent enforces the same rules.

Validate the real filesystem boundary

Create an expendable workspace with non-sensitive marker files. Place one marker inside the permitted directory and another outside it. Using the actual runtime and tools, verify both the permitted read and the expected denial. If the workflow should be read-only, test a write to a disposable file as a separate case.

Check whether shell tools, file tools, mounted volumes, and remote backends share the same restrictions. A restriction in one tool may not apply to another. Investigate symlink behavior with dummy paths, and record the backend and configuration used. A convincing refusal in a chat message is not evidence that the underlying operation was blocked.

OpenClaw documents distinct workspace access settings and backend-specific limitations. Consult its workspace access documentation before interpreting your test. Do not infer that a local setting provides equivalent protection on a remote execution backend.

Control execution, browsers, and outbound data

Treat execution as a separate capability from reading. Review command policy, approval behavior, installers, startup hooks, and the environment available to child processes. A command that looks like a read can invoke another program; naming a command “safe” is not an isolation mechanism. Inspect package scripts before an install gets a chance to run them.

Use a dedicated browser profile for agent work and minimize its privileges. Inventory active sessions, downloads, clipboard access, and connected account actions. A read-only browser interaction may still expose account data to the model or logs. Require an appropriate review step for sensitive account changes and external actions.

For network access, identify necessary destinations and where restrictions are enforced. Tool-level URL checks and process-level egress controls have different coverage. Include redirects, local services, and connector endpoints in the review. Use harmless markers when checking where data travels; never test containment by placing a genuine secret in reach.

Keep credentials and retained context in scope

Inventory environment variables, mounted credentials, browser sessions, connector tokens, and configuration files. Prefer task-specific credentials with narrow permissions and a clear expiry or revocation process. If a credential may have been exposed, revoke or rotate it; narrowing permissions afterward does not invalidate an already copied token.

Trace prompts, command output, downloaded files, persistent memory, and diagnostic logs. Determine whether each is stored locally, sent to a provider, or synchronized elsewhere. Decide what needs retention and what should be excluded. Redacting a user-facing response is insufficient if the raw credential was already captured by a log or external service.

Expand access one capability at a time

1. Begin with dummy data, a narrow workspace, and only necessary read tools.
2. Review the skill and supporting code before adding execution.
3. Add a specific write capability only for a workflow that requires it.
4. Introduce browser or connector access using a dedicated test account.
5. Recheck boundaries after configuration, dependency, or backend changes.

Keep a record of the capability, reason, validation result, and how to revoke it. This makes later permission creep easier to identify. A task that no longer uses a connector should not keep its token merely because the original setup required it.

Use the pre-install skill guide for package inspection and CyberLens as a supporting review where its scan scope applies. Static findings do not verify runtime containment. For the application itself, use the separate pre-launch authorization and release checklist.

About this guide

Published by CyberLens AI with AI-assisted drafting. The linked educational fixture was run with Node.js 22.22.3 on September 19, 2026: all 12 assertions passed on synthetic examples. This is not a test of your application, a CyberLens detection benchmark, or a claim of independent human security review. Verify guidance against the linked documentation and your installed versions.