Publishing an OpenAI Data agent dashboard creates a second permission boundary

OpenAI’s operating guide for the recently launched Data agent in ChatGPT Work documents a permission boundary that was not explicit in the launch architecture: the agent can answer business questions across connected data systems and create interactive dashboards, but publishing one copies the analysis data into an OpenAI Site. (OpenAI; OpenAI Help Center)

The product remains a front end rather than a replacement warehouse or universal permission system. OpenAI’s setup guide says administrators separately enable the Data plugin and the underlying source plugins; queries then use the connected account’s existing table-, row- and column-level permissions. OpenAI recommends pairing a warehouse connection with an authoritative semantic layer, and optionally a BI tool, so metric definitions and relationships can ground the analysis. (OpenAI Help Center)

Analysis and distribution use different controls

A user can ask a question in plain language, compare segments, inspect possible causes and turn the result into a dashboard. OpenAI says the agent can work with approved sources including Redshift, ClickHouse, Databricks, BigQuery, MongoDB and Snowflake, and can use documents from Google Drive or SharePoint when those connections are available. Connected BI tools include Oracle BI, Power BI, Sigma, Tableau and ThoughtSpot; the actions available depend on each tool and the user’s access. (OpenAI; OpenAI Help Center)

That breadth makes the semantic layer a deployment dependency rather than optional polish. OpenAI explicitly advises users to check the source, time period, filters and metric definition before relying on an answer, and to compare those details when a result conflicts with an existing report. (OpenAI Help Center)

Publishing creates a second control plane

The sharpest operational warning appears in the sharing documentation. When a dashboard is published through OpenAI Sites, the data used in the analysis is copied into the published site. Teams therefore need to review the Site audience independently of the source query’s warehouse permissions. A correct row-level policy at query time does not by itself decide who should receive a copied artifact later. (OpenAI Help Center)

The same separation applies to actions. OpenAI says Slack or email sharing and actions in connected tools remain constrained by tool capabilities, user permissions and approval requirements, and advises reviewing both destination and content before approval. (OpenAI Help Center)

A practical rollout should therefore test four things independently: source access, metric definitions, generated analysis, and artifact distribution. Start with explicit @Data invocation, a narrow read-only dataset and a named business metric. Verify the query inputs and output against an existing report. Then publish only a low-sensitivity dashboard to a small workspace group and confirm that copied data, refresh behavior and audience controls match policy. That sequence follows the boundaries OpenAI documents rather than assuming one connection grant governs the entire path. (OpenAI Help Center)