A business reader should retrieve approved information and return an answer without changing the source system. OpenClaw tool permissions help define that boundary, but a profile name or a prompt saying “read only” is not sufficient evidence. Verify the effective capabilities, credentials, and runtime used by the actual workflow.
1. Define what the reader may do
Consider an illustrative supplier-review assistant. It may read an approved document collection and selected supplier records, then return a summary in the requesting conversation. It may not update records, send supplier messages, schedule follow-up work, or ask a more privileged agent to perform those actions. This is a design example, not a customer deployment or reported test result.
Define read-only separately for source records, local files, and communication. Reading a document can still disclose it through an allowed outbound channel. Record permitted datasets, destination conversations, and the service identity behind each integration. Where the provider supports it, use read-scoped credentials as an independent boundary.
2. Resolve the policy that applies to this run
The current documentation describes filtering through the tool profile, provider profile, global policy, provider policy, agent policy, agent-provider policy, sandbox policy, and applicable subagent restrictions. Later restrictive layers cannot restore tools denied earlier. An agent-specific profile replaces the global profile; it is not simply an extra restriction on that profile.
Review tools.profile, tools.allow and tools.deny, the matching agents.entries settings, and provider/model overrides together. Deny wins. Expand groups into actual tool names: group:fs includes read, write, edit, and apply_patch, so it is not a read-only group.
A full tool profile selects capabilities; it does not grant Full Access execution permissions. Also record the session permission mode, requester/channel restrictions, integration availability, and selected runtime. Repeat the inventory for each production provider route rather than assuming a model change leaves the callable surface unchanged.
3. Build a capability inventory, not a profile screenshot
Use a worksheet like this for the supplier reader. Replace the examples with names from the installed tool catalog and observed controls. Exact read-tool selections are easier to review than an entire connector namespace that also contains update or delete operations.
| Surface | Intended boundary | Evidence to collect |
|---|---|---|
| Document retrieval | Approved collection only | Allowed document succeeds; out-of-scope document is denied. |
| Supplier connector | Read operations and read-scoped identity | Record retrieval succeeds; disposable update is denied. |
| Local files and shell | No source mutation or unrestricted execution | Effective tool list, file-root policy, and unchanged test fixtures. |
| Browser, desktop, and nodes | Unavailable unless separately justified | No alternate logged-in UI or command route can change test data. |
| Messaging and delegation | Only the required response path | Unrelated sends and privileged-agent handoffs are unavailable. |
| Scheduling and setup | No persistent work or policy changes | Automation, configuration, and installation capabilities are excluded. |
4. Close alternate write paths
Tool policy filters named capabilities; it does not inspect every side effect inside an allowed shell command. Denying write and edit while retaining unrestricted shell exec is not read-only enforcement. The configuration reference also distinguishes write from apply_patch: denying write does not deny apply_patch.
For a reader that needs no execution, exclude runtime capabilities as well as direct file mutation. If execution is necessary, define the filesystem and host boundary separately and test it. A read-only workspace mount does not make every other mounted path or remote service read-only.
Review plugin and MCP tools alongside built-ins. The docs support exact MCP tool names and server globs, with an additional sandbox tool gate for sandboxed sessions. Allowing all plugin tools is not equivalent to allowing one read operation. Plugin code also runs in the Gateway process; callable-tool restrictions are not isolation for installed executable code.
5. Inspect the real session and runtime
Use openclaw sandbox explain for the relevant session or agent to inspect sandbox mode, workspace access, effective sandbox tool policy, and elevated gates. This explains that layer; it is not a complete inventory of external credentials or business-system permissions.
The documented read-only session mode limits OpenClaw-managed reads to the session root, omits managed mutation tools, and denies exec. Native harnesses can retain their own tool surface under their permission controls. Verify the runtime you deploy instead of treating the session label as a universal promise.
Tool presentation can also differ: Code Mode moves tools behind a callable catalog. A short visible list is therefore not proof of few effective capabilities. Inspect the eligible underlying catalog and test actual calls after changing providers, session modes, or integration configuration.
6. Run harmless positive and negative tests
Use disposable documents and a test supplier record, with no production credentials. These are recommended acceptance tests, not results claimed by this article. A refusal in chat alone is weak evidence: the control must prevent the action, and the target must remain unchanged.
- Read an approved item and verify the answer refers to the intended record.
- Request an out-of-scope read and a harmless update to the test record; capture the denial and independently inspect the record.
- Try equivalent writes through every enabled route, including shell, connector, browser, and delegated work where applicable.
- Repeat with each production provider/runtime combination and both sandboxed and unsandboxed session types if both are permitted.
- Disable the required read integration and confirm the workflow reports the missing capability instead of silently switching to a broader route.
7. Keep a versioned acceptance record
Keep the OpenClaw version, sanitized configuration revision, agent and requester context, provider/runtime, effective tools, expected outcomes, observed denials, and target-system checks together. Name an owner to repeat the tests after tool, plugin, policy, or runtime changes. Do not store secrets in the evidence.
The bundled Policy plugin can check conformance and drift against authored requirements, but its documentation explicitly says it does not enforce tool calls at request time. Use those checks as supporting evidence, not a replacement for runtime controls.
OpenClaw assumes one trusted boundary per gateway. Different agent names and tool profiles do not establish hostile-tenant isolation. Accept the reader only when its necessary reads work and its prohibited actions are demonstrably blocked within the intended deployment boundary.
Sources and further reading
- OpenClaw: configuration — tool policy
Checked October 20, 2026 - OpenClaw: multi-agent sandbox and tool restrictions
Checked October 20, 2026 - OpenClaw: sandbox vs tool policy vs elevated
Checked October 20, 2026 - OpenClaw: tool and agent permissions
Checked October 20, 2026 - OpenClaw: session permission modes
Checked October 20, 2026 - OpenClaw: Policy plugin conformance checks
Checked October 20, 2026 - OpenClaw: security and trust boundaries
Checked October 20, 2026
Research-assisted writing by Santuri. Technical statements are grounded in the sources above, checked on the dates shown. Deployment requirements depend on your environment and installed version. Workflow examples are illustrations, not customer case studies.
Planning a deployment? Start with our enterprise OpenClaw guide and business workflow examples, or review our deployment approach.