Set your agent’s permissions
6 min read
Updated
Set your agent’s permissions
Separate instructions, technical permissions and approval, then check the boundaries on a copy without sensitive data.
Direct answer
An instruction states what you authorize. Tool permissions, the connected account and the sandbox determine what can actually execute. Check both before entrusting files or a service to your agent. Approval for one tool does not establish another connector’s rights; record the effective scope before continuing.
Glossary
Terms explained here
Open a term for a short definition, then continue to its full sourced entry if useful.
01
Distinguish four layers
“Read this folder and ask before editing” is an instruction to the model. It does not remove any rights from the connected account. A tool permission allows or blocks an operation; a sandbox constrains its environment, such as accessible paths or the network. An approval authorizes an operation within the displayed scope.
These mechanisms complement each other, but their scope depends on the product and configuration. A folder protected by the terminal sandbox does not prove that a messaging connector is restricted. Inspect each tool’s effective permissions and the rights of its account.
- Instruction: the boundary you ask the model to respect.
- Effective permission: the operation the tool and account can execute.
- Sandbox: resources accessible within the relevant environment.
- Approval: consent for the displayed scope.
02
Write a verifiable authorization
Example: read only the copies in “test-quotes”; suggest corrections in the conversation; wait for my approval before editing a specific copy; send nothing. For each action, record the target, account, accessible data, duration and expected evidence.
Counterexample: “be careful” with an administrator account and tools allowed to do everything. The phrase expresses a preference without establishing a technical boundary. Grant only necessary access and remove unused connections.
03
Check your product’s settings
Open the official documentation for your product and version. Identify reading, writing, terminal tools and connectors. Check rules inherited from the account or organization, saved permissions, and the scope of a one-time or permanent approval.
Configure read-only access or approval requests where available. If the product cannot enforce the intended boundary, use copies and a less privileged account, or perform the action manually. This guide does not provide a tested interface walkthrough for every provider.
04
Observe a bounded trial before the real task
In a test folder without sensitive data, explicitly authorize a trial: read a copy, then attempt to write a harmless marker to check the control. Record its contents first. Reject the write request if it appears, then check that the copy is unchanged. Do not test with a real message, payment or deletion.
If writing occurs without the expected approval, stop the task and correct permissions. An agent’s refusal sentence does not prove technical enforcement: inspect the tool result or available log. A successful trial covers that operation, not every tool or possible path.
05
Recheck scope after a change
After changing the account, connector, folder or saved rule, repeat verification for the affected access. Success in the test folder does not prove the real account’s behavior; start by inspecting its settings without triggering an external action.
Before a real approval, compare the request with the prepared target: exact file, recipient, content and expected effect. If it includes another access or a lasting authorization, reject that scope and reformulate the request. Keep the observed result with the configuration used so you know what was checked.
Keep this
Checklist
- 01The real request has the same target and scope as those reviewed.
- 02The target and account are identified.
- 03Effective settings match the instruction.
- 04The authorized trial on a copy produced the expected request or denial.
- 05No change occurred after denial.
- 06An unknown scope blocks the real action.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- Configure the sandboxed Bash tool (opens in a new tab)Anthropic · Filesystem and network isolation for the terminal; scope and limits distinct from approvals.
- Authorization (2025-06-18) (opens in a new tab)Model Context Protocol · Authorization to access HTTP MCP servers in this protocol version; does not guarantee individual tool permissions.
- Configure permissions (opens in a new tab)Anthropic · Primary source for technical distinctions; original SkillCodex procedure and examples.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Set your agent’s permissions” step by step
# Apply the “Set your agent’s permissions” guide in your agent ## Objective An instruction states what you authorize. Tool permissions, the connected account and the sandbox determine what can actually execute. Check both before entrusting files or a service to your agent. Approval for one tool does not establish another connector’s rights; record the effective scope before continuing. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Separate instructions, technical permissions and approval, then check the boundaries on a copy without sensitive data. - Preserve the correct decisions already in place. ## Guide steps - 1. Distinguish four layers — “Read this folder and ask before editing” is an instruction to the model. It does not remove any rights from the connected account. A tool permission allows or blocks an operation; a sandbox constrains its environment, such as accessible paths or the network. An approval authorizes an operation within the displayed scope. - 2. Write a verifiable authorization — Example: read only the copies in “test-quotes”; suggest corrections in the conversation; wait for my approval before editing a specific copy; send nothing. For each action, record the target, account, accessible data, duration and expected evidence. - 3. Check your product’s settings — Open the official documentation for your product and version. Identify reading, writing, terminal tools and connectors. Check rules inherited from the account or organization, saved permissions, and the scope of a one-time or permanent approval. - 4. Observe a bounded trial before the real task — In a test folder without sensitive data, explicitly authorize a trial: read a copy, then attempt to write a harmless marker to check the control. Record its contents first. Reject the write request if it appears, then check that the copy is unchanged. Do not test with a real message, payment or deletion. - 5. Recheck scope after a change — After changing the account, connector, folder or saved rule, repeat verification for the affected access. Success in the test folder does not prove the real account’s behavior; start by inspecting its settings without triggering an external action. ## Acceptance criteria — Checklist - The real request has the same target and scope as those reviewed. - The target and account are identified. - Effective settings match the instruction. - The authorized trial on a copy produced the expected request or denial. - No change occurred after denial. - An unknown scope blocks the real action. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:f4c50833c1716c2880a6ae4effd6deb55f27f13d62845e9ab6de16c192473d54
Diagnose a problem
Diagnose a “Set your agent’s permissions” guide gap
# Diagnose a failed application of the “Set your agent’s permissions” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. Distinguish four layers — “Read this folder and ask before editing” is an instruction to the model. It does not remove any rights from the connected account. A tool permission allows or blocks an operation; a sandbox constrains its environment, such as accessible paths or the network. An approval authorizes an operation within the displayed scope. - 2. Write a verifiable authorization — Example: read only the copies in “test-quotes”; suggest corrections in the conversation; wait for my approval before editing a specific copy; send nothing. For each action, record the target, account, accessible data, duration and expected evidence. - 3. Check your product’s settings — Open the official documentation for your product and version. Identify reading, writing, terminal tools and connectors. Check rules inherited from the account or organization, saved permissions, and the scope of a one-time or permanent approval. - 4. Observe a bounded trial before the real task — In a test folder without sensitive data, explicitly authorize a trial: read a copy, then attempt to write a harmless marker to check the control. Record its contents first. Reject the write request if it appears, then check that the copy is unchanged. Do not test with a real message, payment or deletion. - 5. Recheck scope after a change — After changing the account, connector, folder or saved rule, repeat verification for the affected access. Success in the test folder does not prove the real account’s behavior; start by inspecting its settings without triggering an external action. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Checklist - The real request has the same target and scope as those reviewed. - The target and account are identified. - Effective settings match the instruction. - The authorized trial on a copy produced the expected request or denial. - No change occurred after denial. - An unknown scope blocks the real action. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:6758936d511348205a90c4dee955710a56c7e7bbd910e5fcb3f1e111c971810d
Pack digest: sha256:ff65b5dfb15abe4504841d1e95698851135fe858f9a39bbdd204e0bb13aeb843