Build a permission boundary that can be tested

Before you start

• A disposable workspace and a separate test identity where possible

Define scope

1. List allowed files, network destinations and tool actions. Express one concrete allowed task: read the sample file and return its first line.
2. Use the current security guide to configure approvals; do not turn approvals off to make a trial run more smoothly.
3. Reduce actual access with a dedicated OS identity, container or filesystem permissions appropriate to your host. Verify the tool process uses that identity.
4. Try an explicitly disallowed write to a harmless protected test location and inspect both the tool result and filesystem.

Success criteria

The allowed read succeeds, the denied write leaves the protected location unchanged, and the execution record identifies the permission mechanism responsible. Model refusal alone only verifies model behavior. A security audit is useful evidence about configuration, but does not demonstrate every runtime boundary.

Revisit when adding tools

A new channel, skill or connector can widen the boundary. Repeat the denied-operation check after each addition. If it unexpectedly succeeds, stop the test and retain configuration plus process evidence before changing it.

Evidence and limits

Official documentation checked

• Original BotClaw acceptance procedure based on linked official documentation. Product commands were not executed; check your installed version.

Sources

• https://hermes-agent.nousresearch.com/docs/user-guide/security
• https://docs.openclaw.ai/gateway/security