By Steven R. Combs, Co-Founder & Principal, Cocha Technology Inc.
An AI assistant that can find a document and an assistant that can send that document to someone are two very different things. The first one reads. The second one acts. Once an assistant can send email, update a customer record, or move a file, a mistake stops being a bad answer on a screen and becomes something that happened.
Take a hypothetical operations coordinator at a regional distribution company. Her manager sets up an assistant to help with order follow-ups. It can read the shared order inbox, look up customers in the CRM, and send emails. One morning a customer asks for an updated delivery schedule. The assistant pulls the right schedule, drafts a reply, and sends it. It also attaches a pricing sheet it found in the same thread, one that was meant for a different customer with different terms. Every step used a permission someone had granted on purpose. Nobody had thought about how those permissions combined.
At Cocha Technology, a Houston-based consultancy focused on AI governance and Microsoft 365 data security for law firms and mid-market organisations, our work centres on setting those boundaries before something like this happens. How you set them depends on the product. Some assistants offer fine-grained controls over each connection. Others give you little more than on or off. What follows is a way to think about the problem that applies whichever tools you choose.
Start from the task, not the tool
Write down the specific job the assistant will do. Following up on late orders is a task. Helping the operations team is not. Once the task is clear, ask what the assistant needs to read and what, if anything, it needs to change in order to do it.
In the example above, the assistant needed to read order status and draft replies. Sending was a convenience. Access to the whole shared inbox, with years of threads involving other customers, was far more than the job required. A narrower version might read only the order system and leave drafts in a folder for the coordinator to send.
Grant what the task needs and nothing more. If the job grows, expand access then, on purpose.
Know what each connector can do
Connectors and integrations are where the gap between reading and acting usually hides. A connection to an email system might allow reading messages, drafting, sending, deleting, or managing calendar invitations, and the setup screen doesn’t always make the full scope obvious. The same goes for connections to file storage, CRMs, and accounting systems.
For every connector, find out which read and write capabilities it grants and whether you can turn individual ones off. Check the vendor’s current documentation rather than relying on the description in the setup screen. If a connector bundles read and write together and the task only needs read, look for another way to do the job.
Also look at whose identity the assistant uses. An assistant acting with a senior manager’s account inherits everything that manager can reach. One acting with a dedicated, limited account is easier to contain.
Put a person in front of sensitive actions
Some actions deserve a pause. Sending anything outside the company, changing financial or customer records, deleting data, and granting access to others are reasonable places to require approval.
The approval has to show the reviewer what will happen. A prompt that asks whether the assistant may send an email is close to useless. The reviewer needs to see the recipient, the full message, and every attachment. For a record change, they need the record, the current value, and the proposed new one. Had the coordinator in our example seen the attachment list before sending, she would have had a fair chance to catch the wrong pricing sheet.
Human approval is a control, not a guarantee. People approve things in a hurry, especially when the requests come all day and most of them are fine. Keep approvals for the actions that matter so reviewers still pay attention when one arrives.
Written instructions to the assistant are not a boundary either. Telling an assistant never to email outside the company may shape its behaviour, but it isn’t the same as removing the permission. Where the risk is real, enforce the limit through account permissions and product settings, and treat the instructions as guidance on top.
Test small before you go wide
Before anyone uses the assistant on live work, try it with a limited account and sample data. Create a test mailbox, a few dummy customer records, and files that look realistic but contain nothing sensitive. Then give it the kinds of requests real users will make, including messy and ambiguous ones.
Watch what it reaches for. If it pulls from places you didn’t expect, or tries actions you didn’t intend to allow, you’ve learned that cheaply. Expand to a small group of real users next, and widen access only after that group has used it for a while.
Keep records and a way to shut it off
When something goes wrong, you’ll want to know what the assistant did, on whose behalf, and when. Find out what activity records the product and your connected systems keep, how long they keep them, and who can see them. If the default logging can’t answer basic questions about what happened, fix that before the assistant takes real actions.
Plan the shutdown too. Someone should know how to disable the assistant’s access quickly, whether that means revoking a connector, suspending the account it uses, or switching off a feature for everyone. Write the steps down so more than one person knows them.
Revisit when anything changes
Permissions that made sense at launch drift. Vendors add capabilities. Someone connects a new system. The coordinator moves to finance, and her assistant setup moves with her into a role with access to very different data.
Treat each of those as a reason to look again. Recheck what the assistant can read and change when a tool updates, when a new connection is added, and when anyone who relies on it changes roles or leaves.
A place to begin
Pick one AI assistant in your business that can already send, edit, or delete something. List every connection it has and, next to each one, write whether it can only read or can also act. Any line marked act that the assigned task doesn’t need is your first permission to remove.