AI agent permissions should separate reading from taking action.

An AI agent permission review needs to say what the agent may read and what it may change. List the actions separately: read, draft, update, send and pay. For each action, name the source, the permitted scope and the person who owns the decision. Those five classes are an evaluation aid; a real system may need a different or more detailed permission model.

Access is a key to the records room. It does not describe which files may be taken out or changed. Before an owner or IT lead approves access to real business data, inspect the action that matters in the intended workflow.

Write the permitted action beside the connection.

Start with one job. For example, a worker preparing a draft response from an approved document needs a defined source and a place to save the draft. A message-sending permission introduces a different destination and consequence. Check whether it is needed at all for that job.

Use the five classes to make those decisions explicit:

• Read: Identify the records and fields the worker may retrieve, and the records it must not see. Check the identity used at the source.
• Draft: Define where a proposal is saved and who reviews it. Inspect whether creating the draft triggers another action elsewhere.
• Update: Name the permitted record and fields. Establish the approval conditions and how the change can be inspected afterwards.
• Send: Specify permitted destinations and the review required before information leaves. Include recipients and attachments in that review.
• Pay: Keep payment execution outside the initial pilot. Any later payment use needs a separately authorised workflow and an isolated test environment.

For each permitted action, record what ends the authority. That might be a revoked connection, a removed role or an expired grant. The mechanism matters because the same user may have more than one route into the system.

OWASP’s excessive-agency guidance distinguishes unnecessary tool functions from excessive downstream permissions and autonomy. It recommends restricting each and enforcing authorisation in the connected system. Use that as a design reference, not as proof that a permission label works. See OWASP’s excessive-agency guidance.

Test a permitted action and a blocked action.

Use synthetic records in an isolated environment with no live recipients, banking connection or production write path. Agree the test with its owner. Choose a task the worker may draft but must not execute.

First confirm that the permitted draft can be produced. Then request the unapproved action inside that isolated fixture. Inspect both the visible response and the source-system evidence. Record the worker, request, decision time and result. A refusal message alone does not show whether an action was attempted elsewhere.

If the permitted task fails too, do not call that a successful permission boundary. The connection may simply be broken. Keep availability failures separate from verified restrictions.

Check revocation on the same route.

After the permitted test succeeds, have the authorised owner remove the relevant access. Retry the same formerly permitted action using synthetic data. Record when access was removed, which identity was used and what happened.

Ask which existing sessions, stored credentials and alternate grants were included. A removed role may not be the only source of authority. If only one route was tested, limit the conclusion to that route.

Revocation of access also does not establish deletion of information already retrieved. Copies in an output, conversation or other destination need their own handling decision. Keep that question in the review rather than assuming a disconnected integration removed every copy.

Does permission to read include permission to send?

The review should make those separate decisions. Check the integration’s actual permissions and the account used to execute the action. A label such as “connected” does not describe every operation available through it.

What should the permission record contain?

Keep the task, worker identity, permitted action, source scope and approval condition. Add the evidence reference, expiry or revocation rule, test date and limitations. Avoid putting credentials or unnecessary customer data in the record itself.

This map is an evaluation aid, not a universal permission standard or a claim that every access path has been disabled. Use the result to decide whether the proposed workflow is sufficiently understood before widening access.

Questions buyers ask.

What are the five permission classes for an AI agent?

Read, draft, update, send and pay. For each one, name the source, the permitted scope and the person who owns the decision. The classes are an evaluation aid, and a real system may need a more detailed model.

Does revoking an AI agent’s access delete the data it already retrieved?

No. Revocation ends the authority on the route that was tested. Copies held in an output, a conversation or another destination need their own handling decision.

For the wider review method, read the CISO evaluation guide for AI workspaces.

Choose one worker’s next task and write down its permitted actions. Open the procurement workbench.

Josh Olayemi · Founder, Handvantage · August 2026