OpenAI’s Data Agent inherits row and column permissions. Governance must follow the output.

One conversation now spans governed data and downstream action

OpenAI’s Data Agent announcement introduces a ChatGPT Work plugin that can investigate company data, build interactive dashboards and carry out approved actions through connected tools. Administrators choose which connections are available and which roles may use them.

Supported sources include Redshift, Datadog, BigQuery, ClickHouse, Databricks, MongoDB, Snowflake, Google Drive and SharePoint. Semantic context can come from systems such as dbt, GitHub, Snowflake Horizon and existing BI dashboards.

OpenAI says queries enforce the connected account’s table, row and column restrictions. That is the correct foundation: the agent should not gain broader read access than the person asking the question.

The workflow crosses several policy systems

A plain-language request can combine operational data, documents and business definitions, then turn the analysis into a dashboard. OpenAI says the agent can also share findings through Slack or email and act through connected tools after approval.

Each transition changes the risk. A row-level rule may protect source records, but a chart can reveal a small group. A document might be available for reading but unsuitable for a broad dashboard. An approved recommendation can become a write action in another system.

OpenAI’s help centre makes one implementation detail explicit: when an analysis is published with Sites, the data used in that analysis is copied into the published site. Teams should therefore treat the Site as a separate data copy and apply its own audience, expiry, deletion and permission-revalidation controls.

Controls along the Data Agent path

Stage	Primary control	Evidence to retain
Connection	Admin-approved source and role	Who enabled it and scope
Query	Source table, row and column policy	Account, query and policy decision
Analysis	Metric definitions and data quality	Sources, transformations and caveats
Dashboard	Audience, copied-data and sensitivity policy	Lineage, owner, sharing list and expiry
Action	Explicit approval and least privilege	Approver, parameters and result

Deploy with output tests, not connection tests alone

Before broad rollout, test users who differ only in row or column access and compare every generated answer and chart. Include small-group inference, joins between differently classified sources, cached results and exported files.

Apply expiry and ownership to generated dashboards. When a dashboard is published with Sites, inspect the copied data and prove that the selected audience cannot see rows, columns or derived values outside its entitlement. Re-run that test when source permissions change, because the published artefact has its own sharing boundary.

Preserve source citations and the policy context that produced each result. For connected actions, show the exact target, parameters and affected records at approval time, then log the outcome independently.

OpenAI says nearly all of its product team and more than two-thirds of its go-to-market organisation use data agents. That is a vendor adoption figure, not an external effectiveness benchmark.

The position

The product moves self-service analytics closer to the decision and the action. Its value will depend on whether organisations can preserve meaning, permission and evidence through that full path.

Inherited database controls solve an essential part of the problem. They do not automatically govern a derived artefact or a write into another system. Security, data governance and analytics teams should treat the agent as one policy-spanning workflow.