Define the task before the permissions

A request such as "help with customer accounts" is too broad to authorise. It could mean searching support notes, reading billing status, drafting a reply, changing an account or issuing a refund. Those actions use different systems and carry different consequences.

Write the initial task as an observable unit of work. For example: receive one support case, retrieve the account records linked to that case, compare them with the current policy, draft a proposed response and stop for review. The task definition should name its inputs, permitted sources, expected output and stopping point.

This gives the permission review something concrete to inspect. For each step, ask:

• Which system contains the required information?
• Does the agent need a whole collection or one record selected through the task?
• Is content enough, or does it also need metadata such as owner, date or status?
• Will the agent prepare an action or execute it?
• What happens when the record is missing, ambiguous or restricted?
• Which person is accountable for approving the final action?

The task should also have exclusions. It may exclude closed cases, legal correspondence, payment details or records from another business unit. These are operating boundaries, so enforce them in the tool and identity layers rather than leaving them in a prompt.

Once the single task works under narrow access, adjacent tasks can be assessed separately. Bundling them into a general assistant role makes later review difficult because nobody can tell which permission exists for which job.