Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- A permission worksheet identifies every requested capability, its owner, test boundary, expiry, and specific revoke action.
- Failure mode
- An unreviewed server inherits broad runtime access, secrets, or host execution because its purpose sounded harmless.
- Rollback
- Do not connect the server; remove its configuration and credentials from the disposable environment, then record the rejection reason.
“Read-only” is not a permission model
Before adding an MCP server or external tool, independently list what it can reach—not just what its README says it intends to do. The approved OpenClaw configuration and sandbox/tool-policy references distinguish where tools run, which tools are callable, and host-level elevated execution. Use those boundaries to challenge any request for shell, filesystem, browser-profile, network, or secret access.
Complete this worksheet for each candidate:
| Field | Required evidence |
|---|---|
| Supplier and artifact | Maintainer, immutable version/digest, license, change history |
| Purpose and alternatives | Specific job; lower-authority option considered |
| Inputs and outputs | Schema, data classes, citation/log format |
| Requested authority | Network hosts, files, browser profile, commands, credentials, writes |
| Containment | Disposable environment, allowlist, timeout, rate/cost bound |
| Human gate | Who approves a write or credential use, and when |
| Test and monitoring | Fixture cases, expected denial, log owner |
| Expiry and revoke | Review date; exact config/credential removal action |
Reject a request that cannot name an artifact version, a data boundary, a test target, and a revoke route. “We can turn it off later” is not evidence.
Lab — red-team the request
Take a fictional server that “reads project tasks.” It requests unrestricted network, local filesystem, and host command execution. Write a rejection: its stated purpose can be met by an allowlisted read-only API or a fixture. Then write the minimum viable permission request and one test that proves the broader authority is denied.
Checkpoint
Which evidence closes a permission review?
A. A popular package name
B. A successful first run
C. A named artifact version, requested authority inventory, containment test, owner, expiry, and revoke action
D. A promise not to use the dangerous functions
Answer: C. Popularity and intent do not establish control. The record must be reproducible when a future reviewer has to disable the integration quickly.
Learner artifact
Create a redacted configuration screenshot showing only the disposable server name, tool allowlist, and test profile. Blur all tokens and personal paths. Provide a structured text table with the same facts so the lesson remains usable without the image.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.