Pin down the task before you touch permissions

If someone asks for an agent to "help with customer accounts", I can't work out what access to give it, because that could mean almost anything. Searching support notes, reading billing status, drafting a reply, changing an account and issuing a refund all touch different systems, and getting one of them wrong costs a lot more than getting another wrong.

So I'd start by writing the task down as one piece of work you could watch happen. Something like: take one support case, pull the account records linked to that case, compare them with the current policy, draft a proposed response and stop for review. That description should say what goes in, which sources the agent is allowed to use, what it hands back and where it stops.

Once you've got that, the permission review has something real to look at. For each step I'd ask:

• Which system holds the information?
• Does the agent need a whole collection, or one record picked out through the task?
• Is the content enough, or does it also need metadata like owner, date or status?
• Is the agent preparing an action, or actually doing it?
• What happens if the record is missing, ambiguous or restricted?
• Who's accountable for approving the final action?

Write down what the task excludes, too. Maybe that's closed cases, legal correspondence, payment details or records from another business unit. Those are operating boundaries, so I'd enforce them in the tool and identity layers instead of leaving them as a line in the prompt and hoping the model sticks to it.

When that one task works with narrow access, you can look at the next task on its own terms. If you bundle a few of them into a general "assistant" role, later reviews get hard because nobody can tell which permission is there for which job.