[The agent fieldbook](https://www.agentlist.io/learn/guides) # Give an agent the right permissions Translate a task into specific access. Let useful work proceed while keeping consequential actions visible and reviewable. Chapter 03 of 1014 min readBeginner [Jump to the exercise](#try-it) Set the boundaries, one useful step at a time. Keep this chapter open alongside your next real task. ## What you’ll be able to do - Distinguish reading information from changing external state. - Choose access that matches a specific task and workspace. - Check the actual result and revoke access when the work ends. ## 1\. Translate the job into concrete actions Start with the task and list what the agent needs to do. ‘Prepare a customer follow-up’ might involve reading a meeting note, looking up an account, writing a draft, and sending an email. Those actions have different effects. Reading a note exposes information to the system. Editing changes a record. Sending creates a communication that another person can act on. A single label such as ‘email access’ can hide several of these abilities. For each action, name the resource and purpose. Reading one project folder is narrower than reading an entire drive. Creating a draft in a test account is different from changing a customer record in production. Check the actual permission screen and provider documentation. Do not assume a connection grants only the actions mentioned in your prompt. Record any permission that is broader than the task requires. Worked example ### Illustrative access map For a weekly project digest: read the chosen project board, read the team's approved notes folder, and create a draft document. The task does not require access to unrelated projects or permission to send the digest. Review the draft before deciding whether to distribute it. ## 2\. Put boundaries in the access controls Use the narrowest permissions that let the agent complete the authorized work. Where the product supports it, choose specific accounts, repositories, folders, or projects. Prefer a test workspace for the first run. If the provider only offers a broad connection, decide whether a smaller exported sample or a different integration can serve the task. The limitation belongs in your setup decision, not in a hope that the agent never visits the wrong place. Written instructions still matter, but they are not a substitute for enforced access controls. A request to ‘only edit this folder’ describes intended behavior. A credential limited to that folder restricts what a tool can do. The two can work together. Verify the restriction with a harmless check where practical, such as confirming that the connected account sees only the expected project. Avoid testing boundaries by attempting destructive actions. ### Credentials stay in the connection flow Use the product's supported authorization or secret-storage mechanism. Do not paste passwords or tokens into ordinary task text. If a credential has been exposed, revoke or rotate it through the provider before continuing. Try it yourself ## Design a permission boundary Adjust what an agent can read, change, and send. See how each permission changes the review boundary for a sample task. **Read project files**Reading can expose private information. Select the smallest useful folder.**Edit a working copy**A working copy makes changes reviewable, but is not a security sandbox.**Run project commands**Commands can run project code and cause effects outside the edited files.**Use the network**Network access can move data outside the workspace. Review the destination and payload.**Prepare an external action**External actions need a separate approval tied to the exact destination and content. #### Draft your permission policy These controls draft instructions. Enforce access separately in the agent’s settings and connected accounts. Read only the selected project files. Any capability not listed here is outside this task. Stop and ask if the task requires it. ## 3\. Put review immediately before the consequential action Allow the agent to prepare a complete result within the agreed scope. Review becomes useful when there is something concrete to inspect: the exact message and recipients, the proposed file changes, the order and total, or the destination of a publication. A vague approval at the start cannot reveal mistakes in an artifact that does not yet exist. Decide which actions need review based on consequence and reversibility. Editing a disposable draft can often proceed within the task. Sending to a customer, modifying production data, or making a purchase deserves a clearly defined authorization boundary. Your organization may require additional controls. Use those controls as the rule for the workflow, and keep the approval tied to the exact action and artifact being reviewed. 1. ### Prepare Let the agent gather the permitted inputs and create the draft or proposed change. 2. ### Inspect Check content, destination, scope, and any amount or recipient associated with the action. 3. ### Authorize and verify Authorize the specific action when appropriate, then inspect the resulting record or receipt. A request being submitted does not prove completion. ## 4\. Keep external content in its proper role An agent can encounter instructions inside web pages, emails, documents, issue descriptions, or tool results. Some text is ordinary task material. Some may attempt to redirect the agent, reveal private information, or trigger an unrelated action. OWASP describes this class of problem as prompt injection. A retrieved page should supply evidence for the task, not acquire authority over your connected accounts. Keep the permission boundary small enough that a misleading document cannot turn a reading task into a powerful action. If a source tells the agent to upload data elsewhere, install a tool, or contact someone, treat that as untrusted content until independently authorized. Preserve useful factual material from the source when possible. Investigate the suspicious instruction without following it. Filtering alone does not establish that the remaining content is safe. ## 5\. Know how to stop and recover Before enabling write access, identify the relevant history, backup, draft, or rollback mechanism. The recovery plan should match the action. A document may have version history. A code change may live on a branch. A sent email generally cannot be treated like a local draft, even if the interface offers a short undo window. Do not describe an action as reversible unless you have checked what reversal actually restores. If the agent performs an unexpected action, pause the run and stop further writes. Preserve the activity log and identify the affected resources. Revoke the connection if continued access is part of the problem. Restore only the changes you can attribute to that run, using the provider's supported recovery path. Then diagnose whether the cause was broad access, unclear scope, a misleading input, or an incorrect action by the agent. ## 6\. Review access as the work changes At the end of the trial, check what the agent actually read and changed against your original access map. Keep the artifact and any useful activity record. Disconnect temporary integrations or revoke temporary credentials when they are no longer needed. For a recurring workflow, name an owner who can review the connection when the task, team, or application changes. Increase access in response to a demonstrated need. If a report is accurate but cannot reach the delivery folder, resolve that specific gap. A successful read-only run does not establish that unattended writes are appropriate. Test each new class of action with a representative case and a clear recovery path. Your permission setup should remain understandable to the person responsible for the result, even as the workflow becomes more capable. ## When things go wrong Start with the failure you can observe. The agent cannot reach a needed file. Confirm the account, resource, and granted scope. Add only the missing access if the task justifies it; do not immediately replace the connection with an administrator credential. Approval requests interrupt every harmless step. Review whether the product allows a narrower preauthorized workspace or action class. Keep consequential actions distinct instead of disabling all review. A web page tells the agent to change its instructions. Treat the text as untrusted source content. Stop any resulting external action, inspect the activity, and return to the user-authorized task. ## Put it into practice 0 / 5 Use this checklist on your next real task. I mapped each required action to a specific resource.I checked the actual permissions granted by the connection.I placed review before consequential external actions.I know how to stop the run and inspect its activity.I assigned an owner and removed temporary access when finished. Your checklist is saved in this browser. Exercise inputs are not saved. ## Sources & further reading Primary references for the ideas in this chapter. Product behavior can change; check the documentation for the version you use. - [OWASP: LLM prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) Supports the explanation of indirect prompt injection, least-privilege tools, and human oversight of sensitive actions. - [GitHub: Managing personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) Provides a concrete example of resource-specific token permissions and credential expiration. Available controls differ between providers. - [NIST: AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook) Supports assigning governance and managing risk throughout an AI system's use. The access-map exercise is this guide's practical method. Edited October 7, 2026 · Examples are illustrative unless attributed. --- Source: [Give an agent the right permissions | agentlist.io](https://www.agentlist.io/learn/guides/set-agent-permissions). This is the public page rendered as Markdown; interactive controls require the website.