When OpenAI launched its new 'always-on' agents last month, one of its examples was about an invoice. An early tester's agent noticed he'd forgotten to bill a publication, put the invoice together, and sent it once he approved it.
That's useful, absolutely. Most small businesses have an invoice like that sitting somewhere. What stood out to us, though, was the approval step at the end. These agents are built to keep working when nobody's watching, so before you connect one to your email or your store, you need to decide what it's allowed to do on its own and what it has to ask about first.
What OpenAI Announced
At DevDay on September 29, OpenAI introduced dots. Each dot runs on its own cloud computer with its own browser, connects to more than 4,000 apps through OpenAI's plugins, and can be reached in ChatGPT, Slack or Microsoft Teams. OpenAI says they can work toward your goals 24/7.
The DevDay recap had a couple of related items too - team tasks that run on a schedule or start when a new email or Slack message comes in, and computer use in the Agents API, so developers can build agents that operate other software directly.
Dots are rolling out on Pro and Business Premium plans in eligible markets. In Enterprise, Edu and Healthcare workspaces they stay off until an admin turns them on. Most small businesses won't have one running yet, but it's a pretty clear sign of where these tools are heading.
Agents in Business Tools Don't Get a Pull Request
In June, we wrote about AI coding agents moving into the pull request workflow. Coding agents have one big advantage. Their changes come back as a pull request, checks run, someone reads the diff, and nothing goes live until a person merges it.
Email, your CRM and your online store don't have anything like that. Once an email is sent, it's sent. A refund leaves your account the moment it's issued, and an overwritten CRM record may not have any history to roll back to. If an agent gets one of these wrong, you will probably hear about it from a customer.
OpenAI has built some controls into dots for this. You can set Custom Rules to allow an action, require approval for it, or block it. An auto review step checks anything that could affect your accounts or share information against your instructions, and some things, like changing a password, are always left to the person. OpenAI also says plainly that dots can still make mistakes and that you should review consequential work.
Those controls only help if someone sets them up properly, though. The defaults are built for every customer at once, and they don't know which actions are risky in your business.
What Security People Call This
OWASP, the group behind the well known web security Top 10, also publishes a list for AI applications. In the 2026 edition, excessive agency moved up to third place, from sixth the year before, as more AI apps were given tools to act with.
OWASP traces it back to three causes:
- Excessive functionality, where the agent has tools it doesn't need, sometimes ones that were tested once and never removed.
- Excessive permissions, where the tools it does need can reach more than they should, usually because they're connected through an account with broad access.
- Excessive autonomy, where high-impact actions go through without anyone checking and approving them first.
Their example happens to be about email. If an assistant only needs to read mail, give it a tool that can only read, connect it with read-only access, and have a person look over anything it drafts and hit send themselves.
The agent doesn't have to malfunction for this to go wrong, either. Prompt injection, where instructions are hidden in content the AI reads, is still number one on the same list, and an agent that reads your inbox also reads everything strangers send you. OpenAI says dots include safeguards against malicious instructions. The UK's National Cyber Security Centre, in its August interim advice on agentic AI, cautions against relying only on safeguards built into the model when the stakes are higher.
Before You Connect One
This part is mostly business decisions. Someone who knows how things run should spend an hour on it before the agent gets switched on.
Reading vs. changing
An agent that can read your inbox and one that can send from it are very different risks. OpenAI uses this split in dots too - when a dot works in the background on its own, its app tools are read-only and can't send messages or change content. We'd start any agent that way and add write access for specific tasks once you've watched it work for a while.
What needs approval
For most businesses, anything going to a customer, anything that moves money, deleting records, sharing files outside the company, and changing who can access what. If the tool supports approval rules, set them for those on the first day.
Which account it uses
Setting an agent up with the owner's login is quick, and it also means the agent can do anything the owner can. That's the excessive permissions problem from OWASP's list. If your tools allow it, give the agent its own account with only the access it needs. OpenAI sets up its specialist dots for organizations the same way, each with its own identity, credentials and access to specific systems.
Seeing what it did
Dots have an Activity View, and most agent tools have something similar. Someone should actually look at it. The NCSC recommends logging and monitoring agent activity as part of normal security operations, and making sure the agent's actions can be told apart from a person's. If nobody can easily answer "what did the agent change this week", fix that before giving it more to do.
Stopping it
The NCSC also stresses being able to stop an agent quickly and having named people responsible for it. For a small business, that might just mean deciding who's allowed to pause it and making sure they know how.
While you're at it, sort its actions into ones you can undo and ones you can't. You can delete a draft or unsend an email. Anything in the second group belongs on the approval list.
Connecting AI to Your Business Tools?
We can help you decide what an AI agent should be allowed to touch, set up the approval points and logging, and build the integrations so it fits the systems you use.
Where We'd Start
Start with the dull stuff only. Summarizing what came in overnight, drafting replies that a person sends, flagging overdue invoices, pulling together a weekly update from tools you already use. They save time, they're mostly read-only, and a mistake doesn't become a total disaster.
That's close to what the NCSC said in its earlier guidance on adopting agentic AI, which Infosecurity Magazine summarized as starting small, applying the governance you already have, and planning for failure. The guidance also says an agent whose actions you can't understand, monitor or contain "is not ready for deployment", which is a reasonable test to run before connecting anything.
After that, add one permission at a time. Let it send one kind of message or update one kind of record, keep an eye on the activity log for a few weeks, then decide on the next step.
If you're building agents into your own products or internal tools, it's the same list, just earlier in the project. Narrow tools, scoped credentials, approval steps for anything that can't be undone, and logging from day one are much easier to build in at the start than to add later. It's the kind of planning our AI and ML automation team can help with.
