ChatGPT Sites can host plugins, but each visitor uses their own connection

OpenAI’s [September 29 DevDay recap](https://openai.com/index/devday‑2026‑recap/) says builders can add supported ChatGPT plugins to the Sites they build. It lists the plugin‑in‑Sites announcement for Business, Enterprise, Healthcare and Edu plans, and says the company is making Site automations easier to add and manage. For a team building an internal dashboard or portal, the change is that the Site can use an approved plugin rather than forcing every reader back into a separate ChatGPT conversation. This is a narrower promise than every public Site using every plugin. OpenAI’s [Sites documentation](https://learn.chatgpt.com/docs/sites) says plugin use requires an enabled workspace and a Site private to that workspace; connected features require visitors to belong to the workspace. The broader Sites product is in public beta on additional plans, but general Site availability does not establish plugin availability for a particular visitor.

OpenAI’s [Sites administration guide](https://learn.chatgpt.com/docs/enterprise/sites) says a visitor signs in with ChatGPT, reviews the Site’s requested plugin access and chooses which of their own connected accounts to allow. The Site receives only information available through that visitor’s permissions. Sharing a Site therefore does not turn the creator’s connection into a shared credential; a visitor who declines access can still open the Site while its connected features stay unavailable. That distinction matters when a Site combines project tasks, documents and a team view. Two colleagues may see the same interface but different underlying records. A builder should test with another workspace member using a separate account, then test the declined‑access path, instead of relying on the builder’s preview. The admin guide specifically recommends that two‑person check.

In the same [admin guide](https://learn.chatgpt.com/docs/enterprise/sites), each plugin has an ‘Allow site visitors to use this plugin’ setting. When no admin choice has been saved, available plugins are allowed in Sites by default for Business and Education; Enterprise starts with plugins off for Sites. A saved admin choice overrides that default. Ordinary plugin permissions and any tenant connector restriction still apply, so turning on the Sites setting alone does not grant a member access to an app. The guide separates Site sharing, workspace plugin policy and tenant connector access. If a plugin works in ChatGPT but not in a Site, those are the first settings to compare before changing the Site’s audience. Admin permission does not replace each visitor’s consent or the source service’s rights. OpenAI’s [Sites product page](https://chatgpt.com/features/sites/) describes user‑approved read‑only connected access in eligible workspaces; the detailed [Sites docs](https://learn.chatgpt.com/docs/sites) say any write action needs separately enabled write access, visitor consent and an explicit user action. Do not infer write capability merely from a plugin appearing in the Site.

The DevDay recap also mentions easier Site automations, but an unattended update should not be planned around a visitor’s temporary connection. OpenAI’s [Sites feature page](https://chatgpt.com/features/sites/) says connected information from a visitor is available while that person uses the Site and is not available to scheduled tasks running in the background. A team can design a live per‑user view with approved plugin data, then separately verify what a scheduled Site task can access before promising it will refresh that view on its own. The practical launch sequence is to confirm that the plan and workspace permit plugin use, verify the specific plugin and tenant controls, test consent with a second member, and check the connected service’s actual data and action rights. The Site is part of [ChatGPT](https://opentools.ai/tools/chatgpt), made by [OpenAI](https://opentools.ai/organizations/openai).