Set Permissions Before AI Uses Your Computer

A year ago, watching an AI tool click around a browser was a demo. In May 2026, it is a checkbox on the pricing page. ChatGPT agent, Anthropic's Claude with computer use, and Google's Gemini 3 Computer Use can all drive a desktop, fill in forms, open files, and chain steps across applications. The capability is no longer the news.

The news is that the useful buying question has changed. For most of the last two years, owners asked us "can the AI actually do the task?" That is no longer the right question. The right question is "what is it allowed to do, who reviews it, and what happens if it goes wrong?"

When the assistant can hold the mouse, permissions become the product.

AI capability is no longer the main cost

It is worth being clear about how far this has moved. ChatGPT agent gives the AI a visual browser, a text browser, a terminal and direct API access, and presents that as a single tool inside the chat window. Anthropic's models can drive a Chrome extension or a virtual desktop and respond to high-level instructions like "find the latest invoice and download it". Gemini's Computer Use sits inside Gemini 3 Pro and Flash and clicks through real web interfaces.

The teams shipping these have all said variations of the same thing. The model can usually complete the task. The hard part is making sure the task it completes is the one you wanted.

For a small business reading the marketing pages, that is a useful filter. If a vendor's demo opens with the agent finishing a long sequence of actions, watch what they say next. The serious vendors then spend a long time on the boring slide: when the assistant pauses, what it asks before sending, and what records it leaves behind. The unserious ones move on to the next demo.

Prompt injection is now a practical risk

The risk that has moved from theory to operational concern is prompt injection. When an AI agent reads emails, browses a supplier site, processes a PDF a customer has uploaded, or picks up text from a Slack thread, it is reading instructions written by people outside your team. Some of those instructions can be hostile.

Anthropic published its own numbers on this earlier in 2026. Without the safeguards in place, Claude for Chrome was successfully manipulated by a hidden prompt 23.6 per cent of the time in their internal testing. With the latest mitigations, that rate dropped to 11.2 per cent. That is a real reduction, and it is also a long way from zero.

The practical translation for a small business is short. As soon as the AI can act on text it did not write, you have a security boundary you did not have before. A hidden instruction inside a customer support email could ask the assistant to forward a file. A line buried in a vendor invoice could try to change a payment record. The assistant does not know it is being attacked, because to the model the malicious instruction looks like part of the request.

This is not a reason to avoid these tools. It is a reason to put limits on what they can do without a person checking.

Set permissions before you buy

When we look at agent products with clients now, we walk through a small set of questions before talking about features or price. They are dull, and they sort the market quickly.

First, what can the agent read. Email, files, the website, a CRM, a payments dashboard. Each new source of input is a new place a malicious instruction could enter.

Second, what can it write or send. Drafting an email is different from sending it. Adding a row to a draft document is different from posting to a public site. Producing a refund proposal is different from issuing the refund. The further from "produce a draft for review" the agent is allowed to roam, the harder the review needs to be.

Third, what does the approval step actually look like. A button labelled "approve" inside a chat thread is not much of a review if the request is summarised in three lines and the actual change is buried in an attachment. The good products show the underlying action, in the underlying system, with enough context to spot a problem before clicking.

Fourth, what record exists afterwards. If the assistant has been given the keys to send messages, post updates, or change data, you should be able to ask, three months later, what it did, when, on whose authority, and from what input. If the answer to that is "we don't keep that", treat it as a serious limitation.

Fifth, what is the rollback path. Some actions can be undone with a click. Some require a phone call to a customer. Some cannot be undone at all. Map them, and decide which categories the assistant is allowed near.

These questions are not a security audit. They are a sanity check before signing.

Match permission to risk and reversibility

The shortest version we give clients is this. Group every action the agent could take into three buckets.

The first bucket is "draft and prepare". Summarise this thread. Pull these numbers. Sort these documents. Suggest this reply. Almost any team can let the AI run unattended in this bucket, because the work goes into a queue for someone to look at.

The second bucket is "act with review". Send this draft. File this expense. Update this record. Anything in this bucket should pause for a person before completion. Even when the team trusts the model, this bucket benefits from the assistant explaining what it is about to change in the same screen as the change.

The third bucket is "act without asking". Anything irreversible, expensive, public, or about a specific person belongs in this bucket. For most small businesses, this bucket should be small or empty until trust is earned through a long run of correct behaviour in the second bucket.

If the vendor cannot help you draw that map for their product, the product is not ready for your business. It does not matter how fluent the demo is.

How we limit AI access in our studio

We run several agents that clock on and do work without anyone watching. They classify inbound enquiries, sort live software errors, draft project summaries, and prepare code review notes. In practice, they all live in the first bucket, with a small foothold in the second. Sending an email, closing a ticket, merging code, refunding a payment: those still go past a person.

The reason is not that the agents are bad at the work. They are often quite good. The reason is that the cost of a single bad action in the second or third bucket is much higher than the cost of a person glancing at a queue once an hour. We design the systems with that asymmetry in mind, because usefulness without limits is not a business system, it is a liability waiting for a Tuesday morning.

Permissions cannot remove every risk

These tools are still moving quickly, and the safety story is not finished. Even the vendors most invested in the area publish papers in which their own agents are tricked by prompts hidden in web pages. Permissions help, but they do not remove the underlying problem that AI tools cannot always tell instructions from data.

For small businesses, that means taking advantage of the capability without trusting it more than the design supports. Use the agents in places where mistakes are visible and recoverable. Keep destructive actions inside a review step. Reread the permissions when you renew the subscription, because the defaults change between releases.

Control access before you automate

If you are looking at an agent product right now, do not start with the demo. Start with the permissions screen. Look at what is enabled by default, what each toggle actually allows, and what the audit trail looks like. The product you want is the one whose permissions match the way your business already decides what to send out of the building. Anything else is a tool you will spend the next year quietly unwinding.

We are happy to take half an hour to walk through a specific agent setup with you, including the boring permissions slide. If the right answer is not to buy yet, we will say so on the call.