Which permission tier does this action belong in?
Use three categories. Read means gathering information. Draft means preparing work in a location where it can be reviewed. Execute means taking the consequential action, such as sending a message, publishing a page or changing a business record.
A process that prepares outreach email may need permission to read contact details and save a draft, but not to send. Keep these permissions separate so the reviewer retains the final decision.
| Tier | Example action | Default rule | Undo cost |
|---|---|---|---|
| Read | Fetch a page, list a folder, query a report | Allow, scoped to named paths and domains | None |
| Draft | Write a file, save a draft, open a branch | Allow inside the working directory only | Seconds |
| Execute | Send, publish, spend, deploy, delete | Ask every time, with the target read back | Hours to never |
How different agent tools describe permissions
The products use different names for similar controls. Use the table to locate the relevant settings, then confirm their behavior in the version you are running.
| Control | Claude Code | Hermes | OpenClaw |
|---|---|---|---|
| Rule outcomes | Allow, ask, and deny lists | Smart, manual, or off, plus deny globs | Deny, allowlist, ask, auto, or full |
| Precedence | Deny wins, then ask, then allow | Deny patterns beat the standing allowlist | Policy, allowlist, and approval must all agree |
| Unattended runs | Bypass mode can be disabled by policy | Cron and unattended default to deny | Auto review escalates to a human route |
| Where rules live | Project and user settings files | One user config file plus an env file | A gateway config key, set from the CLI |
| Approval store | Settings file, checked into the repo | User config directory | Host local, exact path unconfirmed |
Two lessons carry across all three. Deny beats allow, so a broad deny cannot hold a narrow exception inside it. And any pattern that tries to constrain arguments is weaker than it looks: a rule that pins a command to one URL will miss the variants.
{
"permissions": {
"allow": [
"Read(./src/**)",
"Bash(npm run build)",
"WebFetch(domain:docs.stripe.com)"
],
"ask": [
"Bash(git push *)",
"Bash(npx vercel *)"
],
"deny": [
"Read(./.env)",
"Read(./secrets/**)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(rm -rf *)"
]
}
}# ~/.hermes/config.yaml
approvals:
mode: smart
timeout: 300
cron_mode: deny
unattended_mode: deny
deny:
- "git push --force*"
- "rm -rf *"
command_allowlist:
- npm run buildopenclaw config set tools.exec.mode allowlist
openclaw approvals allowlist add "npm run build*"
openclaw gateway restartCheck what the connected account can access
Permission to run a tool and the tool's account access are separate controls. An API key is a credential used to connect software to a service. Check what that key can read or change, even if the agent is allowed to call the tool.
- Issue a separate key for the agent, never the shared team key
- Restrict that key to the exact scopes the deliverable needs
- Point the agent at a test account until the workflow is boring
- Keep secrets in an environment file, outside the skill package
- Read the destination back before any send, publish, or deploy
Before approval, show the account, destination and exact action. A correct operation aimed at the wrong website or customer list is still a mistake. Compare those details with the project brief.
What changes when you connect an MCP server
An MCP server hands your agent tools the harness did not write. The 2026-07-28 revision of the Model Context Protocol moved to a stateless request and response model and put the method and tool name into HTTP headers, so a gateway can authorize a call without parsing the body. If you run your own gateway, that is where a central allow list now belongs.
A tool description may label an action as read-only or destructive. Treat that as information to verify, rather than a guarantee enforced by the label itself.
Add one tool at a time
Test a new tool on sample data. Check the output, what happens if it times out, its usage charges and what information it retains. Then set the permissions needed for the next run.
What to review every quarter
- Remove tools no workflow has called in ninety days
- Re-read the allow lists after every harness update
- Rotate the agent keys and drop scopes nothing uses
- Confirm cron and unattended runs still default to deny
- Re-check any MCP server that shipped a new tool list
Review permissions regularly and remove access the process no longer needs. Record why each remaining permission exists so the next reviewer can understand it.
What is the safest default for a brand new agent?
Start with access to approved information and a separate place to save drafts. Add further permissions only when the task needs them and the behavior has been tested.
Should an agent ever send email on its own?
Keep drafting and sending separate. If sending is later automated, define recipients, message rules, exceptions and review requirements explicitly. A successful draft alone does not establish that unattended sending is appropriate.
Do deny rules stop prompt injection?
Permission rules can block some actions, but they do not prevent every misleading instruction. Combine them with restricted account access, isolation where available and tests of the complete workflow.
Map the permissions before anything runs
Inventory the accounts, files, and actions the workflow needs. We can help separate read access from draft and execution permissions, with a named approval gate before anything is sent, published, or changed externally.