An agent with its own login is a hire, not a tool
OpenAI's dots arrive with their own identity, credentials and a permit, require-approval, block rule per action. That makes the pilot an onboarding decision, and here is how to run one.
Koundinya Lanka
Enterprise AI
OpenAI shipped dots on September 29. Each one runs on its own cloud computer, connects to over 4,000 apps through plugins, and does research in the background with tools that are restricted to read-only ([Introducing dots](https://openai.com/index/introducing-dots/)). The version built for companies, which OpenAI calls specialist dots, comes with its own identity and credentials, custom approval workflows, and governance through Microsoft Agent 365. The named pilot applications are procurement, invoice processing, email marketing, customer support and commercial contracting.
I read that list twice. Those are not tooling decisions. Procurement and commercial contracting are the two functions where a wrong action costs real money and a long apology. Something that arrives with its own credentials and does that work is a hire, and the pilot should be run the way you would onboard one.
What OpenAI actually shipped for control
Four things, all from the announcement. Custom Rules let you allow specific actions, require approval for them, or block them. An Activity View shows progress, including the background work. An auto-review decides what work can proceed, what needs approval, and what you must do yourself. And certain sensitive tasks, the example given is changing a password, always stay with the human. Business, Enterprise and Edu workspace content is not used to improve the models by default ([Introducing dots](https://openai.com/index/introducing-dots/)).
That is a per-action permission model shipped by the vendor. I have spent a year arguing that AI earns decisions task by task, with an evidence gate at each step, and most of that argument was about things we had to build ourselves around a model that only knew how to answer. Now the three settings are in the product: block, require approval, permit. The gate is there. What the product cannot tell you is when an action has earned the move from require approval to permit. That part is still yours.
Key Insight
The hard decision in a dots pilot is not which actions to block. It is what evidence moves one action from require approval to permit, and who signs that move.
The onboarding frame
When a new analyst joins a procurement team, nobody argues about whether they get a login. The argument is about what the login can do on day one. They can read the vendor master. They can draft a purchase order. They cannot approve one, and they cannot change a bank account on a supplier record, and that stays true until someone with authority has watched enough of their drafts to sign off on more. Every company already has that playbook. It is called access control and probation, and it has an owner.
A specialist dot with an identity and credentials fits that playbook with almost no translation. Day one is read-only, which OpenAI already enforces for background research. Drafting is require approval. Approving anything, or changing a record of money or identity, is block until it is earned. The people who should set those rules are the same people who set them for the analyst, not the AI team. If the pilot is being run by the people who chose the vendor rather than the people who own the process, that is the first thing to fix.
How I would run the pilot
- 1
Start every action at require approval
Not just the risky ones. All of them, including the ones that look harmless. The point of the first month is to see what the agent reaches for, and you only see that if every reach shows up in a queue.
- 2
Treat Activity View as the audit trail, and export it
The Activity View is where background work becomes visible. Decide on day one who reads it, how often, and where a copy lives outside the vendor's product. An audit trail you can only read inside the tool is not an audit trail your auditor will accept.
- 3
Define the count before you start
For each action, write down how many clean approvals in a row move it from require approval to permit, and what a clean approval means. Twenty invoice drafts matched to purchase orders with no edits is a number. 'When we're comfortable' is not, and it is how approvals quietly turn into rubber stamps.
- 4
Promote one action at a time
When an action hits its count, move that action, and only that action, to permit. Record who moved it and the evidence they looked at. The Custom Rules file is now a controlled document with a change history, the same as a role in your identity system.
- 5
Keep the human-only list honest
OpenAI keeps password changes with the human. Add your own: anything that moves money, changes a supplier's bank details, commits the company in a contract, or touches an employee record. Those stay at block until a named executive decides otherwise, in writing.
- 6
Re-read the rules every quarter
Models change and the agent's plugins change. An action that earned permit on one model has not earned it on the next. Put the rule review on the same cadence as your access reviews, because that is what it is.
The approval queue is where this breaks
I run my own small set of agents and the approval step was the first thing that broke. Not the model. Within two weeks I was approving without reading, because almost everything in the queue was fine, and a queue where almost everything is fine trains the reviewer to stop looking. That is the real risk of a require-approval default with no promotion rule behind it. The approvals become theater, the agent is effectively on permit for everything, and nobody decided that.
The fix is the count. If an action has twenty clean approvals, promote it and get it out of the queue, so the queue only holds things that still need a human. A short queue of real decisions gets read. A long queue of confirmations does not. This is the same reason pilots stall for nine months in the first place: the gate exists but nobody defined what passing it looks like ([why AI pilots fail in production](/blog/why-ai-pilots-fail-production)).
What changes in the contract
Three things need to be on paper before a dots pilot turns into production, and none of them are in a standard SaaS order form. First, per-action liability: when an action on permit is wrong, the contract should say whose problem it is, and the honest answer is that it depends on whether the action was promoted with evidence or by default. Second, the training exclusion. Workspace content is excluded from training by default today; a default is not a term, so write the term. Third, the commitments. OpenAI also announced a marketplace where enterprise customers can apply existing commitments toward approved partner software ([DevDay 2026 recap](https://openai.com/index/devday-2026-recap/)), which is convenient and also means software bought that way inherits the scope, renewal and exit terms of your OpenAI agreement unless you write otherwise.
If you have already rewritten your AI SOWs for model deprecation and model repricing, this is the third clause set, and it uses the same machinery: name the condition, name the evidence, name who signs ([the three SOW clauses model deprecation made mandatory](/blog/ai-delivery-sow-model-deprecation-clauses), [three model price moves in one week](/blog/model-price-moves-ai-sow-pricing-clauses)).
Action Checklist
0 of 8 complete
Where this leaves the operating model
For a year the operating model work on AI programs has been about building gates the vendors did not give us. Dots ship with the gates. That moves the work, it does not remove it. The decisions that were hard before are the same ones that are hard now: what counts as evidence, who signs, and how you keep a queue of approvals from turning into a habit. The product gives you the three settings. Deciding when an action has earned the next one is still a person signing their name, and the pilot is only real once you know whose name that is.
Frequently asked questions
Should we turn on dots for the whole company?
No. Pick one team and one or two of the pilot applications OpenAI itself named, such as invoice processing or procurement. Keep every action at require approval for the first month. Expand by action, not by headcount.
Who owns the Custom Rules?
The same person who owns the access review for a new employee in that function, usually the process owner with security signing off. If nobody can name that person, the pilot is not ready. The rules are an access-control artifact and should be versioned and reviewed like one.
What goes in the contract before the pilot becomes production?
Three things at minimum. Which actions the agent may take alone and who is liable when one of those actions is wrong. Confirmation in writing that workspace content is excluded from training, since the default can change. And how any marketplace or partner software bought with existing commitments is scoped, renewed and exited.
Koundinya Lanka
Founder of The Production Line. Strategy & Operations leader at Brillio, a Bain Capital portfolio company, on enterprise AI. Berkeley Haas EMBA '27.
Enjoyed this article? Get more like it every week.