ChatGPT Sites for internal apps: access, data and ownership

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

ChatGPT Sites can now host plugins, which means someone in operations or sales can build an internal app that reads company systems without an engineer involved. OpenAI announced this at DevDay 2026 for Business, Enterprise, Healthcare and Edu workspaces, and the Sites documentation explains how it works. Our view: allow it for small read-only tools, but decide publishing rights, plugin scope and ownership before the first Site goes live.

Sites is still in public beta. The controls below are the ones documented today, and they may change during the beta.

What changed with ChatGPT Sites plugins?

A Site is a hosted web app that people build in ChatGPT by describing it, or by deploying an existing Codex project. Sites already came with built-in storage. With plugins, a Site that is private to the workspace can also load data from each visitor's own connected apps.

The important design choice is that the Site reads with the visitor's permissions, not the builder's. Each visitor signs in with ChatGPT, reviews the access request, chooses an account and consents. The product page describes this as read-only access to visitors' connected tools. A teammate who cannot see a record in the source app should not see it in the Site either.

That removes one familiar risk of internal tools, a shared service credential that sees everything. The Site still has its own storage, editors and audience.

Who is this for, and what does it require?

The best fit is a team that already keeps shared information in a connected app and wants a simpler view of it. Think of a request tracker, a status board or an onboarding checklist for one department.

It requires a workspace plan with the feature enabled, a Site kept private to that workspace, and admin approval for each plugin the Site uses. Building Sites without plugins is available on Plus, Pro, Business, Enterprise and Edu, with plan-specific usage limits across all Sites during the beta. The documentation does not publish a separate price for Sites.

It is not for regulated data. The docs exclude Protected Health Information and payment-card data, and data residency is not available at launch. If your policies require data to stay in a region, that alone rules out some Sites for now.

Where are the approval points?

Two rows deserve attention. Business and Education workspaces start with plugins allowed in Sites, so an admin there should review the plugin list before announcing the feature. The docs also state that editors can read the Site's live database data, so edit rights are data rights.

Allowing a plugin in Sites does not override ordinary plugin permissions or tenant restrictions, so your existing connector policy still applies.

What are the risks when non-engineers build internal apps?

Ownership is the first risk. A Site built by one person becomes a tool a team depends on. When that person changes roles, someone has to answer questions about it. Admins can transfer ownership and suspend a Site, but only if someone knows the Site exists and who should take it.

Stored data is the second. Plugins read on page load, yet the Site also has a D1 database and R2 file storage. Decide what a Site may keep, and check that nobody copies sensitive records from a plugin into Site storage where every editor can read them.

Review is the third. A Site built from a prompt does not pass through your pull request process unless you set that up. Sites does save a version before it deploys one, which gives you a natural review point. Use it.

Secrets are the fourth. The docs say environment variables and secrets belong in Site settings, never in prompts or content. People who have never handled an API key need that rule written down for them.

A rollout checklist for the first Sites

1. Pick one team and one read-only use case, such as a request dashboard.
2. Review which plugins are allowed in Sites, and turn off any the pilot does not need.
3. Name an owner for each Site and record it where your team tracks internal tools.
4. Write a one-line data rule: what the Site may store, and what must stay in the source app.
5. Before the first deploy, have a second person test the saved version as an ordinary member and confirm they see only their own data.
6. Keep the Site private to the workspace until the owner and an admin agree otherwise.
7. Review the pilot after a month and decide whether to widen access.

Step 5 follows the same principle as our checklist for making AI-generated changes reviewable: the reviewer should see evidence, not a promise.

What should you measure?

Sites records unique visitors and page views under More actions > Analytics. That shows use, not whether the tool is safe or worth keeping.

Track four things during the pilot. Count the Sites and how many have a named owner. Count plugin requests to the admin. Log any case where someone saw data they should not have. Estimate time saved on the task the Site replaced. Use the approach in our guide to measuring an AI workflow before scaling it, and record the baseline before the Site launches.

The DevDay recap also says automations in Sites are now easier to add. The docs do not yet explain how those automations are configured or approved, so keep them out of the pilot until they do.

Where does engineering fit?

Engineers do not need to build every Site. They should own the rules around them: which plugins are allowed, how a Site moves from a prompt to a reviewed Codex project when it grows, and when a tool should leave Sites for your normal stack. Our free Delegate, Review, Own guide sets out the review habits, and our AI training for teams practises that handover on your own tools.

Before you widen access, check your first Site against the owner, data rule and plugin list above.

Further reading

• ChatGPT Sites documentation
• Sites setup for workspace admins
• ChatGPT Sites product page
• OpenAI DevDay 2026 recap