How to Share a ChatGPT Site with External Clients Without Making It Public

The safest sharing pattern: invite named external viewers, not the whole internet

ChatGPT Sites now supports a practical middle ground for client review: eligible ChatGPT Business and Enterprise Site owners can share a live Site with named external viewers without adding those viewers to the workspace and without publishing the Site publicly. OpenAI describes these external viewers as view-only visitors: they can use the Site, but they cannot edit it, publish it, or become workspace members by accepting the invitation. That distinction matters for agencies, consultants, product teams, legal reviewers, customer advisory boards, and enterprise administrators who need client feedback without turning a prototype, approval portal, demo app, or microsite into a public destination.

This tutorial focuses on the narrow external-client workflow: choose the least broad audience that still lets the client complete the review, invite specific people, confirm their view-only experience, and remove or retest access after the review window closes. It does not treat ChatGPT Sites as a replacement for a production identity provider, customer portal, payment system, health-record workflow, or regulated-data application. OpenAI’s Sites documentation states that shared and public Sites require careful review for confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection before anyone outside the authoring team gets access.

For ChatGPT Sites No Code Guide, How to Use ChatGPT Sites to Build and Deploy Web Apps Without Code in 2026 is the most relevant adjacent resource. The ChatGPT Sites no-code guide explains how hosted applications are created and deployed, providing the build context needed before configuring external viewer access.

Four access models you must not confuse

The most common mistake is treating every non-private option as “sharing.” In practice, ChatGPT Sites has materially different access patterns: named external viewers, workspace sharing, editor access, and public publishing. Each pattern answers a different operational question: who can see the Site, who can modify it, who can publish it, and whether the Site becomes reachable beyond a defined audience.

Named external viewers are the correct pattern when the client only needs to inspect, test, comment on, or approve the Site. For example, a marketing agency might invite a client’s brand lead and legal reviewer to a campaign landing-page prototype. The agency should not add those reviewers to its ChatGPT workspace, should not make the campaign public, and should not grant editor access unless the reviewers are expected to directly modify the Site. The narrower model reduces administrative cleanup, limits accidental collaboration rights, and keeps the review audience explicit.

Workspace sharing is appropriate when the audience is inside your organization and the Site should be available to colleagues under workspace governance. It is not a client-sharing shortcut unless the client is legitimately part of the same ChatGPT workspace, which is uncommon for external agency-client relationships and inappropriate for most vendor or customer reviews. Use workspace sharing for internal review groups, enablement teams, or cross-functional stakeholders who already operate under the workspace’s administrative policies.

Editor access is a collaboration decision, not a viewing decision. An editor can affect the Site’s content and behavior, so editor access should be limited to people who are accountable for making changes and who understand review obligations. If a client asks to “leave edits,” consider collecting feedback in a separate document, issue tracker, or comments process rather than granting direct editing rights. View-only access plus a structured feedback channel is usually safer for client approval because it preserves ownership of the build and reduces accidental changes before launch.

Public publishing is the broadest access decision and should not be used merely because a client is outside your workspace. OpenAI’s documentation distinguishes public Sites from Sites shared with named external viewers. Public access can be appropriate for a completed public campaign, documentation demo, calculator, or lightweight application after review, but it is the wrong default for pre-launch client review. If the Site contains unreleased messaging, internal implementation details, draft pricing language, restricted creative, or unapproved third-party material, do not solve client access by making it public.

Eligibility and rollout: why the invitation control may not appear

OpenAI describes ChatGPT Sites as a public-beta feature for creating, previewing, publishing, and sharing interactive websites and lightweight applications from Work on the web or from Work or Codex in the desktop app. Availability can depend on plan, workspace controls, surface, region, and rollout. If a teammate sees a Sites control but you do not, the difference may be an administrative role setting, a plan difference, the product surface being used, or a staged rollout condition rather than a bug in the Site itself.

For ChatGPT Business, OpenAI states that Sites are enabled by default. That does not mean every sharing option should be treated as automatically approved for every business process. A Business workspace still needs a practical policy for what types of Sites may be shared externally, who can invite clients, what data is prohibited, how reviewers are removed, and which person signs off before a Site becomes public. Smaller teams often skip this policy because the feature is easy to use; that is exactly when accidental exposure risk increases.

For ChatGPT Enterprise and Edu workspaces, administrators have more explicit role-based control. OpenAI’s workspace administration documentation says Enterprise and Edu administrators must enable Sites for the relevant role and separately enable the permission to invite external visitors. OpenAI’s release notes identify the administrator path as Workspace settings, Permissions & roles, Sites, with a separate permission named “Allow members to invite external visitors to sites.” The important operational point is separation: permission to use Sites, permission to invite external visitors, and permission to publish publicly are not the same approval.

For ChatGPT Workspace Permissions, How to Import and Govern ChatGPT Plugin Marketplaces from GitHub: Enterprise Workspace Playbook is the most relevant adjacent resource. The GitHub plugin-marketplace governance playbook shows how workspace administrators manage shared resources, synchronization, removal, and member access across an enterprise environment.

Decision rule: if the client only needs to review or use the Site, invite named external viewers. If the client needs to change the Site, consider editor access only after a collaboration and content-control decision. If anyone on the internet should be able to reach it, use public publishing only after a launch-grade privacy, security, rights, and content review.

Preflight review before inviting any external client

Before you invite a named external viewer, perform a content and audience review as if the recipient will carefully inspect every page, form, file, link, and interaction. View-only access prevents the invited client from editing or publishing, but it does not make the Site’s visible information harmless. If the Site displays confidential roadmap text, internal customer names, credentials, private URLs, test records, draft legal terms, or non-cleared creative assets, view-only access still exposes that material to the recipient.

Start with audience classification. List each proposed recipient by name, organization, role, and reason for access. A client executive approving brand direction may need a different Site experience than a legal reviewer checking disclaimers or a technical stakeholder testing form behavior. If a recipient does not have a specific review task, wait to invite them. Named external access is most valuable when the list is deliberate, short, and tied to a review deadline.

Next, review the Site’s content for confidentiality. Check visible page text, generated copy, button labels, sample data, hidden sections exposed through navigation, downloadable files, images, metadata-like labels, and any linked resources. Replace internal project names with client-approved names, remove employee-only references, and confirm that examples do not include real personal data unless there is a documented reason and lawful process for using it. Treat screenshots as data: a single dashboard image can reveal revenue, customer names, support queues, internal tooling, or unreleased product plans.

Review forms and visitor data collection with extra caution. OpenAI’s Sites guidance warns that shared and public Sites should be reviewed for forms, authentication behavior, and visitor data collection. Do not collect information from client reviewers unless you know where it goes, who can access it, how long it is needed, and whether the client expected to submit it. For approval workflows, a safer pattern is often to put feedback in a separate, governed system and keep the Site itself focused on display and interaction.

Check prohibited or unsupported sensitive use cases before sharing. OpenAI states that Sites must not process protected health information or payment-card data except through an appropriate third-party payment processor, and must not target children below the applicable age of digital consent. OpenAI also states that ChatGPT Sites does not support data residency or inference residency at launch. If your client contract, regulatory environment, or internal policy requires residency guarantees for this workflow, named external viewer access does not solve that requirement.

Finally, review the access path itself. Confirm the Site is not already public, confirm whether it is shared internally more broadly than intended, and identify any editor access that could change the Site during client review. If you remove a direct invitation later, OpenAI warns that the person may still have access through another audience setting, such as public, workspace, or group sharing. Build retesting into the workflow: after each sharing change, verify the recipient experience from the perspective of the intended visitor, not just from the owner’s settings screen.

What this tutorial will do next

The remaining steps in this tutorial will walk through the client-sharing workflow from the Site owner’s perspective: choose the narrowest audience, invite named external viewers, confirm that they have view-only access, test the signed-in recipient experience, remove access after review, and verify that no alternate audience setting keeps the Site reachable. The goal is not only to send an invitation successfully; it is to create an auditable habit for external review that avoids public exposure, avoids unnecessary workspace membership, and keeps publishing authority in the hands of the team that owns the Site.

Invite one client account and verify the private route

OpenAI’s Sites sharing model lets an eligible Site owner give a named external viewer access to a live ChatGPT Site without adding that person to the workspace and without switching the Site to public access. The operational goal in this step is narrow: keep the audience limited to the owner, permitted workspace roles, and the client email address you explicitly invite, then prove the client experience from the invited account before you send the link in a project thread.

Decision rule: if the client only needs to review, click through, fill a test form, or approve copy, invite that person as a named external viewer. Do not use public publishing or broad workspace sharing as a substitute for a direct client invitation.

The exact owner workflow

1. Open the Site you intend to share. Start from the ChatGPT surface where the Site is available to you, such as Work on the web or a supported desktop app experience. Confirm you are opening the correct Site, not a duplicate preview or an older prototype, because the audience setting applies to the live Site you share.

2. Select Share. Use the Site’s sharing control rather than copying a browser URL from your own session. A copied owner URL can create false confidence during testing because it may work for you through your workspace identity while failing for the invited client.

3. Choose the narrow audience. Select the most restrictive audience that still permits named external viewers. In practical terms, avoid choosing a public audience and avoid broad internal sharing unless the project requires those audiences. OpenAI’s help materials distinguish between restricting a Site to the owner and admins, sharing internally, sharing with named external viewers, and making a Site public when the workspace allows it.

4. Add the external client email address. Enter the exact email address the client will use to sign in. Treat aliases, distribution lists, and personal-versus-corporate addresses as separate identities unless your organization has independently verified how the recipient authenticates. If the client says they will review from [email protected], do not invite [email protected] for convenience.

5. Confirm Viewer access. External viewers are view-only according to OpenAI’s Sites documentation: they can use the Site but cannot edit or publish it, and they do not become members of your ChatGPT workspace. If you see any role choice that appears broader than viewer, stop and verify that you are not changing an internal collaborator role or workspace-level sharing setting.

6. Save the sharing change. Do not assume the invitation exists until the sharing dialog or Site state reflects the saved audience. For client approvals, capture the invited email address, the Site name, the date, and the person who approved the share in your project record.

7. Test while signed in with the invited account. The proof test must use the invited client identity, not the owner account, not a workspace admin account, and not an unrelated personal account. If you cannot access the invited mailbox, schedule a short screen share with the client and ask them to open the Site while signed in with the invited email address.

This workflow deliberately separates two actions that teams often blend together: publishing a Site and sharing a Site. Publishing makes a live version available according to its audience settings; sharing determines who can reach that live version. A Site can be live but limited to a narrow set of named viewers, which is the pattern you want for client review without public exposure.

Permissions matrix for owners, editors, internal viewers, external viewers, and public visitors

The following matrix is a practical interpretation of the Sites access model described by OpenAI. Workspace configuration, plan eligibility, and role-based controls can change what a specific person sees, so use the matrix as an implementation checklist and then validate the actual Site behavior with test accounts.

The most important line in the table is the distinction between external viewer and editor. OpenAI’s documentation says named external viewers can use the Site but cannot edit or publish it. That is appropriate for client review, stakeholder approval, and controlled demonstrations; it is not appropriate if the client must modify the build directly, because that would require a different collaboration model and workspace governance decision.

How to test the invited account without fooling yourself

Testing must answer three questions: whether the invited account can reach the Site, whether an uninvited account is blocked, and whether the Site still exposes only the content you intended external viewers to see. Run those checks in separate browser profiles or private windows so cached owner sessions do not contaminate the result.

1. Positive test: sign in as the invited email address and open the shared Site link. The expected result is that the client can load and use the Site as a viewer, with no editing or publishing controls available.

2. Negative test: sign out, then try the same link with an account that was not invited and is not covered by internal or public sharing. The expected result is no access unless another audience setting still grants it.

3. Owner-control test: return to the owner account and confirm the Site is not set to a broader audience than intended. This catches the common mistake where a direct invitation exists but public or internal sharing is also enabled.

4. Content test: browse the pages, forms, generated responses, embedded links, and downloadable materials as the external viewer. View-only access prevents editing; it does not automatically remove confidential text, uploaded content, secrets exposed in the interface, or third-party material you did not have rights to share.

Client Site access test record
Site name:
Site owner:
External viewer email:
Audience selected:
Public access disabled or not used:
Internal broad sharing disabled or not used:
Invited account can open Site:
Uninvited account blocked:
External viewer sees no edit controls:
External viewer sees no publish controls:
Forms and links reviewed:
Confidential files/content removed:
Tester:
Date:
Approval owner:

The negative test matters because OpenAI warns that removing a direct invitation does not necessarily remove access granted through another audience setting. The same logic applies before launch: a successful invited-account test does not prove the Site is private if a public, workspace, or group audience also reaches it.

Business and Enterprise administrator dependencies

OpenAI’s release notes and help materials describe named external Site viewers as available to eligible ChatGPT Business and Enterprise Site owners, with Enterprise administration adding more granular control. Business Sites are documented as enabled by default, while Enterprise availability and public publishing depend on role-based access controls and workspace configuration.

For Enterprise and Edu workspaces, administrators must enable Sites for the relevant role and separately enable the permission that allows members to invite external visitors to Sites. OpenAI identifies this as a distinct permission from public publishing, which means a user may be able to work with Sites but still not see the option to invite an external client.

For ChatGPT Business Administration, ChatGPT Business Premium vs Standard Seats: 5x Usage, Pricing, ROI, and Team Allocation Guide is the most relevant adjacent resource. The ChatGPT Business seat comparison explains administrative roles, allocation decisions, and workspace economics relevant to deciding who should own and maintain a client-facing Site.

If the external invitation control is missing

When the invite control does not appear, do not workaround the problem by making the Site public. Treat the missing control as a configuration or eligibility signal and check the likely causes in order: your plan may not include the capability, the rollout may not have reached your workspace or surface, Sites may not be enabled for your role, or Enterprise permissions may allow Site creation but not external visitor invitations.

The safest escalation path is to ask the workspace administrator for a yes-or-no decision on external viewer invitations for your role. That request should include the Site name, client domain, business reason, intended review window, and confirmation that the client only needs viewer access. This gives administrators enough context to approve the narrow permission without enabling broader public publishing.

Operational safeguards before you send the client link

Before sending the link, review the Site as if every visible element could be forwarded in a screenshot. OpenAI’s Sites documentation calls out the need to review public or shared Sites for confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection. The same review is necessary for named external viewers because “not public” does not mean “risk-free.”

• Remove internal-only material: delete roadmap notes, private pricing assumptions, customer names, unreleased screenshots, source excerpts, and hidden test copy that an external viewer could encounter through navigation or generated interactions.

• Check forms and data flows: if the Site collects feedback, make clear what the client should enter and where that information will be reviewed. Do not collect protected health information or payment-card data through the Site; OpenAI’s guidance says Sites must not process those categories except for payment-card handling through an appropriate third-party payment processor.

• Validate links and embedded content: external viewers may follow links to documents, prototypes, repositories, or third-party services. Confirm those destinations have their own access controls and do not accidentally expose broader project material.

• Separate Site access from in-Site authentication: an invited viewer may be allowed to load the Site, but any authentication or account behavior inside the Site is a separate design and security concern. Do not assume the outer sharing audience enforces every application-level rule.

• Record the review window: if the invitation is for a time-boxed approval, set a calendar task to remove or reassess access after the review. Offboarding is part of the sharing workflow, not an optional cleanup step.

After the client confirms access, send a short instruction note that names the invited email address, states that access is view-only, and asks the client not to submit sensitive regulated data unless your organization has separately approved that workflow. This reduces confusion when the client forwards the link to a colleague who was not invited and cannot open it.

Verify the client experience, then remove access without leaving another route open

After you invite a named external viewer, treat the first client session as an access-control test rather than a launch celebration. OpenAI’s Sites documentation distinguishes the Site audience setting from the Site’s content and behavior: an external viewer can be view-only and still see confidential text, uploaded assets, embedded links, generated responses, form fields, or connected data exposed by the application itself. Your verification pass should therefore confirm two things at the same time: the intended person can reach the live Site, and the live Site does not disclose anything you did not approve for that person.

Recommendation: run the verification from an account that is not the Site owner, not a workspace administrator, and not an editor. Owner and admin sessions can mask broken recipient access because those roles may retain access through administrative privileges. A private browser window helps reduce cached-session confusion, but it is not a substitute for using the exact external identity you invited. If the client uses multiple email identities, ask them to test with the same address you added as the named external viewer.

Build a visitor test that checks both access and disclosure

The safest visitor test starts from the live Site link you intend to send to the client, not from an editor preview or builder session. Preview and authoring contexts can include permissions, draft state, or workspace context that an external viewer should not inherit. OpenAI describes Sites as publishable live websites and lightweight applications; your test should therefore reflect the published visitor path, including any form submissions, navigation links, file downloads, embedded media, generated outputs, and custom-domain routes you plan to expose.

For ChatGPT Site Publishing Checklist, How to Build and Deploy a Full Web App with Codex Sites — From Prompt to Production in Under 10 Minutes is the most relevant adjacent resource. The Codex Sites deployment tutorial walks through prompt-to-production publishing, making it a useful companion for pre-share validation and launch readiness.

Suggested verification log

Site:
Owner:
Client organization:
Invited external viewer email:
Date and time tested:
Tested live Site URL:
Tested custom domain URL, if applicable:
Browser/session used:
Expected result:
Actual result:
Could view Site: yes/no
Could edit or publish: yes/no
Unexpected files visible:
Unexpected links visible:
Forms tested:
Generated responses tested:
Connected data exposed:
Uninvited account result:
Removal retest completed:
Approver:

Understand the sign-in boundary before troubleshooting access

Named external viewer access is identity-based. If the recipient opens the link while signed out, signed into a different account, or using an email alias you did not invite, the result may look like a broken invitation. The practical troubleshooting rule is simple: first confirm the invited email address, then confirm the account currently signed in, then test an uninvited account separately. Do not broaden the Site to public access just to “get past” a sign-in issue; that changes the risk model from named-client viewing to internet reachability.

OpenAI states that external viewers do not become workspace members and cannot edit or publish the Site. That restriction is important but narrow. It protects the authoring and publishing workflow; it does not mean the client cannot copy visible text, download exposed files, submit forms, take screenshots, forward observations, or trigger Site functionality available to visitors. Treat a view-only viewer as a real external recipient with full visibility into whatever the Site renders to them.

If your Site includes its own authentication screen, client portal form, password field, CRM lookup, or third-party login, keep that separate from the ChatGPT Sites audience setting. The Site audience answers “who can reach this Site.” Your in-Site authentication answers “what this visitor can do inside the application after reaching it.” A visitor may pass one layer and fail the other. Conversely, a Site made public with a login form is still publicly reachable at the outer layer, even if the inner workflow requires credentials.

Review links, files, forms, generated content, and secrets as separate risk surfaces

Before inviting a real client, click every visible link as the external viewer and classify the destination. A link to a public brochure is different from a link to an unpublished roadmap, a private document, a staging dashboard, or a third-party tool that accepts the viewer into a broader workspace. Links can also reveal confidential information through filenames, folder names, query parameters, or document titles. If a linked resource has its own sharing setting, verify that setting separately instead of assuming the Site’s audience controls the downstream destination.

Uploaded files require the same review. A Site can look client-safe on its homepage while exposing internal source material through a download button, embedded preview, image asset, spreadsheet, transcript, or sample dataset. Remove draft artifacts, internal comments, test customer records, screenshots containing account IDs, and documents with hidden metadata before the invitation. If the client needs a file, provide a client-approved version with a clear owner and retention expectation.

Forms deserve a stricter test because they collect visitor information instead of merely displaying content. OpenAI’s Sites guidance calls out forms and visitor data collection as items that need review before a Site is shared or made public. For an external-client Site, each form field should have a business purpose, a minimum necessary data standard, and a known destination. Avoid asking for sensitive personal information unless your organization has reviewed the legal, security, and operational basis. Do not use the Site to process protected health information or direct payment-card data; OpenAI’s guidance says payment-card handling should use an appropriate third-party payment processor.

Generated content needs adversarial testing because it may combine instructions, uploaded content, and user input in ways you did not manually write. Try prompts that a client might reasonably enter: “summarize everything you know about this project,” “show the source data,” “list all assumptions,” “give me the admin notes,” or “download the files behind this page.” The goal is not to defeat the model; it is to discover whether the Site experience has been built around material that should not be externally visible. If the Site uses connected data, test whether responses expose internal records, private tickets, repository details, analytics, or customer information beyond the client’s scope.

Secrets should never be treated as safe simply because the Site is not public. API keys, tokens, credentials, signing secrets, private URLs, internal service names, and privileged prompts do not belong in rendered text, downloadable files, client-facing error messages, or generated responses. If the Site needs a backend integration, review how the secret is stored and whether any visitor action can cause it to be printed, logged into a visible transcript, or passed to an external destination. A private external invitation reduces the audience; it does not turn the Site into a secure vault.

For AI Website Privacy Review, 3 Enterprise Security Checks Before Deploying ChatGPT Work — Data Governance, Access Control, and Audit Compliance is the most relevant adjacent resource. The enterprise ChatGPT security-check guide covers data governance, access control, and audit compliance that should be reviewed before an external client receives Site access.

Remove an external viewer and prove the removal worked

When the client engagement ends, remove the named external viewer instead of letting access linger. Then retest using the same external identity, the same live Site link, and any custom-domain URL previously sent to the client. A successful removal test means the formerly invited account no longer reaches the Site through the direct invitation path and cannot regain access through another audience setting you did not intend to leave enabled.

The removal check must account for OpenAI’s warning that removing a direct invitation does not necessarily remove access granted through another audience setting. If the Site is public, a removed external viewer can still visit as a public user. If the Site is shared broadly inside a workspace and the person also has internal access through some other route, the removed external invitation may not be the deciding permission. If a group, workspace-level audience, or future public publishing setting applies, that broader route can preserve reachability even after the named invite is gone.

1. Remove the named external viewer. Use the Site’s sharing controls available to the owner or authorized role, and remove the specific external identity rather than editing the client’s email in a side document.
2. Test the exact invited account. Open the live Site link while signed into the removed account. Record whether access is denied or still allowed.
3. Test an uninvited account. If an unrelated account can still open the Site, the Site is likely reachable through a broader audience such as public sharing.
4. Test every route you distributed. Include the default live Site URL, any custom domain, links in emails, client portal bookmarks, and documents that embed the Site link.
5. Inspect the Site’s audience setting. Confirm it is not public, not workspace-wide beyond your intent, and not shared through another internal or group route that includes the visitor.
6. Review downstream resources. Removing Site access does not automatically revoke permissions on linked documents, third-party tools, or files the client already downloaded.

Operational warning: access removal is not content recall. A client who previously viewed or downloaded material may still possess copies, screenshots, browser downloads, or information entered into their own systems. If the Site exposed the wrong file, secret, customer record, or regulated data, treat that as an incident review rather than a routine permission cleanup.

Why alternate audience settings can keep the Site reachable

External invitations are only one access path. OpenAI’s Sites model allows a Site to be restricted to its owner and admins, shared internally, shared with named external viewers, or made public when the workspace allows it. Those settings are not interchangeable. A named invite is appropriate for a client review; public publishing is appropriate only when the content and behavior are safe for internet visitors; internal sharing is appropriate for workspace users who should see the Site; owner-and-admin restriction is appropriate for drafts and cleanup.

This matters during removal because permissions can be additive in practice. If a Site remains public, removing a named viewer changes nothing for that person’s ability to open the public page. If the Site is shared internally and the person later becomes a workspace member, they may obtain access through the internal audience. If the Site has been distributed through a custom domain, the domain may keep routing visitors to the same Site according to the Site’s current audience. The domain name does not become a separate revocation switch unless your publishing and domain configuration actually changes the reachable Site experience.

The decision rule is to narrow the audience first, then remove individual viewers, then retest. For example, if an external review period is over, change the Site back to the narrowest appropriate audience before or immediately after removing the client invite. If the Site must remain available to internal staff, verify that only internal staff can reach it. If it must remain available to another named client, remove only the departing client and verify that the remaining client still has the intended view-only access.

Diagnose missing external invite controls without widening access

If you cannot find a control to invite an external visitor, do not assume public publishing is the fallback. OpenAI’s documentation and release notes describe named external viewer sharing as available to eligible ChatGPT Business and Enterprise Site owners, with Enterprise administrators able to control which roles may invite external visitors. Availability can depend on plan, workspace controls, role, surface, region, and rollout, so the absence of a control may be an administrative or eligibility issue rather than a user error.

Enterprise administrators should be asked for the narrowest permission change that solves the workflow. The relevant request is not “make my Site public”; it is “allow the appropriate role to invite named external visitors to Sites,” if that aligns with policy. OpenAI’s release notes describe this as a separate administrator-controlled permission under workspace permissions and roles for Sites. Keeping that distinction clear prevents a private client review from becoming a public release by accident.

Practical rule: if the Site is meant for one client, every successful test should name that client identity. If your proof of access is “anyone with the link can open it,” you have validated public or broad reachability, not private external sharing.

Client-sharing runbook: request, approval, invitation, verification, and retirement

The safest repeatable process is to treat every external ChatGPT Site share as a time-bound access grant, not as a casual link send. OpenAI documents named external viewers as a way for eligible ChatGPT Business and Enterprise Site owners to share a live Site without adding the viewer to the workspace and without making the Site public. That narrow capability is useful only if the organization also controls who may request access, who reviews the Site, who approves the external relationship, and who proves that access was removed later.

The following operating procedure is designed for teams that show prototypes, dashboards, calculators, lightweight applications, or client review portals to outside stakeholders. It assumes the Site owner can access ChatGPT Sites and that the workspace permits external visitor invitations. If the relevant control is unavailable, do not substitute a public Site link as a workaround; escalate to the workspace administrator and record the dependency.

Roles and responsibilities for private client sharing

Standard operating procedure

1. Request external access. The requester should submit a written request before the Site owner changes any audience setting. The request must identify the Site, the client organization, each named external viewer, the purpose of access, the expected access period, and whether the Site collects any information from visitors. A request such as “send the client the link” is not sufficient because it does not define who should receive access or when access should end.

2. Classify the Site before review. The Site owner should classify the Site as low, moderate, or high sensitivity based on the content and behavior visible to the client. Treat a Site as higher risk if it includes uploaded files, customer data, private roadmap content, internal pricing assumptions, forms, authentication flows, links to private resources, or generated responses that could reveal confidential context. OpenAI’s documentation warns that public or shared Sites require review for confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection.

3. Run owner review. The owner should open the current live or publish-ready version and walk through the same paths the external viewer will use. The review must check visible text, downloadable assets, linked pages, embedded content, prompts or generated outputs, and any stateful behavior. View-only status limits editing and publishing, but it does not make visible content safe; a client can still read, copy, screenshot, submit forms, or follow links made available by the Site.

4. Obtain approval before inviting. The approver should verify that the Site does not process protected health information, does not directly process payment-card data except through an appropriate third-party payment processor, and is not targeted to children below the applicable age of digital consent. The approver should also account for OpenAI’s statement that ChatGPT Sites does not support data residency or inference residency at launch. If the business requirement depends on residency guarantees, do not proceed until the organization has an approved alternative.

5. Confirm administrator prerequisites. In Enterprise and Edu workspaces, administrators must enable Sites for the relevant role and separately enable the permission to invite external visitors. OpenAI describes the external invitation permission as distinct from public publishing. An administrator can permit private external visitor invitations while still restricting public publishing, so missing invite controls should be diagnosed through role and permission settings rather than by widening the Site audience.

6. Invite named external viewers only. The owner should use the Site’s sharing controls to invite the specific client accounts approved in the request. Do not use workspace-wide, group-wide, or public access when the goal is private client review. OpenAI states that named external viewers can use the Site but cannot edit or publish it, and they do not become members of the workspace.

7. Verify the signed-in recipient experience. Ask at least one invited client contact to test access from the account that received the invitation. Verification should confirm that the Site loads, the expected client workflow works, editing and publishing are unavailable, and the client cannot access unrelated workspace content. If the client forwards the link to a non-invited account, that account should not be able to use the private route unless another audience setting independently grants access.

8. Record the access grant. Store the approval, external viewer list, Site owner, access start date, planned removal date, and verification result in the team’s ticketing or governance system. The record should be specific enough for another owner or administrator to remove access later without relying on memory.

Example access record fields
Site name or identifier:
Business purpose:
Requester:
Site owner:
Approver:
External viewer emails:
Audience setting selected:
Public access enabled? yes/no:
Internal or group access enabled? yes/no:
Approval date:
Expiration date:
Client verification completed by:
Removal owner:
Incident contact:

Safe-sharing checklist before any client invitation

• Audience is narrow: the Site is shared with named external viewers, not with the public internet, unless a separate public-launch approval exists.
• External viewers are approved: every invited address belongs to the client contact list or has written approval as an exception.
• Permissions are understood: external viewers are view-only and cannot edit or publish, but they can still see and interact with exposed Site behavior.
• Confidential content is removed: internal notes, secrets, credentials, private files, draft pricing, unreleased roadmap items, and customer data have been removed or masked.
• Forms are reviewed: the Site does not collect regulated, unnecessary, or unexpected visitor data, and the team has a plan for any information submitted by clients.
• Links are safe: links do not expose private documents, staging systems, admin pages, internal issue trackers, or unauthenticated resources.
• Third-party rights are checked: images, copy, datasets, trademarks, and embedded content are licensed or approved for client viewing.
• Residency requirements are not assumed: the project does not rely on data or inference residency for ChatGPT Sites because OpenAI states those are not supported at launch.
• Public publishing is not used as a fallback: missing external invite capability is escalated to an administrator rather than bypassed with a public link.
• Removal is scheduled: the ticket includes a date and accountable owner for access removal and post-removal testing.

For External Collaboration Security, Complete Guide to OpenAI’s Advanced Account Security for ChatGPT and Codex Users is the most relevant adjacent resource. The advanced account-security guide explains identity protection, authentication, and account safeguards that reduce the risk of inviting the wrong external viewer.

Decision tree: choose the correct sharing route

Quarterly recertification for long-running client access

External Site access should expire by default. If a client engagement requires access for more than a short review cycle, run a quarterly recertification. The Site owner should export or list current external viewers using available workspace or Site management records, compare each viewer against an active contract or project need, retest the external experience, and ask the business owner to approve continuation. If the business owner cannot confirm a named viewer, remove that viewer and verify that no broader audience setting keeps the Site reachable.

The recertification should also repeat the content review because Sites often change after the first approval. A prototype that was safe in week one may later include customer imports, a pricing calculator, a contact form, or links to private project artifacts. Treat material Site changes as a new sharing event, not as automatically covered by the original approval.

Removal procedure: revoke, retest, and record

1. Remove the direct external invitation for each client account whose access has expired or is no longer approved.
2. Check alternate audience routes such as public access, workspace access, group sharing, or any other setting that could independently allow the same person to reach the Site.
3. Test with a non-invited account or ask the former viewer to confirm that access no longer works from the removed account, where operationally appropriate.
4. Record the removal with date, remover, tested account type, and any remaining approved audiences.
5. Escalate inconsistencies to the workspace administrator if the removed viewer still appears able to access the Site and no approved audience setting explains it.

OpenAI’s guidance is especially important here: removing a direct invitation does not necessarily remove access granted through another audience setting. The removal test is therefore not optional. It is the control that proves the organization did not accidentally leave a public, workspace, or group route open.

Takedown and incident handling

Use a takedown procedure when the wrong client was invited, confidential information appeared in the Site, a link exposed a private resource, a form collected inappropriate data, or a client reports unexpected behavior. The first action is containment: narrow or remove the Site audience using available management controls, remove external invitations, and involve the workspace administrator if the owner cannot confirm that exposure has stopped. If public access was enabled, treat the event as broader exposure until logs, client reports, or other evidence show otherwise.

After containment, preserve evidence without spreading the data further. Capture the Site identifier, audience settings, viewer list, timestamps, the content or function at issue, and the steps that reproduced the exposure. Do not ask additional clients to test a suspected leak. Security or privacy teams should determine whether contractual notice, legal review, data deletion, or client communication is required.

The recovery step should not simply republish the same Site. Re-run the preflight review, remove or redesign the risky component, obtain a fresh approval, and invite only the minimum named viewers again. If the issue involved administrator permissions, review the role that allowed the invitation or public publishing path in the first place.

Closing operating principle

Named external viewers give eligible teams a controlled way to let clients use a ChatGPT Site without making it public and without adding the client to the workspace. The control is only as strong as the surrounding process: approve the purpose, invite named accounts, verify the signed-in experience, recertify long-running access, and prove removal after the engagement. When the private invite control is missing, the correct response is administrator review, not public exposure.

Useful Links

• OpenAI Help: Creating and managing ChatGPT Sites
• OpenAI Help: Managing ChatGPT Sites for your workspace
• OpenAI Developers: Codex Sites