agentic AIAI governanceagent identityfinancial servicesSingapore

OpenAI's Dots Can Hold Credentials. Where Does Their Authority Come From?

Arjen Hendrikse · · 7 min read

An AI agent with its own identity, its own credentials and a dedicated role inside your organisation is no longer a thought experiment. OpenAI has tested one internally on procurement and invoice processing, and is now starting pilots with enterprises.

Picture it placing a purchase order with a new supplier on your bank’s behalf. Your internal auditors, and eventually your regulator, will ask a simple question: which system decided the agent was allowed to do that? Unless your bank has designed for that moment, the honest answer will be the rules configured inside OpenAI’s platform.

Identity and access management was built for two kinds of principal. Humans carry accountability. Service accounts do one narrow thing, predictably. The agent OpenAI calls a specialist Dot sits awkwardly in both. Register it as a user and you grant human-scale breadth without human accountability. Register it as a service account and you apply controls designed for predictable behaviour to something that works while nobody is watching and decides its own next step. Microsoft has reached the same conclusion: its Entra platform now treats agent identities as a distinct type, separate from both human users and application identities.

What is actually new

Specialist Dots are the enterprise edge of Dots, the persistent agents OpenAI launched on 29 September. Each Dot runs on GPT-6 Astra with its own cloud computer, connects to more than 4,000 applications, and keeps working after the chat window closes. For the specialist version, the company sets up each Dot with its own identity, credentials and system access. OpenAI has tested specialist Dots internally across procurement, invoice processing, email marketing, customer support and commercial contracting, is now starting focused enterprise pilots, and is working with Microsoft to integrate them with Agent 365. Standard Dots are rolling out to Pro and Business Premium users in eligible markets, and to Enterprise workspaces as a beta that is off by default until an administrator enables it.

Most coverage has focused on what these agents can do. For a regulated institution, the useful question is where their authority comes from, and who can prove it.

The agents already in the building

That question is already live, because the enterprise route is only one way in. Dots are available to individuals on Pro plans, and an employee may connect an always-on agent to work applications and connected information without a procurement process ever starting. OpenAI is also not alone: SpaceXAI’s Grok Bot, launched in August, is available through Cursor subscriptions, a coding tool many engineering teams already pay for.

Shadow IT used to mean unapproved software. Shadow agents can take actions on institutional data using the employee’s own access. Most AI inventories list models and approved use cases. Few list the agents staff have connected to institutional systems, and fewer still can say which actions those agents took.

For senior leaders, this is the most immediate exposure. It requires no vendor contract, no architecture review and no switch in an admin console. Discovery and intake of agents, sanctioned and personal, belongs in the same conversation as the model inventory, starting now.

Reading the controls

OpenAI has published a considered set of safeguards in its privacy, security and safety FAQ. Custom Rules let users decide which supported actions a Dot can take independently, which require approval, and which it should not take. An Activity View shows ongoing and delegated tasks and the steps taken, and lets users correct or halt work. Auto-review “checks certain planned actions against your instructions, Custom Rules, and safety requirements before they run.” The most sensitive actions, such as changing a password or transferring money, require the user to take over, and credentials entered in a secure login form are not exposed to the model. In Enterprise workspaces, administrators can control access to Dots, Custom Rules, cloud computer capabilities, password manager access and the Slack and Teams integrations.

These controls are valuable. They reduce the chance of an agent acting outside its instructions, keep the most sensitive steps with a human, and give administrators real levers. The open questions are about where the controls sit and what they can prove.

Custom Rules are a permission policy evaluated within the vendor’s platform. Their reliability depends on the vendor’s implementation behaving as described through every product and model update.

Auto-review applies to “certain planned actions”. OpenAI’s documentation does not specify how those actions are selected or whether the check is rule-based or model-based. If it rests on a model’s judgement, an action it treats as routine would pass without a second look. That is an inference, and a question worth putting to the vendor before relying on the control for material actions.

The Activity View lets a person see and intervene. Background agents are designed to act when people are not looking, so it works best as a supervisory tool alongside other controls.

OpenAI’s own caution on its next model underlines the point. It has delayed GPT-6.1 Astra, citing concerns about unauthorised behaviour (AP). When the builder of the model treats authorisation as an open problem, the institution deploying the agent should do the same.

The conclusion follows. Vendor controls are valuable safeguards. For a material business action, they should operate alongside the institution’s own mandate, entitlement checks and audit evidence, and those institutional controls should remain the authoritative ones.

Where does the agent’s authority come from? OpenAI safeguards support a procurement proposal, followed by institutional controls: agent identity checked, business limits enforced, approval obtained, and action executed and logged. These controls establish authority, enforcement and evidence.

Three questions before a specialist Dot goes live

Authority. Is the agent’s mandate bounded by the institution’s own systems, or only by rules in the vendor’s console? Microsoft’s Agent 365, once integrated, should place the agent’s identity and application access inside the institution’s own Entra tenant, with a named human sponsor and expiring access. That settles which systems the agent can enter. What it may do once inside, such as the value of a purchase order or which suppliers it can use, still has to be enforced by the business system itself.

Enforcement location. When a rule says “require approval”, is there a control point the institution owns that would block the action if the vendor’s check failed or was bypassed? For an agent connected to thousands of applications, instructions hidden in content it reads remain an obvious failure path.

Evidence. Can the institution reconstruct, from its own records, who authorised the action, what the agent executed, and which constraint applied? If that decision lineage lives only in the vendor’s activity log, the institution’s audit trail changes whenever the vendor’s product does.

A concrete test makes this practical. Take a specialist Dot running procurement. OpenAI’s design already hands money transfers back to a human. The harder cases sit one step earlier: raising a purchase order, amending a supplier record, accepting contract terms. The agent may propose any of these. Whether it proceeds should be decided jointly by the institution’s ERP, its IAM policy for that agent identity, the approval workflow with its own limits, and an immutable enterprise log that records the mandate, the request and the outcome. If the vendor’s rules also flag the action, that is a useful second line. If the vendor’s rules are the only thing standing between the agent and the commitment, the institution has delegated its control environment.

The Singapore context

For financial institutions in Singapore, this lines up with where supervision is heading. In November 2025, MAS consulted on proposed Guidelines on Artificial Intelligence Risk Management for financial institutions. The proposals set expectations on board and senior management oversight, an accurate inventory of AI use cases and systems, lifecycle controls including human oversight and third-party AI management, and testing and ongoing monitoring proportionate to risk.

A specialist Dot touches almost every one of those areas at once. It is third-party AI, it needs to appear in the inventory, and much of its oversight machinery sits with the vendor. The three questions above are a practical way to show senior management that the institution’s own controls hold.

The window

OpenAI says Dots are rolling out in “eligible markets”, and Pro users in the EEA, Switzerland and the UK are excluded at launch. Specialist Dots remain in pilots, and Meta’s comparable agent, Muse, remains limited to North America. None of these restrictions will last long.

Institutions that settle where agent authority is defined, enforced and evidenced before these products reach their environment will make that decision on their own terms. Those that wait will be making it after a specialist Dot is proposed or provisioned.

When the first agent in your organisation receives its own credentials, which system will decide what it is allowed to do?


Arjen Hendrikse is the founder of Aivance, an AI governance consultancy in Singapore focused on the technical implementation of governance frameworks for agentic AI systems.

AH
Arjen Hendrikse
Founder of Aivance Consulting. ISO/IEC 42001:2023 Lead Auditor. Thirty years working at the edge of what technology can do. More about Arjen
This article was drafted with AI assistance and reviewed for accuracy by Arjen Hendrikse before publication. AI Use Policy

Put what you just read to work

If this article raised questions about your own governance posture, the 30-minute Authority & Control Review is the right next step. A written scoping note follows within 48 hours.

Book an Authority & Control Review