OpenAI's Data agent, launched for ChatGPT Work on September 10, 2026, connects a conversational interface to a company's warehouses, BI tools, and internal documents so anyone can ask a data question in plain English. That's a genuine productivity unlock, and every serious agent vendor is converging on the same shape of product. It's also, mechanically, a new instance of a problem this space already has a name for: an agent that reads untrusted context and inherits an access level nobody individually reviewed. The interesting part isn't whether to adopt this category — it's the two specific places the risk actually lands.
TL;DR
| Risk | Where it comes from | What actually mitigates it |
|---|---|---|
| Permission inheritance | Agent's access ceiling = connected service account's access, not the individual user's | Scope the service account before enabling the role, not after |
| Prompt injection via context | Agent reads dashboard notes, tickets, synced docs as part of answering | Treat agent-read context as untrusted input; monitor what queries it actually ran |
| Action approval fatigue | High-frequency tool with an "approve the action" step invites rubber-stamping | Log and review actions taken, not just outputs shown |
The feature, briefly
OpenAI describes the Data agent as connecting to approved sources — Redshift, BigQuery, ClickHouse, Databricks, Snowflake, MongoDB — plus files from Google Drive and SharePoint, and using the organization's own metric definitions pulled from semantic layers like dbt, GitHub, Snowflake Horizon, and Databricks Genie Ontology. From a plain-language question it produces an interactive dashboard, can edit dashboards directly inside Tableau, Power BI, Sigma, or ThoughtSpot, and can "carry out the actions you approve through connected tools" — sharing findings over Slack or email, for instance. explainx.ai covered the full launch and its permission claims in detail: OpenAI launches a Data agent in ChatGPT Work.
The permission line worth reading twice is OpenAI's own: "Queries enforce the connected account's existing permissions, including table, row, and column restrictions." That's the correct design choice — inherit an existing enforcement layer instead of reinventing one. It also means the honest question isn't "does the agent respect permissions," it's "what does the account it connects with actually have permission to see."
Risk one: permission inheritance, at the account level
Service accounts get provisioned for throughput and convenience, not least privilege. A pipeline account that reads three warehouses so a nightly job doesn't break across teams is a completely reasonable thing to have — right up until a conversational agent connects through it and every person with the plugin inherits that same read scope, through a UI with essentially zero friction to use.
This isn't specific to OpenAI's implementation. It's the default failure mode of any natural-language interface bolted onto an existing data platform: the interface is new, the permission model underneath it usually isn't, and nobody re-audits the account just because a friendlier front end got attached to it. The fix is boring and specific — audit what the connecting account can actually see before turning a data agent on for a role, and scope a dedicated account per use case instead of reusing whatever pipeline credential was already sitting there with broad access.
Risk two: prompt injection through the context it reads
A data agent doesn't just run SQL against a warehouse. To interpret "why did sales slow down," it reads dashboard notes, ticket text, semantic-layer descriptions, and synced documents — the same category of untrusted-context problem covered in our MCP security guide and what is AI agent monitoring, just moved from tool descriptions to BI annotations and doc content.
Any of that text is a place an attacker — or a careless internal integration syncing external content into a wiki the agent reads — can plant instructions aimed at the agent's next step: broaden the query, pull a different table, send the output somewhere it shouldn't go. It's harder to spot than classic prompt injection in a chatbot because the injected text arrives dressed as ordinary business context — a comment on a Tableau dashboard, a field description in a semantic layer — not as an obviously foreign instruction. The mitigation is the same principle as everywhere else in this space: text the agent reads mid-task is input, not instruction, no matter how legitimately business-y it looks.
Risk three: approval fatigue on the action step
"Carries out the actions you approve" is a real safety control only if the approval step gets read. A tool used dozens of times a day by non-technical staff, for routine questions that mostly turn out fine, is exactly the workflow shape where a human stops reading the approval prompt and starts clicking through it. That's not a flaw unique to any one vendor's UX — it's what happens to every approval gate under high-frequency, low-stakes-feeling use, and it's why the action log matters as much as the approval dialog: something needs to be watching what the agent actually did, reviewable after the fact, not just what it asked permission to do in the moment.
The actual checklist
- Scope the connected account before enabling a role, not the plugin's default. Table/row/column permissions are only as tight as the account, not the marketing claim that they're "enforced."
- Treat every piece of agent-read context as untrusted — dashboard notes, ticket text, synced docs, semantic-layer descriptions included.
- Log the actions, not just the answers. A dashboard is the visible output; the query plan and any downstream action (a Slack post, an emailed export) is the part worth an audit trail.
- Review, don't rubber-stamp, the approval step for anything beyond read-only query — and expect that review quality degrades with frequency, so design the gate accordingly.
- Prefer per-use-case service accounts over reused pipeline credentials. The agent's ceiling is the account's ceiling; give it its own, scoped account.
None of this argues against adopting a data agent — the productivity case is real and the direction is industry-wide, not one vendor's bet. It argues for treating the connection point, not the chat interface, as the thing that needs review.
Frequently asked questions
What is an enterprise data agent?
A conversational AI agent connected to a company's data warehouses, lakes, and BI tools — Snowflake, Databricks, BigQuery, Redshift, Tableau, Power BI, and similar — that answers plain-language questions, builds dashboards, and in some products takes follow-up actions like sending a report over Slack. OpenAI shipped one for ChatGPT Work on September 10, 2026; it is a category, not a single product.
Does a data agent bypass a company's existing data permissions?
Not by design — vendors including OpenAI state that queries enforce the connected account's existing table, row, and column permissions. The practical risk is upstream of that: the agent's access ceiling is whatever the connected service account already has, and service accounts are routinely provisioned broader than any one human employee needs.
Can a data agent be prompt-injected?
Yes, the same way any agent that reads untrusted context can be. A data agent investigating a question reads dashboard notes, ticket text, synced documents, and semantic-layer definitions as part of forming its answer — any of which is a place attacker-planted text can redirect its next query or action.
What should a security team check before enabling a data agent for a role?
Audit the connected service account's actual table/row/column access against what the role genuinely needs, treat every piece of context the agent can read mid-query as untrusted input, and require a real approval step for any action beyond read-only query.
Related reading
- OpenAI launches a Data agent in ChatGPT Work — and what it means for data security — the launch details and OpenAI's own permission claims, covered on explainx.ai
- What is AI agent monitoring?
- MCP security: a practical guide to tool poisoning and rug pulls
- AI compliance and regulation for agent activity: what auditors need
- How much sensitive data do people share with AI chatbots? The 2026 numbers
- OpenAI's Project Lily: what human review of ChatGPT chats means for work
- What is AI safety? Definition, AI safety vs. AI security
This post reflects OpenAI's September 10, 2026 announcement of the Data agent in ChatGPT Work as its news hook, generalized to the enterprise data agent category. Feature and permission details are as OpenAI described them at launch and may change as the product evolves.