The ChatGPT Work Data Plugin: A Client Readiness Checklist for Agencies

On September 10, 2026, OpenAI announced that everyone can connect their own data to ChatGPT Work. The wording is flat and deliberately unremarkable: “Now everyone can put data to work… Just add the Data Plugin in ChatGPT Work, connect to the data sources and context you already use, and start the conversation.” Our own earliest verified artifact from that day is OpenAI’s demo video, uploaded at 11:07 a.m. ET.

The reason this matters to an agency is not the connector list. It is that a plugin toggle moves the client conversation from “should we use AI on our data” to “what do we have to fix before we let it.” The first question is a software purchase. The second is a readiness engagement, and it is billable whether or not the client ever turns the plugin on.

Below is the checklist we run with a client before anything is connected: what shipped, what to inventory, how permissions actually resolve, who approves an action, what is (and is not) logged, and the list of sources that should stay unconnected even when the plugin can reach them.

What actually shipped on September 10, 2026

The Data Plugin is not a new model or a new product line. It is a connection layer inside ChatGPT Work that reads from systems the client already runs and writes back into the reporting tools they already open. Two halves matter, and they carry different risk.

OpenAI describes the action surface in its own words: the agent can “recommend next steps and identify who needs to be involved… share the findings through Slack or email and carry out the actions you approve through connected tools.” That is a read-analyse-act loop, not a chat window. It is also the sentence that should drive the entire engagement, because the approval in it is an undefined human input.

Before you connect: the client data-source inventory

Do this on a call, not by email. Walk the client through every system the plugin can reach and record four things per source: who owns it, who administers it, which identity a connection would use, and whether it is in scope for a pilot or out of scope entirely. If nobody can name the owner, that source is out of scope by default.

1. Warehouse and lake. Snowflake, BigQuery, Databricks, Amazon Redshift, ClickHouse. Ask which databases inside each one are actually business data and which are staging copies nobody curates.
2. Operational and observability. MongoDB for application data; Datadog for telemetry. Telemetry routinely contains customer identifiers and internal hostnames — it is the bucket clients forget.
3. File stores. Google Drive and SharePoint. This is where the real problem usually lives: folders with inherited sharing, personal drives, and contract or HR material alongside the marketing plan.
4. Semantic and code context. dbt, GitHub, Snowflake Horizon, Databricks Genie Ontology. This is the metadata tier. It is low-risk to read and high-value to connect, because a semantic layer is what stops the agent guessing at column meanings.
5. The BI estate. Power BI, Tableau, Sigma, Omni, ThoughtSpot, Oracle BI. This is the write surface. Every one of these needs a named approver before it is enabled, not after.

Two questions expose most of the inventory risk before you look at any permission screen: which of these systems is the copy of record, and which are copies of the copy? Duplicated sources of truth are what make an agent’s answer confidently wrong, and the Help Center guidance that a semantic layer is “strongly recommended” is the vendor saying the same thing more politely.

Who can read, who can write: mapping plugin scopes to the client’s existing identity

OpenAI’s permission model is published, and on its own terms it is coherent. Administrators choose which connections exist and which roles get them, from Workspace settings > Plugins, using the workspace’s existing role-based access control. Plugins can be available or pre-installed, and installing a plugin is explicitly not the same as granting access to the apps behind it.

The load-bearing line is this one: “Queries enforce the connected account’s existing permissions, including table, row, and column restrictions.” Paired with “a successful connection does not create additional source permissions,” that means the plugin cannot widen what the client’s own accounts can already see. Which also means the agent’s ceiling is exactly the ceiling of whichever account the connection runs as.

And that account is usually the wrong one. Service accounts and integration identities tend to be provisioned for throughput — a single credential that has to reach every dashboard and every table — not for least privilege. So the permission map is less about ChatGPT and more about auditing the identity you are about to hand it.

Who approves an action — and why “the agent asked me” is not a control

OpenAI notes that actions depend on the connected tool’s supported actions, the user’s permissions, and any approval requirements. What is not published is who the approver should be, or what size of action needs one. There is no named approver role and no write threshold for this agent. That is a gap the client has to fill in writing, and filling it is a deliverable you can charge for.

The rule we put in front of clients is deliberately blunt: one named human approver per write class, no unattended writes, and every approval recorded somewhere that is not the chat. “The agent asked me and I said yes” leaves no artefact, cannot be reviewed after the fact, and collapses the moment someone is on holiday.

1. Define write classes first. Refreshing an internal dashboard is a different class of action from posting findings into a client-visible Slack channel or emailing a summary to a distribution list.
2. Name one approver per class. A person, not a team alias. Their name goes in the runbook next to the class they own.
3. Keep one class that can never run unattended. Anything that leaves the organisation or changes a number someone else reports on stays behind a human.
4. Record approvals outside the tool. A ticket, a log line, a weekly review — anything durable and inspectable.
5. Plan for approval fatigue. When every action needs a click, people start clicking. Set a volume threshold at which the class moves to scheduled batch approval instead of per-action prompts.

What gets logged, where it lives, and for how long

This is the part of the checklist where the honest answer is “the vendor has not published one.” We measured it rather than assumed it: across OpenAI’s announcement page and the Help Center article on the Data plugin, the words audit, residency, log retention, training on connected data, encryption, prompt injection and DLP each appear zero times. No audit trail and no retention commitment is published for this agent.

Read that correctly. It is an absence of a published commitment, not evidence that no controls exist, and it is not a reason to call the product unsafe. It is a reason to make the logging question a contract question with the client and their other vendors, because the agent will be acting inside systems that already have their own logs.

1. Require the action log from the connected tools first. Tableau, Power BI and the rest log who changed a dashboard. Confirm the approval produces a row there before you rely on ChatGPT to tell you what happened.
2. Ask the retention question in writing. How long does a conversation that touched client data persist, who can retrieve it, and what is the deletion path on offboarding.
3. Account for the second copy. The Help Center states that analysed data “is copied into the published site.” A dashboard or published answer is a copy that lives outside the source system’s permission checks — so say where it lives and who can open it.
4. Treat implicit triggering as the default case. @Data is optional in the Help Center’s own description, so a normal question can reach connected data without anyone invoking the plugin by name. A per-prompt opt-in is not your control; the enabled connection list is.

The never-connect list

This list is ours, not OpenAI’s. It exists because “the plugin can reach it” and “the plugin should reach it” are different sentences, and the second one needs a human decision that survives staff turnover.

1. Regulated health and financial records. Anything under a compliance regime the client cannot re-paper in a week: patient data, payment instrument data, regulated lending or advisory records.
2. HR and PII-dense stores. Employee files, payroll, performance notes, candidate pipelines, customer contact databases with identity documents attached.
3. Single-source-of-truth ledgers. The one system whose numbers are the numbers — the general ledger, the billing system of record, the production inventory table. Read access to a copy, never the primary, and never write.
4. Secrets and credential stores. Vaults, key stores, CI secrets, connection strings. If the agent can read them, a prompt-injection path becomes a credential path.
5. Anything unowned. A source with no named owner and no named admin is out of scope until it has both — this is the rule that quietly removes the worst folder in the client’s Drive from the pilot.

Is it safe to connect company data to ChatGPT?

Not on the strength of anything published about this plugin, and not as a binary question. The permission half is published and it is coherent — queries inherit the connected account’s existing permissions, and connecting does not create new ones — but the audit trail, the retention period, the residency answer and the approval control are not published, so safety here is a design decision the client makes, not a setting they toggle.

Three things are true at once, and a client conversation that holds all three is the one that ends in a scoped engagement:

1. What is published: admins choose connections and roles, queries enforce the connected account’s existing table, row and column restrictions, a successful connection adds no new source permissions, and installing a plugin is not the same as granting app access.
2. What is not published: audit, log retention, residency, encryption, prompt-injection handling, DLP, training on connected data, a named approver role and a write threshold. Not published is the accurate description; “does not exist” is a claim we cannot support.
3. What the client controls regardless: which sources are enabled, which identity each connection uses, whether implicit triggering is acceptable, which human approves each write class, and where approvals and action logs are kept.

Two honest notes on the question itself. First, we are not claiming to be first: an enterprise-framed governance analysis of this launch was published on September 10, 2026 by explainx.ai, covering the permission model, service-account breadth, injection and approval fatigue. What is still thin is the small-business and agency version — the data-source inventory, the never-connect list and the approval rule a ten-person client can actually operate. Second, the query itself is largely unclaimed for this product: across the twenty results we pulled for this question, none mentioned the Data agent at all.

The scoped engagement: deliverables and the first two weeks

Sell this as readiness, not as a software rollout. The deliverables do not depend on the plugin being enabled, and the client leaves with artefacts they need for every AI vendor they will evaluate next year.

Six deliverables

1. Data-source inventory — every reachable source with its owner, admin, business purpose and in-scope or out-of-scope status.
2. Permission map — the connected identity per source, its row and column restrictions, and the delta between what it can reach and what the pilot needs.
3. Connected-identity audit — the service accounts and integration logins in play, with a least-privilege target for each and a replacement list for shared credentials.
4. Approver matrix — write classes, one named approver each, the no-unattended-writes class, and the approval record location.
5. Never-connect list — signed off by the client, with the reasoning, so it survives the next change of staff.
6. Readiness sign-off and rollout gate — what must be true before the first connection, and who signs it.

The first two weeks

1. Days 1–2: run the inventory call. Capture owners and admins for every source, and mark anything unowned as out of scope on the spot.
2. Days 3–4: build the permission map and audit the connected identities. Confirm row and column restrictions in the source systems, not in ChatGPT.
3. Day 5: write the approver matrix and the never-connect list; get both signed.
4. Days 6–7: send the logging and retention questions to the client’s other vendors and to OpenAI’s account contact, in writing. Record what comes back, including silence.
5. Days 8–9: scope the pilot — one read-only source, one dashboard, one named approver, in a test workspace, with the revocation path tested before anyone asks a real question.
6. Day 10: deliver the sign-off, the rollout gate, and a one-page decision record. Then, and only then, discuss expanding the connection list.

The commercial point is straightforward. A client who toggles a plugin on their own gets a capability and no evidence. A client who runs this first gets a permission map, an approval rule and a list of things they decided not to connect — which is exactly what an auditor, an insurer or a nervous board member will ask for later.

Frequently asked questions

Sources

1. OpenAI, “Now everyone can put data to work,” September 10, 2026 (direct fetch returns 403 to a scripted client; read via the Internet Archive capture of the same day) — https://openai.com/index/put-data-to-work/
2. OpenAI Developer Community, “Introducing the Data Agent for ChatGPT Work,” posted September 10, 2026 (17:22 ET) — https://community.openai.com/t/introducing-the-data-agent-for-chatgpt-work/1396488
3. OpenAI, “Data agent in ChatGPT Work” demo video, September 10, 2026 (uploaded 11:07 ET) — https://www.youtube.com/watch?v=MSiAd36bGeQ
4. OpenAI Help Center, “Using the Data plugin in ChatGPT Work and Codex” (English route returns 403 to scripted clients; read via the localised route, same article id) — https://help.openai.com/en/articles/20001518-using-the-data-plugin-in-chatgpt-work-and-codex
5. Blockchain.News, “OpenAI Launches Data Agent in ChatGPT Work for Business Analytics” — its article body carries a release date that conflicts with OpenAI’s own; we use OpenAI’s September 10, 2026 announcement — https://blockchain.news/news/openai-data-agent-chatgpt-work
6. AWS Big Data Blog, “Every team is a data team — bring Amazon Redshift analytics to ChatGPT Work,” September 10, 2026 — https://aws.amazon.com/blogs/big-data/every-team-is-a-data-team-bring-amazon-redshift-analytics-to-chatgpt-work/
7. explainx.ai, “OpenAI Data Agent in ChatGPT Work: enterprise safety and governance,” September 10, 2026 (enterprise-framed governance analysis; its claims are not re-verified here beyond its own text) — https://explainx.ai/blog/openai-data-agent-chatgpt-work-enterprise-safety-2026