0–5 min: tool inventory
List tools, owners, tokens, versions, scopes, and whether each can read, write, execute, browse, fetch, or remember.
Success checkEvery active tool has an owner and authority class.
AI agent operations guide · Updated 2026-06-27
Agent Tool Permission Model Checklist: Read/Write Tools, Network Access, MCP Scopes, Browser Actions, Approval Prompts, and Audit Logs
A practical checklist for deciding what an AI agent may read, write, click, fetch, execute, remember, and log before connecting tools such as browsers, MCP servers, scrapers, codebase memory, and command runners.
Agent tools are not equal. Reading a URL, scraping a page, clicking inside a browser, writing a file, running a command, calling an MCP server, and storing memory all create different blast radiuses. A permission model makes those differences explicit before the agent acts.
This checklist connects Agent-Reach, Firecrawl, Playwright, Jina Reader, codebase-memory-mcp, Claude Code, and SkillSpector-style reviews into one practical model: classify tools by authority, define approval prompts, scope network access, separate read and write paths, log every privileged action, and keep humans accountable for the final decision.
RepoDaily verdict
Start agents with read-only, source-grounded tools. Add network, browser, write, command, MCP, and memory permissions only when the task needs them, with owner approval, denied paths, scoped tokens, audit logs, and a stop path. A useful agent tool model is not about maximum autonomy; it is about explicit, reviewable authority.
RepoDaily fixture evidence: simulated permission boundary test
This is not a benchmark of Claude Code, Codex, Playwright, Firecrawl, or any single AI product. RepoDaily created a small local test fixture to check whether the permission model in this article returns the expected allow, prompt, or deny decision for simulated tool actions.
| Evidence item | Fixture result | Why it matters | Limitation |
|---|---|---|---|
| Simulated permission cases | 14/14 simulated tool-action scenarios returned the expected allow, prompt, or deny result. | This validates the article’s permission model, not a specific AI tool. | Deterministic local fixture only; no live agent service is connected. |
| Secret-like file boundary | Requests for `.env.example`, `private-data/`, and `forbidden-paths/` return deny. | Secret-like files and private data need stricter rules than ordinary repo reads. | Uses fake values only; no real credentials or customer data. |
| State-changing action boundary | Writing files, MCP write actions, and production-like browser actions require prompt instead of silent allow. | A read-only research task should not silently turn into write or account-level authority. | The fixture models action classes rather than executing real browser or MCP workflows. |
| Command boundary | `python -m pytest` is allowed; a destructive command such as `rm -rf fixture-repo` is denied. | Safe validation commands and destructive commands need different treatment. | The destructive command is evaluated as a string and is not executed. |
| Memory side effect boundary | Memory write is denied unless retention and deletion rules are defined. | A task that only reads files can still create long-term risk if it persists private context. | No live memory server is used in this fixture. |
- Read this section as a RepoDaily self-test of the checklist’s permission rules, not as a score for any vendor or model.
- The test supports the page recommendation: start with narrow read access and require prompt or deny decisions for state-changing, off-scope, secret-like, or persistent actions.
- The evidence is intentionally small and local, so the result is a reproducible sanity check rather than a full product benchmark.
Quick matrix
| Permission surface | Default policy | Approval trigger | Audit evidence |
|---|---|---|---|
| Read files | Allow scoped repo reads for approved paths | Secrets, private data, ignored files, customer logs, or unrelated repos | Files read, denied paths, source citations |
| Write files | Deny by default outside task branch or sandbox | Any source, config, migration, dependency, release, or generated-file change | Diff, owner approval, test output |
| Network fetch | Allow approved public docs or pinned sources | Private URLs, auth cookies, internal services, customer systems, or unknown domains | URL list, response source, data owner |
| Browser action | Read-only browsing first; no personal profile | Clicks, forms, downloads, logins, admin panels, uploads, payments | Browser profile, actions, screenshots/traces |
| Scraping/crawling | Limit depth, domain, rate, and data type | Login walls, copyrighted assets, personal data, or large-scale crawling | Domain allowlist, crawl settings, output path |
| Command execution | Allow lint/test/read-only commands; prompt for mutation | Install, delete, deploy, migrate, chmod, curl pipe, credential, or network commands | Command log, approvals, exit status |
| MCP server | Enable one server at a time with least privilege | Server can read files, browser, tickets, database, cloud, email, or memory | Server inventory, scope, token owner |
| Memory write | Deny until retention and deletion are defined | Storing user data, repo secrets, customer context, or cross-tenant facts | Memory key, source, retention, deletion proof |
Tool permission maturity scorecard
Score a workflow before giving agents new tools.
| Control | 0 points | 1 point | 2 points | Owner question |
|---|---|---|---|---|
| Tool inventory | Unknown tools active | Partial list | Tool, owner, scope, token, version tracked | What tools can the agent call today? |
| Read/write split | Same permission for all actions | Some prompts | Read, write, command, network, memory separated | Which action changes state? |
| Approval prompts | Ad hoc confirmations | Some risky prompts | Risk-based prompts with stop criteria | When must a human approve? |
| Network scope | Any URL allowed | Some domain rules | Allowlist, depth, auth, and data-type rules | What domains are allowed? |
| Audit logging | No reliable logs | Partial transcript | Tool calls, inputs, outputs, approvals, and diffs logged | Can we reconstruct a run? |
| Revocation path | No disable plan | Manual disable known | Owner can disable tool, token, memory, or browser profile | How do we stop this tool now? |
30-minute agent tool permission test plan
Use this plan before enabling a new browser, MCP, scraper, memory, or command tool.
5–10 min: permission table
Write default policy, approval trigger, denied paths/domains/commands, and audit evidence for each tool.
Success checkThe model is reviewable before the run.
10–18 min: controlled task
Run one low-risk task and capture tool calls, files, URLs, commands, browser actions, diffs, and memory events.
Success checkThe run creates evidence without surprise authority.
18–24 min: abuse probe
Try a near-boundary request: forbidden path, off-domain URL, write action, memory write, or risky command.
Success checkThe tool stops, prompts, or refuses as designed.
24–30 min: rollout decision
Decide allow, restrict, disable, or require another test; update logs, owners, and incident response notes.
Success checkThe permission change has owner, scope, and rollback path.
Permission design flow
- Start from the task: what information must the agent read, what state must it change, and what human decision will remain accountable?
- Classify every tool as read, write, execute, network, browser, MCP, memory, or release/deploy authority.
- Assign the minimum permission for the task and write the denied paths, denied domains, forbidden commands, memory retention rule, and stop action.
- Add approval prompts for actions that change files, run commands, leave the local machine, store memory, touch secrets, or affect users.
- Run one controlled task and inspect logs: tool calls, file access, URLs, browser actions, commands, diffs, memory writes, and reviewer decisions.
- Promote the permission model only for task classes where it improves outcomes without hiding authority or increasing review burden.
Scenario table
| Scenario | Minimum permission | Stop if |
|---|---|---|
| Summarize public docs | Network fetch from approved URLs and source-grounded output | Agent follows links outside allowlist or stores private notes |
| Automate browser QA | Dedicated browser profile, local/dev domains, screenshots/traces retained | Agent logs into personal/prod account or submits forms unexpectedly |
| Fix small code bug | Scoped file read/write, focused test command, no deploy tools | Agent touches secrets, migrations, infra, or unrelated files |
| Crawl target site for agent research | Domain, depth, rate, and output limits | Auth pages, personal data, large downloads, or asset copying appear |
| Use codebase memory | Read memory only for scoped repo and task | Memory writes or retrieves cross-tenant facts without approval |
| MCP server for tickets or docs | Single scoped token and read-only first | Server can write tickets, change repo state, or access unrelated systems |
| Security skill evaluation | Read-only skill review and evidence output | Agent executes exploit-like commands or mixes demo secrets with live environment |
Tool permission risk checklist
Tool authority collapse
When read, write, execute, network, and memory permissions are bundled together, humans cannot see where risk increased.
Prompt-only governance
Telling an agent to be careful is not a permission model. Approval gates, denied paths, and logs must exist outside prose.
Browser session leakage
A browser tool with personal cookies can turn a harmless research task into account-level authority.
MCP scope creep
One MCP server may combine file, ticket, database, and cloud capabilities. Scope and inventory each server.
Unlogged action
If a privileged tool action is not logged, incident response becomes guesswork.
Memory side effect
A read task can still create long-term risk if the agent writes memory or stores private context.
Permission implementation patterns
Read-only first
Begin with source-grounded read tools and add state-changing tools only after one successful controlled run.
Action classes
Define read, write, execute, network, browser, MCP, memory, and release/deploy classes with separate approvals.
Allowlist plus denylist
Use domain allowlists and path denylists together; one without the other leaves gaps.
Dedicated browser profile
Use a separate browser profile for agent actions and log clicks, forms, downloads, and screenshots.
Tool-call audit bundle
Store tool name, input, output summary, approval, owner, timestamp, and resulting diff or artifact.
Permission PR
Treat new tools or wider scopes as a reviewed change with owner, rollback, and incident response notes.
FAQ
Short answers for teams designing agent tool permissions.
What permission should agents start with?
Read-only, source-grounded tools. Add write, command, browser, MCP, network, and memory permissions only when a task proves it needs them.
Are approval prompts enough?
No. Prompts help, but you also need denied paths, scoped tokens, browser isolation, tool inventories, audit logs, and a stop path.
How should MCP tools be reviewed?
Review each server by owner, token, scope, data access, write authority, logs, and disable path.
Why separate memory permission from read permission?
Because a read-only task can still create long-term risk if the agent persists private or stale context into memory.
Related radar
Related RepoDaily briefs
Agent-Reach Review: Give Claude Code, Codex, Cursor, and Other AI Agents Web Access Without a Runtime ProxyPanniantong/Agent-Reach · Developer tool / CLIFirecrawl: The Web Data API Powering AI Agents at Scalefirecrawl/firecrawl · AI model / Agent frameworkPlaywright Explained: Browser Automation for Tests, Agents, and Dynamic Web Workflowsmicrosoft/playwright · Developer tool / CLIJina Reader Explained: URL-to-Markdown Context for Agents and RAG Pipelinesjina-ai/reader · Developer tool / CLIcodebase-memory-mcp Review: Local Codebase Graphs for Claude Code, Codex, Cursor, and Other Coding AgentsDeusData/codebase-memory-mcp · Developer tool / CLIClaude Code Explained: Agentic Coding in the Terminal, IDE, GitHub, Hooks, Plugins, and MCPanthropics/claude-code · Developer tool / CLISkillSpector: NVIDIA's Security Scanner for AI Agent SkillsNVIDIA/SkillSpector · Security tool
Sources
Feedback
Did this page help you make a decision?
Anonymous feedback helps RepoDaily improve what is actually useful.