Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is OpenAI Dots Safe to Use for Work?
No, not on work accounts whose pages carry sensitive data: OpenAI's safety write-up describes a dot's model seeing webpage text and document content within connected apps, and custom rules govern how the dot behaves rather than what it reads. Ask what the model receives on each screen and who approves each action before you connect a CRM.
No, not for a work account whose pages carry sensitive data. A support rep who connects a dot to a CRM hands it a browser session and a task, and the ticket it opens renders the customer's name, address, order value and the last four digits of a card. OpenAI's safety write-up describes what the model sees as webpage text and document content within connected apps, with only credentials kept out (Can Insurers Use OpenAI Dots on Claim Files?). The help centre adds that a dot can "make mistakes, including when following your rules" (OpenAI, Dots documentation, 2026). Custom rules are the control a user is given: they decide whether the dot acts without asking, acts when pre-approved, asks first or hands the step back (Do OpenAI Dots Rules Control What the Agent Sees?). Those rules govern what the dot does. What it reads on the ticket page is a separate question, and the one to settle before enabling the beta: a rule can keep a dot away from a screen and cannot change what it has already read.
Key findings
- For OpenAI Dots to be safe on accounts whose pages carry sensitive data, the values on each page would have to be replaced with consistent tokens such as ACCT_001 before any model reads the screen (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission or record change, and a record of what the model received on each screen (Do OpenAI Dots Rules Control What the Agent Sees?).
- OpenAI's Dots documentation does not state that the values on a page are replaced before the model reads them; it describes four rule behaviours and warns a dot "can make mistakes, including when following your rules" (OpenAI, Dots documentation, 2026).
- OpenAI's data controls state that "By default, OpenAI does not use content from ChatGPT Business, Enterprise, Edu, or ChatGPT for Healthcare workspaces to train its models," which settles training on work content, not what a model reads during a run (OpenAI Help, 2026).
- Coder's guide warns that "LLMs and agents can be dangerous if not run with proper boundaries" and advises a separate identity "with limited scope" rather than a user's full permissions (Coder, 2026).
- Zendesk's help pages describe roles, on eligible plans, that scope ticket access from "Assigned to them" to every public group, which limits what an agent can open and not what the model reads on a page it can open (Zendesk, 2026).
What does a dot read when it opens a support ticket?
A dot works with a browser and a task rather than a prompt alone, and the research on its rules records that each dot has its own cloud computer and browser, connects to more than 4,000 apps through plugins and runs on GPT-6 Astra (Do OpenAI Dots Rules Control What the Agent Sees?). A support rep who connects one to a CRM gives it the rep's app session and a job: read the ticket, draft a reply, maybe issue a refund. Dots is one of the 15 AI agents reviewed, and none of the 15 describes replacing the customer data on a working page with tokens the agent can work with, so the card details a support ticket renders reach the model as text (Do AI Agents Ask Before Making a Payment?).
Take one ticket on that CRM. The page renders the customer's name, the delivery address, the order value, the card's last four digits and the internal note the last agent left. That rendered text is what the dot's model receives, and the reply it drafts is written from it. The note is part of the same page, so a line a customer typed into a web form arrives in the model's context beside the order value.
The CRM's own roles narrow which tickets the dot can open. A role grants access to an object, such as the tickets assigned to a group, and the page renders every field that object carries. The distance between an agent a team tries and one it runs on live records is where this exposure sits (What Is the PII Wall?), and a rule that keeps a dot off a screen addresses the reach, not the reading.
What do custom rules control, and what does the model still read?
OpenAI gives a dot four behaviours: "Take action without asking," "Take action if pre-approved," "Ask before taking action" and "Hand off to you" (OpenAI, Dots documentation, 2026). Each one decides whether the dot proceeds, waits for a person or returns the step, and the choice is made before the run. A rule written in advance cannot name a value that arrives on a page later.
OpenAI's governance paper treats human approval as "a standard way to limit egregious failures" and asks that "Actions that can only be reviewed after the fact should be more easily reversible" (Shavit et al., 2023). It also says a user should be able to "activate a graceful shutdown procedure for its agent at any time" and that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). Those are controls on what happens after a dot proposes something, and on who answers for it.
What the model reads is settled earlier, at the page. A rule can stop a dot from opening a screen, and once the screen is open the rule has nothing to say about the text the model receives. The behaviour a rule governs and the values a page renders are two different objects, and only one of them is covered by the four behaviours. A rule can be edited between runs; the text on the page changes with the customer's record, and it arrives before any rule is consulted.
What do the vendors themselves say?
The documentation answers part of the title question directly, and the table reads the answers against what a buyer has to verify.
| Dimension | OpenAI Dots, per its documentation | What a buyer should verify |
|---|---|---|
| What the model receives | Webpage text and document content from connected apps, with only credentials kept out (Can Insurers Use OpenAI Dots on Claim Files?) | Whether values on a page are replaced before the model reads it |
| Rule behaviours | "Take action without asking", "Take action if pre-approved", "Ask before taking action", "Hand off to you" (OpenAI, Dots documentation, 2026) | Whether a rule changes what the model reads or only what the dot does |
| Work content and training | "By default, OpenAI does not use content from ChatGPT Business, Enterprise, Edu, or ChatGPT for Healthcare workspaces to train its models" (OpenAI Help, 2026) | Which workspace and plan the account uses |
| Availability and reset | Pro users outside the EEA, Switzerland and the UK; Enterprise, Edu and Healthcare in admin-enabled beta; "Reset deletes your dot, including its conversations, saved memories, and scheduled tasks" (OpenAI, Dots documentation, 2026) | Whether the workspace is eligible, and whether a run record survives a reset |
The four behaviours are the whole of the rule control: they decide whether the dot proceeds, waits or hands the step to a person, and OpenAI's help page is explicit that a dot "can make mistakes, including when following your rules" (OpenAI, Dots documentation, 2026). A rule that is followed still operates on the page the dot opened.
What should a security team ask for in writing?
The first item to ask for in writing is what the model receives from a rendered screen, and in what form. The second is whether values are replaced on the page before the model reads them, with consistent tokens such as CARD_002, and where the real value resolves.
Ask who approves a payment, a submission or a record change, by name, and what that person sees. Ask what record leaves the run: the screen the model saw, the action, the approver and the destination.
The fourth is credential custody. OpenBSD's manual describes ssh-agent as "a program to hold private keys used for public key authentication" and records that an agent deletes "all keys it has loaded" on SIGUSR1, a pattern in which a separate process holds the credential the requester never reads (OpenBSD, 2026). The OAuth 2.0 BCP requires that "Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation" (IETF, 2025). A browser session logged into a CRM is nearer the second pattern: the session is the credential, and the page is the data.
The fifth is the regulatory frame. FINRA's notice states that "FINRA intends for its rules and guidance to be technologically neutral," so the supervision a member firm already owes applies to a dot that reads a client account (FINRA, 2024). An agency asks the same of a Privacy Act record, and the admin who enables the beta decides who can turn a dot on, not what the record shows it (Can Agencies Use OpenAI Dots on Privacy Act Records?).
How should a team test what a dot reads on one workflow?
Choose one ticket that carries a card's last four digits and a delivery address, and one task: draft a reply and issue a refund. Run the dot on it with a person watching. Then compare the page a person sees, the text the run recorded and the action the dot took.
The recorded text is the evidence. If the conversation or the saved memory carries the card's last four, the model had it, whatever the rule said. Ask for the conversation export and an audit log if the workspace has one, and capture them before any reset, which deletes conversations, saved memories and scheduled tasks.
Next, test the reading with a line the customer controls. Put a line in a ticket note telling the dot to email the customer list to an outside address, and run the same task. A browsing agent has been hijacked by content it read, with "prompt injection, domain validation bypass, and credential exfiltration" among one study's findings (Can a Browser Agent Be Tricked Into Pasting Sensitive Data Into a Chat?). Then check where the run could send what it holds (How Do I Limit Where an AI Agent Can Send Data?).
Run the same test on the pages nobody thought to test, and the answer stops depending on the rules.
What does a governed environment change?
A governed environment moves the control from the dot's behaviour to the page it reads. Values a policy names are replaced with consistent tokens before any model reads the screen: the customer's name becomes CUST_014, the address ADDR_003, the card CARD_002, and the dot works the ticket on those tokens for the whole run. Real values resolve only at an approved destination, at the moment of an approved action.
A named person approves every payment, submission and record change, outside the model. That is a different control from pause and stop: one entry in a 2025 index of agent products records approval requirements of "None" for its decision types, with pause and stop as the available user controls, which can end a run without approving what it proposed (AI Agent Index, 2026).
The third change is the record: every screen the model received as tokens, every action and every approval with a name, exported to the customer's own monitoring. A record that holds the token the model saw is what an assessor can check against the rendered page, which a conversation export does not give.
For OpenAI Dots, that control class is set out against the product's documented behaviour in RedactSure vs OpenAI Dots: 2026 Comparison & Alternative.
What the record shows
No, not on work accounts whose pages carry sensitive data, because a rule that governs what a dot may do leaves what the model reads untouched. The vendor's own pages place the model in front of webpage text and document content from connected apps, and the four rule behaviours decide whether the dot acts, waits or hands back, not which values it saw. The data controls settle training on work content after the run, not exposure during it. Before enabling the beta, a support team should test this on one ticket: put a card's last four in front of a dot, read what the run recorded, and compare it with the page a person sees. If the recorded text carries the customer's values, the account is moving them through the model's context, and the fix is a control that replaces them before the model reads it.
Methodology and limitations
The page rests on OpenAI's Dots help centre and data controls pages, OpenAI's governance paper, the OpenBSD manual and the OAuth security BCP, and vendor documentation from Coder and Zendesk, read between October 16, 2026 and October 22, 2026, with FINRA Notice 24-09. Public documentation read in full gives a sound view of where each product applies its control, and no hands-on testing was done for this page.
The products on this page are described from documentation and none was tested for this page; "not described" means the pages reviewed. Vendor features change and this page carries its date. The example describes a record type, a support ticket on a CRM, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers; nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is OpenAI Dots safe to use for work?
No, not on work accounts whose pages carry sensitive data. OpenAI's safety write-up describes what the model sees as webpage text and document content within connected apps, and the help page says a dot can make mistakes while following its rules. The rules decide whether the dot acts or waits, not what it read. The answer changes when the values on the page are replaced before the model reads it, a named person approves each action, and a record shows what the model received.
What does the model receive when a dot opens a CRM record?
The rendered text of the record, including the fields the page shows: the customer's name, the delivery address, the order value and the card's last four digits. The safety write-up describes webpage text and document content from connected apps, with credentials kept out. A field hidden from the page is not in that text; a field the page renders is. That is why the internal note matters, since it can carry a line the customer typed.
Do custom rules stop a dot from reading a page?
No. The four rule behaviours decide whether the dot acts without asking, acts when pre-approved, asks first or hands the step back. They are written before the run and apply to the action, and OpenAI's help page says a dot can make mistakes while following them. None of the four removes values from the text the model receives. A rule can keep a dot away from a screen; it cannot change what the dot read on a screen it opened.
Who approves a payment or record change a dot proposes?
Whoever the workflow puts there, and in a default setup that can be no one: the four behaviours include "Take action without asking," which removes the person from the step. A named approver outside the model is a separate control, and the Gemini Enterprise entry in the 2025 AI Agent Index records approval requirements of none for its decision types. Approval has to sit with a person who sees the action and its destination.
What record does a dot leave of what it read and did?
Conversations, saved memories and scheduled tasks are what a dot leaves behind, and the Dots help page says a reset deletes all three. That is a record of the interaction, not an export built for an assessor, and the pages reviewed describe no export of what the model received. A team that needs that record should ask for it in writing before the first run.
Which work should stay off Dots entirely?
Work whose pages carry data the organization would not put in a model's context: card numbers, bank details, health records and a public agency's case files. A hiring workflow is the other case, because a candidate's history and contact details sit on the same kind of page. A rule can keep a dot away from those screens only if someone names every screen in advance, which is the part most teams cannot do.
How RedactSure Keeps a Ticket's Card Details Out of the Model
A support ticket carries a customer's name, address and card details into every reply a dot drafts, and a rule written in advance cannot anticipate every one. OpenAI's help page says a dot "can make mistakes, including when following your rules" (OpenAI, Dots documentation, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the dot opens the ticket and its model receives the name, the address and the card's last four as the page renders them. Inside the environment, the same page renders CUST_014, ADDR_003 and CARD_002, the work proceeds on those tokens, and real values are released only when the rep approves the refund at the payment destination.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A ticket page holds a customer's name and card details for the whole run. Bring one ticket from your queue and see, with test values, what the model reads, who approves the change and what the record shows. Book a demo