ChatGPT Sites for Enterprise: Governance Controls, Shadow IT Risks, and Legit Use Cases
ChatGPT Sites lets employees publish sites and apps from ChatGPT. Here's what IT leaders need on admin controls, data residency, and shadow IT risk.
TLDR: ChatGPT Sites turns every ChatGPT seat into a website and app publisher - internal dashboards, client portals, prototypes, all deployed from a prompt. The governance story is better than you’d expect: Enterprise workspaces get RBAC-gated creation, public publishing off by default, and connected-app access scoped to each visitor’s own permissions. But three gaps should shape your rollout: Sites is in beta with no data-residency eligibility, custom domains don’t work on Enterprise at launch, and editors can publish updates without owner re-approval. Pilot it with a small group, keep public publishing off, and write the policy before your users write the apps.
Why This Matters Now
OpenAI launched ChatGPT Sites in public beta this week - a prompt-to-published website and lightweight app builder living inside ChatGPT. Your employees describe what they want, iterate in conversation, and publish to a hosted URL. They can share privately, workspace-wide, invite named external viewers, or go fully public. In eligible workspaces, Sites can even pull live data from connected work tools, scoped to each visitor’s own permissions.
But here’s what makes this an IT story, not a web-design story: the same feature that lets a sales ops analyst ship an internal dashboard in an afternoon lets any employee with ChatGPT access stand up an externally visible app. Practitioner interest is already spiking - the launch thread hit Hacker News within days, and the first comment zeroed in on the privacy implications of visitor sign-in. Press coverage is still in the “cool demo” phase. Nobody has written the enterprise governance guide yet. That’s this article.
ChatGPT Sites at a Glance
| Dimension | Details (verified Oct 3, 2026) |
|---|---|
| What it is | Prompt-to-published websites, apps, and games hosted by OpenAI |
| Availability | Public beta for ChatGPT workspaces, Plus, and Pro accounts |
| How you build | Work surface on web, or Work/Codex in the desktop app; @Sites mention, files, visual refs, or existing Codex project |
| Sharing tiers | Owner + admins only (default) > selected people > workspace-wide > named external viewers > public |
| Enterprise creation control | RBAC-gated; admin must enable per role. Business workspaces get it on by default |
| Enterprise public publishing | Off by default; requires explicit admin enablement plus publish permission |
| Custom domains | Supported generally, but NOT available in Enterprise workspaces at launch |
| Connected-app data | Read-only, visitor’s own account and permissions; requires tenant-level global admin approval |
| Data residency | Not eligible for data or inference residency during beta |
| Beta limits | Usage included up to plan-specific limits; overages can suspend new creation or public availability |
| MCP hosting | A Site can host an MCP server consumed through a ChatGPT plugin |
| Best for | Internal dashboards, client portals, prototypes, team wikis, event pages |
What Sites Actually Does
Strip away the launch buzz and Sites is three things bolted together: a builder, a host, and a permission system.
The builder is conversational. You describe what you want - a dashboard, a project tracker, a launch calendar, an internal portal - attach files or screenshots if you’ve got them, and ChatGPT generates a preview you refine through follow-up prompts. You can start from an existing Codex project, which matters for teams already building in Codex. Every deployment URL is a production URL, so OpenAI’s docs recommend saving a version before deploying changes you haven’t reviewed.
The host is OpenAI’s infrastructure. Built-in storage handles documents, images, and visitor uploads. “Sign in with ChatGPT” gives visitors persistent, personalized sessions. You can rename the hosted URL (old address redirects automatically) or connect a custom domain you already own - except on Enterprise, where custom domains aren’t available at launch.
The permission system is where enterprise buyers should focus. A new Site is visible only to its creator and workspace admins. From there the owner can widen access in stages: named individuals, the whole workspace (gated behind ChatGPT sign-in), named external viewers, or full public publishing. Each stage has its own admin gate, which I’ll cover below.
Earned insight: The staged default-deny model (creator + admins only until someone acts) is the single best design decision in Sites from a governance perspective. I’ve watched three separate shadow-IT incidents start with tools that defaulted to workspace-visible or public. OpenAI chose the safe default here. The risk isn’t the default - it’s what happens after an owner widens access once and forgets, because there’s no expiry or re-certification on sharing settings in the beta docs.
The Admin Control Surface: What You Actually Get
Creation and publishing gates
In Business workspaces, Sites is on by default - every member can create. In Enterprise, an admin must enable Sites through role-based access controls, deciding separately who can create Sites and who can publish them. If someone can’t see Sites, the checklist is: workspace enabled, member in an eligible role, signed into the right workspace.
Public publishing deserves its own paragraph because OpenAI got this right. In Enterprise workspaces it’s off by default. Turning it on takes two steps: enable public publishing in Workspace settings, then grant specific users or groups the permission through RBAC. A member with creation rights but no publish permission can’t go public. That’s the control that prevents the 2 AM “oops, our Q4 forecast dashboard is on the open internet” incident.
Connected-app access: the delegated model
This is the most architecturally interesting part. In Business and Enterprise workspaces with connected-app access enabled, a Site can request read-only access to each visitor’s own connected apps - think a shared issue dashboard that shows live ticket data. But the scoping is tight:
- Each visitor authorizes through their own connected account. Their existing app permissions still apply.
- Access is read-only. It doesn’t authorize writes or background scheduled tasks.
- It requires a workspace-private Site. Public Sites and external-viewer invitations don’t qualify.
- Tenant-level approval is off by default and requires a global admin (not just a workspace admin) to enable Connectors for Sites under External access.
- Per-plugin, a workspace admin must flip “Allow use in Sites” - off by default, and independent of whether the plugin is available in ChatGPT generally.
That’s four separate gates (tenant, workspace plugin toggle, Site privacy, visitor authorization) before any connected data flows. It’s defense in depth, and misconfiguring it into a data leak takes real effort - as long as global admins understand what they’re approving at the tenant level, because that approval covers current and future Sites.
But note the read-only limitation cuts both ways. A Site can’t write back to your issue tracker, update a record, or run scheduled syncs. If your use case needs two-way interaction, you’re building a demo, not a tool.
External viewers and co-editing
Site owners can invite named outsiders as view-only guests without making the Site public - useful for client portals and vendor collaboration. In Enterprise, the inviter needs a separate external-viewer invitation permission, and guests never become workspace members or editors.
Co-editing has the sharpest edge in the whole permission model: after the owner publishes once, an editor with “Can edit” access can publish subsequent versions to the same URL without a separate owner-approval step. Coordinate your review process before handing out edit access, because the tooling won’t enforce one.
Warning: Editors can publish to a live Site URL without owner re-approval after the first publish. OpenAI documents this plainly, but it means your change-management process for Sites is a human process, not a technical control. For anything customer-facing, keep the editor list to one or two people.
Sites Governance Strengths:
- Default-deny sharing (creator + admins only until widened)
- Public publishing off by default on Enterprise with dual RBAC gates
- Connected-app access scoped to each visitor’s own permissions, read-only, four approval gates
- External viewers get view-only access without workspace membership
- Tenant-level connected-app approval requires global admin, not just workspace admin
Sites Governance Weaknesses:
- No data or inference residency eligibility during beta - a hard stop for regulated industries
- No custom domains on Enterprise at launch, pushing teams toward less-governable alternatives
- Editors can publish without owner re-approval after first publish
- No documented audit logging, sharing expiry, or access re-certification in beta docs
- Beta usage limits are plan-specific but undisclosed - capacity planning is guesswork
The Three Gaps That Should Shape Your Rollout
No data residency in beta
OpenAI’s admin documentation states it directly: Sites is currently in beta and is not eligible for data or inference residency. If your organization routes ChatGPT traffic through a residency commitment - EU data boundary, healthcare, financial services - Sites content and visitor data sits outside that commitment until OpenAI changes the status. This alone is a pilot-blocker for regulated shops, and it’s the question your compliance team will ask first. Have the answer ready before they ask it.
No custom domains on Enterprise
Custom domains work for other plans but are explicitly unavailable in Enterprise workspaces at launch. That’s a strange inversion - the plan with the strictest branding and domain requirements can’t use its own domains. The practical effect: Enterprise teams that need branded client portals will either wait or build them elsewhere, while less-governed plans ship branded Sites today. Expect this gap to close, but don’t plan a Q4 client-portal migration around it.
The MCP angle nobody’s covering
Buried in the help docs is the most strategically interesting capability: a Site can host an MCP server that ChatGPT consumes through a plugin. Read that again. Sites isn’t just a publishing surface - it’s a way to stand up a tool-using backend (read from connected services, expose tools to conversations) without leaving ChatGPT. Subject to the same Site, plugin, and connected-service permissions, but still: your analysts can build MCP-backed workflows conversationally and share them workspace-wide. Every “Sites vs website builder” comparison launching this week will miss this. It’s the difference between a page builder and a lightweight agent-hosting platform, and it’s where the real enterprise value - and the real governance questions - will concentrate over the next two quarters.
Earned insight: The MCP-server hosting capability reframes the entire build-vs-buy conversation for internal tooling. A Jira dashboard Site backed by an MCP server, shared workspace-wide with per-visitor permissions, replaces a class of work that used to need a Retool license, a service account with over-broad permissions, and a sprint of engineering time. The catch I keep coming back to: service accounts are auditable and permission-scoped by design, while a fleet of employee-built MCP Sites is neither - yet. Whoever builds the inventory and review layer for this wins the category.
Where Sites Fits Against What You Already Have
You’re not evaluating Sites in a vacuum. Your org already governs something that does parts of this job.
Against Claude Artifacts: Artifacts are the closest interaction analog - conversational build, live preview. But Artifacts don’t publish to hosted URLs, don’t offer visitor sign-in, don’t connect to work tools per-visitor, and don’t host MCP servers. Sites is a deployment platform; Artifacts is a canvas. If your Claude Enterprise users ask “can we publish this,” the answer is still no.
Against Microsoft Copilot surfaces: Copilot Pages and SharePoint-hosted agents cover internal publishing inside M365 with your existing Purview and DLP posture. If you’re a Microsoft shop with mature Purview policies, Sites is a second governance surface you’d need to stand up - weigh that cost honestly before piloting.
Against Retool and Power Apps: these are the real incumbents for internal tools, with proper version control, environments, audit logs, and write-back to systems of record. Sites can’t write back, has no environments, and its versioning is “save a version before deploying.” Don’t migrate anything load-bearing. But for the long tail of dashboards, trackers, and portals that never justified a Retool build, Sites removes the cost and queue entirely - which is exactly why it’ll spread faster than your governance process expects.
Legit Enterprise Use Cases:
- Internal dashboards over connected tools (read-only, per-visitor permissions)
- Client portals via named external-viewer invitations (no public exposure)
- Prototypes and MVPs that unblock product conversations in days
- Team wikis, event pages, launch calendars - the long tail nobody staffs
- MCP-backed conversational workflows shared workspace-wide
What Sites Can’t Do Yet:
- Write back to systems of record (read-only connected access)
- Run scheduled or background tasks against connected apps
- Serve regulated workloads (no residency eligibility in beta)
- Carry your brand on Enterprise (no custom domains at launch)
- Replace version-controlled, audited internal tooling for anything critical
Pricing Reality
Sites usage during the public beta is included in your ChatGPT plan up to plan-specific limits - OpenAI will notify you as you approach them. Hit a limit and you may lose the ability to create Sites, add storage, or keep a high-traffic public Site available until usage drops. Existing Sites stay editable.
Here’s what that means for budgeting (plan prices verified Oct 3, 2026):
| Plan | Per-User Price | Sites Position |
|---|---|---|
| Plus | $20/month | Included in beta limits; no admin controls to speak of |
| Pro | $200/month | Included; individual power users, not a governance story |
| Business | ~$25/user/month annual | Enabled by default; basic workspace controls; custom domains available |
| Enterprise | Custom annual | RBAC-gated, public publishing off by default, no custom domains at launch |
The sticker price isn’t the TCO. Budget for: the admin hours to design RBAC roles and review tenant-level connector approvals; the policy work (acceptable-use rules for publishing, external sharing, connected-app exposure); potential overage exposure since beta limits are undisclosed and “Enterprise limits may vary by workspace”; and the review burden of a growing fleet of employee-published Sites with no native inventory or re-certification tooling. The license cost is the smallest line item. The governance labor is the real budget.
Tip: Before enabling Sites broadly, run a two-week scoped pilot: one RBAC group, workspace-private sharing only, public publishing off, one connected app with “Allow use in Sites” enabled. Inventory everything built at day 14. That inventory becomes your policy’s evidence base - and your argument for headcount if the fleet keeps growing.
Who Should Pilot Sites - and Who Should Wait
Good fit: You’re on ChatGPT Business or Enterprise, your admins can own RBAC and tenant approvals, and you have a backlog of internal dashboards, trackers, or portals that never justified engineering time. Teams already building in Codex get the shortest path since Sites accepts Codex projects as starting points. If your connected-app estate (issue trackers, doc stores) is already governed per-user, the delegated-access model slots in cleanly.
Not a good fit: Regulated workloads needing residency guarantees - hard stop until beta status changes. Anything requiring write-back, scheduled sync, or SLA-backed availability. Enterprise teams that need custom domains on day one. And orgs without a ChatGPT admin function mature enough to manage RBAC roles and review connector approvals: enabling Sites without that muscle is how you get a hundred published apps and zero inventory.
Bottom Line
ChatGPT Sites is a governance story wearing a website-builder costume, and the governance story is surprisingly solid at the defaults layer - default-deny sharing, public publishing off on Enterprise, four gates on connected data. The gaps are real but bounded: no residency in beta, no Enterprise custom domains, editor self-publishing, undisclosed limits. None of them is a reason to ban Sites outright. All of them are reasons to pilot with intention rather than discover the fleet in six months.
But the thing I’d actually plan around isn’t the website builder - it’s the MCP-server hosting. Employee-built, permission-scoped, conversationally maintained tool backends are a new category of internal software, and Sites just made them trivially easy to create and share. The website builder gets the headlines. The agent-hosting platform underneath is what your 2027 architecture diagrams will need to account for.
Rating: 3.8 / 5 for enterprise readiness today (strong defaults, beta gaps). 4.5 / 5 for strategic importance - start governing it now.
Your 30-day action: enable Sites for one RBAC pilot group with public publishing off, publish an acceptable-use one-pager covering sharing tiers and external viewers, and schedule the day-14 inventory review before you widen access.
FAQ
Is ChatGPT Sites available on ChatGPT Enterprise?
Yes, in public beta. But unlike Business workspaces where it’s on by default, Enterprise admins must enable Sites through role-based access controls - deciding separately who can create Sites and who can publish them. If your users can’t see Sites, they’re likely not in an enabled role or signed into the right workspace. Availability is still rolling out, so some accounts may not see it yet even with correct permissions.
Can Enterprise workspaces use custom domains with Sites?
Not at launch. OpenAI’s help documentation explicitly states custom domains are unavailable in Enterprise workspaces, though other plans can connect a domain they own via DNS records. For Enterprise teams this is a concrete blocker - client portals and branded experiences stay on ChatGPT-hosted URLs until OpenAI closes it. Don’t commit to a branded-portal roadmap on Sites until the Enterprise custom-domain flag flips.
Does ChatGPT Sites meet data residency requirements?
No - not during the public beta. OpenAI’s admin documentation states Sites is not eligible for data or inference residency. If your organization depends on EU data boundary commitments or sector-specific residency (healthcare, financial services), Sites content and visitor data falls outside those guarantees. Treat this as a pilot-blocker for regulated workloads and re-check the status before any production commitment.
Can visitors see data they shouldn’t through connected apps?
The design makes this hard to do accidentally. Each visitor authorizes read-only access through their own connected account, and their existing app permissions still apply - a Site can’t elevate anyone past what they could already see. Four gates must all open: tenant-level global admin approval, per-plugin “Allow use in Sites,” a workspace-private Site, and the visitor’s own authorization. The residual risk is tenant admins approving broad connector scopes without understanding they cover all current and future Sites.
Can employees publish public sites without admin approval?
On Enterprise, no - provided admins haven’t changed the defaults. Public publishing is off by default and requires both a Workspace-settings enablement and RBAC publish permission for the user. On Business workspaces, where Sites is enabled by default, the barrier is lower - review your sharing settings there first. Either way, a brand-new Site starts visible only to its creator and workspace admins until someone widens access.
What does ChatGPT Sites cost?
During the public beta, Sites usage is included in your ChatGPT plan up to undisclosed plan-specific limits, with in-product notifications as you approach them. The underlying seats run $20/month (Plus), $200/month (Pro), ~$25/user/month annual (Business), and custom annual pricing (Enterprise). The real TCO is governance labor: RBAC design, connector-approval reviews, acceptable-use policy, and ongoing inventory of published Sites. Budget admin hours, not just licenses.
How is Sites different from Claude Artifacts or Copilot Pages?
Artifacts offer conversational building and live preview but no hosted publishing, visitor sign-in, per-visitor connected tools, or MCP-server hosting - they’re a canvas, not a deployment platform. Copilot Pages and SharePoint agents publish inside M365 under your existing Purview and DLP posture, which is an advantage if you’re a Microsoft shop but a different ecosystem if you’re standardized on ChatGPT. Sites’ distinctive combination is public hosting plus per-visitor connected data plus MCP backends.
Can ChatGPT Sites replace Retool or Power Apps?
Not for anything load-bearing. Retool and Power Apps offer write-back to systems of record, environments, version control, audit logs, and SLA-backed availability - Sites has none of these (read-only connected access, no scheduled tasks, beta limits). Where Sites wins is the long tail: dashboards, trackers, and portals that never justified a formal build. Expect it to complement your low-code stack by absorbing low-complexity demand, not to replace it.
Related Articles
Discussion