Give an agent the right permissions

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.

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.

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.