AI and technology

Before Handing Work to an AI Agent: How to Decide Its Permissions

Having AI draft a message and having it actually send or delete things call for different checks. How to break a job into operations, an example of initial permission settings, why instructions alone are not enough, and preparing logs and a way to stop.

Checked 2026.10.133 min read

What you will learn
  • Breaking a job into read, create, change and send-out operations
  • Deciding what to allow at first and what a person checks
  • Why to block actions with permissions rather than instructions, and how to prepare a way to stop

The short answer

Having AI write an email and having it actually send that email call for different checks.

A suggested text can be corrected by a person before it is used. Once a message is sent or something is deleted, however, information reaches the other party or data is lost.

When you introduce an AI agent, decide "how far it may act" alongside "what it can do."

What does an AI agent do?

In this article, an "AI agent" means a setup in which AI calls outside functions to fetch information and carry out operations. The overall mechanism is explained in "What Is an AI Agent?"

Examples include finding candidate times for a meeting, updating a document, or drafting a reply to an inquiry. What it can actually do depends on what it is connected to and the permissions it has been given.

OWASP, an international community project working on software security, publishes a 2025 list of the main risks for applications that use LLMs. In it, the risk of giving more functionality, permissions or autonomy than needed is described as "Excessive Agency."

Break the job into operations

A request such as "I want AI to handle inquiries," for example, contains several operations.

  1. Read the inquiry.
  2. Search internal documents.
  3. Draft a reply.
  4. Send it to the customer.
  5. Update the support history.

You do not need to allow all five at once. You can start by trying only reading, searching and drafting, with a person checking anything that is sent or updated.

Split the job into actions and set a level for each (one example)

Fine to hand over early
  • Read documents (limited scope)
  • Search documents
  • Draft a reply
After a person checks
  • Send to a customer
  • Overwrite an original
  • Update the case history
Not allowed at first
  • Delete files
  • Buy or pay
There is no need to allow everything at once. In practice, decide according to how sensitive the information is and how the work runs.

Example settings at introduction

The table below is one example of how it could be run.

OperationExample initial setting
Read documents in a specified folderAllowed, limited to that target
Draft a replyAllowed
Send to a customerA person checks recipient, text and attachments
Overwrite the originalRun only after checking the changes
Delete filesNot allowed at the initial stage
Make purchases or paymentsNot allowed at the initial stage

Is writing "do not delete" enough?

Instructions to the AI are needed too, but if it must not delete anything, it is important not to grant delete permission in the connected service either.

For example, a connection that only needs to read documents does not need administrator rights that can change every document in the company. OWASP also recommends keeping the permissions given to such connections to the minimum necessary, and having a person approve high-impact actions before they are carried out. How to divide permissions for people is covered in "Stop Making Everyone an Administrator."

A confirmation screen is easier to judge when it shows not only "OK to proceed?" but also the target, the recipient and what will change.

Prepare a way to stop it

Before going live, check the operation logs and how to stop it.

  • Can you trace whose request it was, when, what it read, and where it sent things?
  • Who is responsible for stopping the connection?
  • Can a mistaken operation be undone? Which operations cannot?

When you evaluate how useful it is, include what happens when it gets things wrong, not only when it works correctly.

Checklist

  • Have you split the job into read, create, change and send-out operations?
  • Have you limited what is allowed at first to reading, searching and drafting?
  • Can a person check the target and content before anything is sent or overwritten?
  • Are deletion and payments blocked by permissions in the connected service, not just by instructions?
  • Can you trace the operation logs, and is someone assigned to stop the connection?

These checks help you decide the settings. Having them all in place does not guarantee that mistakes or misuse will not happen.

One thing to check today

Write down the job you want to hand over, split into "read, create, change, send out."