How to Choose AI Agent Tools and Permissions

Start from the output, not the tool menu

Every agent workflow has one deliverable. A drafted proposal, a set of updated rows, a preview deployment, a weekly report. Write it down first, then work backward to the smallest set of reads, writes, and network calls that can produce it. The tool list should fall out of the deliverable, never out of whatever the harness offers on install.

Broad access is the default on most installs, and it is the wrong default for client work. A general terminal, an inbox, a cloud drive, and a browser together reach almost everything on the machine and most things off it. Narrow that to one scoped folder and one read API and the worst case shrinks from anything to one directory, at almost no cost in capability.

• The exact artifact this run has to produce
• The smallest source of truth it needs to read
• The single destination it is allowed to write to
• The one external action, if any, that needs a person

Which permission tier does this action belong in?

Sort every action a workflow touches into three tiers. Read gathers evidence and changes nothing. Draft produces something reversible: a file on disk, a saved email draft, a branch, a preview URL. Execute changes a system other people can see, reaches another human, or spends money.

The tiers decide where the approval prompt goes. A workflow that assembles an outreach email needs read and draft, not send. A release helper needs draft and a preview, not production credentials. Keeping the third tier small is most of the safety work, and it is the part teams skip because the first two feel harmless enough to bundle in.

What does each harness call a permission?

Monolith runs Claude Code and Hermes daily, and tests OpenClaw as a third harness. All three arrived at the same idea with different vocabulary, so the mapping matters more than the syntax.

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 build

openclaw config set tools.exec.mode allowlist
openclaw approvals allowlist add "npm run build*"
openclaw gateway restart

Scope the credential, not just the tool

A tool rule limits which command runs. It does not limit what that command can reach once it is running. The API key decides that. Most of the damage in agent incidents comes from a correctly permitted tool holding a badly scoped credential, which is why the key deserves as much attention as the rule file.

• 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

Target confirmation is the cheapest control on that list and the one most often missing. A correct command against the wrong repository, the wrong site, or the wrong mailing list is still an incident. Have the agent print the account, the environment, and the recipient count as its last step, then make a person match those three against the brief before approving.

Where MCP servers change the math

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.

Tool annotations are the trap. A server can mark its own tools read only or destructive, and the specification tells clients to treat those hints as untrusted unless the server itself is trusted. They describe intent, not enforcement.

Add one tool at a time

Run the new tool once against something that cannot hurt anyone. Record the output shape, what it does on a timeout, what it costs per call, and what it retains. Then write the rule before the next run. A tool with no written rule is running on the harness default, and the harness default is almost always wider than your workflow needs.

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

Permissions rot in one direction. Every incident, every deadline, and every new integration adds an entry, and nothing ever removes one unless a review does. Put the review on a schedule and treat a shrinking rule file as a good quarter.