ChatGPT Sites Security and Privacy Guide: Access Controls, Secrets, Data Residency, and Safe Publishing

Start with the trust boundary: a ChatGPT Site is not just a document

ChatGPT Sites changes the security review problem because the output is an interactive hosted website or lightweight application, not only a static draft that someone proofreads before sending. OpenAI documents Sites as a public-beta feature for creating, previewing, publishing, and sharing Sites from ChatGPT Work on the web, and from Work or Codex in the desktop app. That means the security boundary includes the generated interface, the published URL, the selected audience, any uploaded files or embedded assets, any form fields presented to visitors, any authentication behavior built into the Site, links to third-party services, and any data or secrets the Site can access during operation.

The safest mental model is to treat each Site as a small production application with a public or semi-public attack surface. A typo in a headline is a content defect; a hardcoded access token, an overly broad audience setting, an unreviewed form collecting personal data, or a link that sends users to the wrong third-party service is an application-security and privacy defect. The Site owner should therefore run a launch review that covers confidentiality, access control, data collection, data residency, third-party rights, and takedown readiness before publishing or widening the audience.

OpenAI’s Sites documentation separates creation and sharing from workspace administration. A creator can build and preview a Site, but whether it can be shared internally, shared with named external viewers, or published publicly depends on the workspace plan and the controls set by administrators. OpenAI states that Business Sites are enabled by default, while Enterprise availability and public publishing are controlled through role-based access controls. For security teams, that distinction matters: a secure design cannot rely only on individual author judgment if the workspace also permits broad publishing by roles that have not been trained to review hosted applications.

For ChatGPT Sites Build and Deploy, How to Use ChatGPT Sites to Build and Deploy Web Apps Without Code in 2026 is the most relevant adjacent resource. The ChatGPT Sites build-and-deploy tutorial provides the application lifecycle context that precedes the access, secrets, data, and publication controls examined here.

The production deployment model: preview, publish, share, and revise

A practical Sites governance model should recognize four operational states. First, the Site is being drafted or previewed, where the primary risk is accidental inclusion of confidential files, internal notes, unreleased product names, source material, or credentials. Second, the Site is published to a live environment, where visitors can interact with the delivered interface according to the configured audience. Third, the audience is widened or narrowed, which changes who can reach the same live behavior without necessarily changing the code. Fourth, the Site is revised after publication, where a harmless-looking content update can introduce new fields, links, assets, prompts, or dependencies that need a fresh review.

For founders and marketing teams, the “publish” step can feel like sending a landing page live. For enterprise administrators and security teams, it is closer to deploying a small application to managed hosting. The review should ask whether the Site reveals customer names, roadmap information, internal documentation, non-public pricing, unreleased screenshots, support exports, uploaded contract language, or private analytics details. The reviewer should also test what a visitor can do, not only what the page says, because an interactive component may collect inputs, trigger workflows, or direct visitors to external services.

OpenAI’s public-beta framing is also part of the deployment model. Public beta should not be read as a waiver for normal production controls; it is a reason to be more deliberate about change management, review evidence, and rollback planning. Teams should assume product behavior, controls, and administrative surfaces may continue to evolve, and they should avoid building compliance-critical processes that depend on undocumented behavior. A Site that is safe for a temporary client demo may not be appropriate for regulated intake, sensitive customer support, payment collection, or children-directed experiences.

Operational rule: if a ChatGPT Site will be visited by anyone outside the authoring team, review it as a deployed application. A content proofread is necessary, but it is not sufficient.

Audience options define reach, not total risk

OpenAI documents several audience patterns for live Sites: a Site can be restricted to its owner and administrators, shared internally, shared with named external viewers, or made public when the workspace allows public publishing. These settings define who can reach the live Site through the platform’s sharing model. They do not prove that every piece of content, every linked service, every form, and every embedded file is safe for that audience. A view-only external viewer cannot edit or publish the Site, but that viewer can still see the Site’s content and interact with the visitor-facing experience made available to them.

Named external viewers are important because OpenAI states that eligible ChatGPT Business and Enterprise Site owners can share live Sites with named external viewers without adding those viewers to the workspace or making the Site public. OpenAI further states that these external viewers can use the Site but cannot edit or publish it. Enterprise and Edu administrators must enable Sites for the relevant role and separately enable permission to invite external visitors. In release-note language, administrators can control which roles may invite external visitors through Workspace settings, Permissions & roles, Sites, and the separate “Allow members to invite external visitors to sites” permission.

This creates a useful middle ground for client review, partner demos, agency approvals, or executive sign-off: the Site does not need to be public, and the external reviewer does not need to become a workspace member. However, it also creates a governance obligation. The owner should record why each external viewer needs access, what version they reviewed, what data they could see, and when the access should be removed. Administrators should periodically test whether external visitors retain access through another audience path, because OpenAI notes that removing a direct invitation does not necessarily remove access granted through another audience setting.

Owner, editor, and administrator responsibilities must be explicit

The Site owner is the person most likely to understand intent, source material, and the expected audience. That makes the owner accountable for the first-pass risk inventory: what information was used to build the Site, what files were uploaded, what outputs were generated, what forms or inputs visitors will see, what third-party content appears, and what links or integrations are presented. The owner should not delegate this entirely to a legal or security reviewer, because reviewers cannot reliably identify missing context such as “this screenshot came from an unreleased dashboard” or “this customer quote is not approved for public use.”

Editors need a different control mindset. An editor may be improving copy, fixing layout, adding a case study, changing a form, or preparing a public launch update. Each of those changes can alter the risk profile. A copy edit can reveal a confidential roadmap item; a layout change can expose an uploaded asset; a form addition can create a new personal-data collection point; a link update can send visitors to a vendor page with a different privacy policy. Teams should document when an editor may change draft content, when an editor may publish later revisions, and when an owner or administrator must approve a change before it goes live.

Administrators own the workspace-level guardrails. For Sites, that includes enabling or disabling the feature for roles where applicable, controlling public publishing, and controlling which roles may invite external visitors. Administrators should avoid granting public publishing or external-invitation rights simply because a user can create good content. The better decision rule is role-based: grant publishing authority to roles that have launch accountability, security awareness, and a process for review evidence. If a role is allowed to publish but not trained to recognize secrets, regulated data, children-directed content, or payment-card collection, the workspace is relying on luck rather than governance.

For Enterprise ChatGPT Security Checks, 3 Enterprise Security Checks Before Deploying ChatGPT Work — Data Governance, Access Control, and Audit Compliance is the most relevant adjacent resource. The three-check enterprise security guide focuses on data governance, access control, and audit compliance, reinforcing the minimum controls for a business Site.

Public-beta limits that affect privacy and compliance decisions

OpenAI states that ChatGPT Sites does not support data residency or inference residency at launch. This is a material compliance constraint, not a footnote. If an organization has contractual, regulatory, or internal policy requirements that data remain in a specific geography for storage or model inference, the Site should not be used for that workload unless the organization’s responsible compliance owner determines that the use is permitted despite that limitation. The conservative default is to keep residency-bound data out of Sites until the platform documentation supports the required residency model.

OpenAI’s Sites guidance also identifies categories that require heightened review or should not be handled directly. Public or shared Sites must be reviewed for confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection. 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. These restrictions should be converted into launch checklist gates rather than left as policy text that creators may not read.

Data residency limits also interact with forms. A Site that asks visitors to enter names, business email addresses, account IDs, symptoms, financial details, or support details is no longer just publishing information; it is collecting information. Before allowing any form, the owner should identify the data fields, purpose, retention expectation, audience, whether submission is necessary, and whether another approved system should collect the data instead. If the Site is intended for public marketing, a lower-risk pattern is often to link to an existing approved intake or payment flow rather than recreate sensitive collection inside the Site.

Access controls and in-Site authentication are separate concerns

Audience settings control who can reach the Site through ChatGPT Sites sharing options. In-Site authentication behavior, if included in the Site’s design, is a separate application behavior that must be reviewed on its own. Teams should not assume that a login screen, passcode field, form gate, or role selector inside the Site replaces the platform audience setting. Conversely, they should not assume that a narrow audience setting makes every in-Site data flow safe. The safest review treats platform sharing and application behavior as two layers that can each fail independently.

A concrete example illustrates the distinction. A Site shared only with named external viewers may still display a confidential embedded spreadsheet, a private roadmap screenshot, or a form that asks for sensitive information. The named-viewer setting prevents broad public access, but it does not make the content appropriate for those named viewers. A public Site may include an in-Site “client login” mockup, but if the authentication behavior is not a properly reviewed production identity system, the public audience setting still exposes the interface and any implementation mistakes to the internet.

Why the launch review must go beyond proofreading

A content proofread checks spelling, tone, factual accuracy, brand consistency, and basic user comprehension. A ChatGPT Sites application-security review checks whether the live Site exposes information or functionality that should not be exposed to the selected audience. The review must include at least six questions: who can access the Site, what can they see, what can they submit, where do links or buttons send them, what files or generated artifacts are included, and what should happen if access must be revoked quickly.

Security teams should ask for evidence, not assurances. Evidence can include screenshots of the configured audience, a list of invited external viewers, a record of uploaded files, a form-field inventory, a link inventory, a statement that no protected health information or direct payment-card processing is involved, and a human approval decision by the accountable owner. For public Sites, evidence should also include a takedown path and a retest showing that the published visitor experience matches the approved version.

Founders and marketers can keep the process lightweight by using a severity-based rule. If the Site contains only public marketing copy, public images, no forms, and links to already approved public pages, a short checklist may be enough. If it contains customer-specific material, non-public business information, downloadable files, visitor data collection, third-party content, access gates, or external stakeholder access, it needs a documented review before sharing. If it touches protected health information, direct payment-card handling, children-directed experiences, or residency-bound data, the default answer should be no until qualified legal, privacy, and security owners approve an alternative architecture.

Design identity and data controls before you publish

OpenAI describes ChatGPT Sites as a way to create, preview, publish, and share interactive websites and lightweight applications from supported ChatGPT Work and Codex surfaces, but the security model is not the same as publishing a static document. A Site can have audience settings, code, storage, secrets, forms, uploads, and authentication behavior. Treat those as separate control planes: the audience setting decides who can reach the Site, while the Site’s own server-side logic decides what an authenticated visitor may do once the app is running.

The practical mistake to avoid is assuming that “not public” means “safe for any connected data.” A Site shared with internal users or named external viewers may still expose sensitive information if the application renders it, returns it from an API route, stores it in a downloadable file, or includes it in a client-side bundle. View-only access limits editing and publishing rights, according to OpenAI’s Sites documentation, but it does not sanitize the Site’s content, redact database records, or prevent the app from collecting new visitor data.

Audience settings are reach controls, not application authorization

OpenAI’s documented audience options include restricting a Site to its owner and administrators, sharing internally, sharing with named external viewers, and making the Site public when the workspace allows it. These settings should be selected using a narrowest-necessary rule: start with owner/admin-only during development, move to named internal reviewers for testing, invite named external viewers only when external acceptance testing is required, and publish publicly only after legal, privacy, security, and content reviews are complete.

Named external viewers are useful for client reviews because OpenAI states they can use the Site without becoming workspace members and without receiving edit or publish rights. That makes them appropriate for a customer acceptance test, an agency handoff review, or a partner demo where public release would be premature. It does not make them appropriate for uncontrolled confidential data exposure; the Site owner still needs to review every screen, response, form, link, and downloadable asset that the viewer can reach.

Enterprise and Edu administrators should also account for OpenAI’s separate permission model. Enabling Sites for a role and allowing that role to invite external visitors are distinct administrative choices. If an owner cannot see an expected sharing option, the likely causes include plan eligibility, workspace role controls, public publishing restrictions, surface availability, or rollout state. Do not work around a missing external-viewer control by making a Site public unless the public audience has been approved.

Use Sign in with ChatGPT as identity, then authorize on the server

Sign in with ChatGPT and Site audience settings answer different questions. The audience setting answers “can this visitor reach the Site?” Sign in answers “who is this visitor inside the app?” Authorization answers “what may this identified visitor see or change?” A secure Site uses all three where sensitive functionality exists. For general marketing pages, an audience setting may be enough. For account dashboards, client-specific deliverables, internal tools, or submission review pages, the app should require identity and enforce server-side authorization.

Recommended pattern: require authentication before rendering private pages, read the platform-provided identity information only on the server, map that identity to an application role in your own allowlist or database, and check that role before every protected read, write, upload, export, or administrative action. A hidden navigation item is not an authorization boundary. If a route returns /api/submissions, the handler for that route must verify that the caller is allowed to view those submissions before querying storage.

// Example authorization flow for a protected server route.
// Names are illustrative; use the identity fields documented for your Site runtime.

async function handleSubmissionsRequest(request, env) {
  const identity = getAuthenticatedChatGPTIdentity(request);

  if (!identity) {
    return new Response("Authentication required", { status: 401 });
  }

  const user = await env.DB.prepare(
    "SELECT role, client_id FROM app_users WHERE chatgpt_subject = ?"
  ).bind(identity.subject).first();

  if (!user || user.role !== "reviewer") {
    return new Response("Not authorized", { status: 403 });
  }

  const rows = await env.DB.prepare(
    "SELECT id, created_at, summary FROM submissions WHERE client_id = ? ORDER BY created_at DESC"
  ).bind(user.client_id).all();

  return Response.json(rows.results);
}

For ChatGPT Authentication and SSO, How to Set Up ChatGPT Enterprise for Your Team: Admin Console, SSO, Data Controls, and Model Access Management is the most relevant adjacent resource. The ChatGPT Enterprise setup guide explains admin-console, SSO, data-control, and model-access management, helping readers separate workspace identity from an application’s own sign-in layer.

Treat identity headers as privileged inputs

Where a Site runtime provides identity through request headers or request metadata, treat those values as trusted only at the server boundary where the platform supplies them. Do not copy identity headers into client-side JavaScript and rely on the browser to enforce permissions. Do not accept lookalike headers from a public client request unless the runtime documentation says the platform strips, signs, or injects them in a way your server can trust. The safe design is to use the server runtime’s documented identity object or headers, then convert that identity into a minimal internal authorization decision.

A practical implementation is to store a stable subject identifier from the authenticated identity in an app_users table and keep display names or email addresses as convenience fields, not primary access controls. Email addresses can change, can differ across organizations, and may be reused in test environments. A stable identity-to-role mapping lets you revoke a person’s application privileges without changing the Site audience setting, and it lets you log which authenticated identity performed each sensitive action.

Reserve owner-only and administrator actions for the smallest group

Some Site actions are inherently owner or administrator responsibilities: changing the audience, inviting external viewers, publishing a revised version, reviewing takedown decisions, configuring secrets, and deciding whether a Site may collect visitor data. OpenAI’s Sites documentation distinguishes owner, administrator, editor, viewer, external viewer, and public access concepts; operationally, you should convert those product roles into a written responsibility matrix before launch.

Editors require special attention because editing a live application is not the same as commenting on a draft. If a Site has access to live D1 tables, R2 objects, environment secrets, or server routes, an editor who can change the application may be able to create a page or endpoint that reads that data. Even if the product role is not called “database administrator,” treat editors as privileged data handlers for any resource the Site code can access. Remove editor access when the work is complete, and retest the live Site after permission changes.

Keep environment secrets out of client code and prompts

Environment secrets should be used for server-side credentials such as API keys, database connection details, webhook signing secrets, and service tokens. They should not be pasted into prompts, stored in source files, embedded in front-end JavaScript, printed in logs, returned from debug routes, or included in screenshots sent for review. A public or shared Site can expose any value that the browser receives, so a secret is only secret if it remains on the server side and the server never returns it to the visitor.

Use separate secret values for local development, hosted preview, and production publishing. Local configuration is appropriate for testing against non-production services and seeded sample data. Hosted configuration is the source of truth for the deployed Site and should be reviewed before each publish. Do not assume that a value in a local .env file automatically exists in the hosted environment, and do not assume that deleting a local file rotates a deployed secret. Rotation should be an explicit operational step in the upstream service and in the Site’s hosted configuration.

# Example local-only configuration pattern.
# Do not commit this file and do not paste real values into prompts or tickets.

CHATGPT_SITE_ENV=local
DATABASE_NAME=sample_reviews_dev
NOTIFICATION_WEBHOOK_URL=https://example.invalid/dev-webhook
UPLOAD_BUCKET=sample-uploads-dev

Recommended secret-control procedure: inventory every external service the Site calls, identify which credential is used, confirm whether the credential is scoped to read-only or write access, store it only in the appropriate environment configuration, test that the browser bundle does not contain it, and rotate it after removing a privileged editor or after any accidental exposure. If a Site no longer needs a service, remove the secret instead of leaving unused credentials available to future code.

Choose D1 for structured records and R2 for objects

For Sites that use the storage options documented for the platform, use D1-style relational storage for structured application records and R2-style object storage for binary or large unstructured objects. A form submission, reviewer status, user-to-client mapping, consent timestamp, audit event, or upload metadata record belongs in a relational table. A PDF, image, spreadsheet, ZIP archive, or generated file belongs in object storage, with its object key and metadata referenced from the database.

This split improves security review because the database can enforce predictable fields and query scopes while object storage can be handled with separate naming, retention, and download rules. For example, store submission_id, owner_subject, created_at, declared_file_type, and r2_object_key in D1, then keep the actual uploaded file in R2. The server route should verify that the authenticated visitor is allowed to access the submission before generating or returning any object download.

Do not treat D1 or R2 as a data-residency solution for regulated deployment requirements. OpenAI states that ChatGPT Sites does not support data residency or inference residency at launch. If your organization requires regional processing guarantees, customer-specific residency commitments, or regulated workload isolation, that limitation must be resolved before the Site collects or processes the data. Moving a file from a form into object storage does not change the residency limitation stated for Sites.

Design forms for minimum collection, not maximum convenience

Every form field should have a purpose, an owner, a retention period, and a display rule. If a visitor is registering interest in a webinar, the Site may need a name, business email, company, and consent checkbox; it probably does not need a home address, government identifier, date of birth, or free-text medical details. OpenAI’s Sites guidance warns that public or shared Sites should be reviewed for forms and visitor data collection, and it specifically rules out processing protected health information or payment-card data except through an appropriate third-party payment processor.

Use explicit field labels and short help text to prevent accidental sensitive disclosures. A free-text field labeled “Tell us about your issue” can attract confidential customer data, credentials, health information, or payment details. A safer version is “Describe the business problem. Do not include passwords, payment-card numbers, health information, or confidential customer records.” This wording does not guarantee compliance, but it gives visitors a clear instruction and gives reviewers a concrete control to verify.

// Example minimum form schema for a client demo request.
// Avoid collecting sensitive data unless there is a reviewed business need.

{
  "name": "Required; business contact name",
  "email": "Required; business email for follow-up",
  "company": "Optional; organization name",
  "use_case": "Required; short non-confidential description",
  "consent_to_contact": "Required; true/false",
  "created_at": "Server-generated timestamp"
}

Constrain visitor uploads before you accept them

Visitor uploads create a larger risk surface than ordinary form fields because files may contain malware, hidden metadata, confidential third-party content, personal information, or copyrighted material the visitor is not allowed to provide. Before enabling uploads, define the allowed file categories, maximum expected size, business purpose, retention period, reviewer role, and deletion process. If the Site does not have a clear need to receive files, do not add an upload control merely because it is convenient.

Recommended upload workflow: accept only documented file types needed for the use case, store the object outside the public web path, create a database metadata record, require server-side authorization before download, show reviewers a warning that uploaded files are untrusted, and delete files automatically or manually according to the published retention rule. Do not accept executable files, credential exports, raw customer databases, health records, or payment-card images through a general-purpose Site upload form.

Apply data minimization to publishing decisions

Data minimization is the strongest privacy control available to most Site owners because it reduces what can be exposed, mishandled, retained, or requested later. Before publishing, remove sample data that resembles real customers, delete unused form fields, replace full records with summaries where possible, avoid displaying raw identifiers, and use aggregate counts instead of row-level detail for public pages. A public case-study Site rarely needs live lead records; a client review portal rarely needs records for clients other than the one currently signed in.

Operational rule: if a Site can meet its business purpose without collecting, storing, displaying, or exporting a data element, remove that data element before launch.

The final identity-and-data review should be performed with accounts that match the real audience: owner, editor, internal viewer, named external viewer, unauthenticated visitor, and public visitor if public publishing is enabled. For each account, test direct URLs, API routes, form submission, upload, download, error messages, and revision publishing. Record the result, the reviewer, the date, and any residual risk accepted by the owner. This evidence is more useful than a general statement that the Site “looked fine” in preview.

Residency, prohibited data, and publish-risk classification

OpenAI states that ChatGPT Sites does not support data residency or inference residency at launch. That single constraint should drive the first compliance decision for any Site: if your policy, customer contract, regulator, or procurement checklist requires prompts, uploaded files, generated Site content, visitor submissions, logs, or model inference to stay in a specified geography, do not treat Sites as satisfying that requirement unless OpenAI later documents support for the exact residency scope you need.

Operational rule: classify a Site as “not residency-bound” only after confirming that no legal, contractual, sector-specific, or customer-imposed residency requirement applies to the Site’s source materials, generated code, published assets, form submissions, analytics events, authentication flows, support records, and review logs.

Residency is not only about where a published page is served. For Sites, the relevant review surface includes the materials used to create the Site, the interactions used to revise it, the deployed application behavior, any stored records, and any visitor-submitted data. A marketing microsite built from public copy has a different residency profile from a customer onboarding portal that accepts identity documents, even if both are published under the same workspace and domain strategy.

For AI Data Residency Guide, How to Build Enterprise Data Loss Prevention Policies for ChatGPT and Codex: Complete Implementation Guide is the most relevant adjacent resource. The enterprise data-loss-prevention guide shows how to classify sensitive information and prevent unauthorized movement, complementing this guide’s caution about residency guarantees and visitor data.

Do not use Sites for PHI or direct payment-card processing

OpenAI’s Sites guidance says public or shared Sites must not process protected health information or payment-card data except through an appropriate third-party payment processor for payment-card handling. This is not a wording nuance: a Site that asks a patient to describe symptoms, upload lab results, enter insurance identifiers, or submit medication history is materially different from a public hospital cafeteria menu or a generic wellness landing page.

For health-related content, separate general information from protected health information before build begins. A public FAQ explaining office hours, appointment categories, or insurance-plan names may be acceptable after ordinary content and privacy review; a triage form that collects symptoms, diagnoses, appointment notes, images of rashes, member IDs, or clinician messages should be blocked unless your legal, privacy, and security teams have an OpenAI-supported path that covers PHI handling. Do not rely on “the form is only visible to invited users” as a substitute for a PHI processing review.

For payment-card data, the safer design is to redirect payment capture to a compliant third-party payment processor and keep card numbers, CVV values, magnetic-stripe data, and raw card images out of the Site. A Site may describe pricing, packages, refund rules, and next steps, but the checkout action should hand off to the payment processor rather than rendering a custom card-entry form inside the Site. If your team cannot prove where card data is entered, transmitted, stored, logged, and redacted, the Site should not launch.

Exclude children below the applicable age of digital consent

OpenAI’s guidance also says Sites must not target children below the applicable age of digital consent. The practical test is broader than whether the word “kids” appears on the page. Review imagery, language level, characters, rewards, classroom use, school distribution plans, advertising audience settings, form fields, and analytics tags to decide whether the Site is directed to children or likely to collect data from them.

If a Site supports education, youth sports, games, tutoring, camps, toys, or family services, require an explicit age-and-audience decision before publishing. A Site for parents to review camp logistics may be lower risk if it avoids child account creation and child data collection; a quiz, game, homework helper, or profile builder designed for children needs a separate legal and privacy pathway. Do not use custom domains, social sharing, or playful branding to route around age restrictions.

Ban malware, phishing, impersonation, and rights-infringing content at the review gate

A Site can be a website, a lightweight application, a form, a prototype, or a public-facing workflow, so abuse review must look at behavior rather than format. Block any Site that distributes malware, encourages credential theft, imitates another organization without authorization, tricks visitors into revealing secrets, or uses confusing branding to make a visitor believe the Site is operated by a different entity.

Phishing risk is especially high when a Site combines a familiar brand, a custom domain, a sign-in prompt, and a form asking for credentials, access tokens, recovery codes, payroll details, invoices, or bank information. The reviewer should test every call to action and ask: “Would a reasonable visitor understand who operates this Site, what data is being requested, why it is needed, and where the action sends them?” If the answer depends on hidden context from an internal chat, the Site is not ready for external distribution.

Impersonation review should cover names, logos, product screenshots, employee likenesses, customer names, partner badges, testimonials, and support contact details. A prototype that says “Acme Bank Login” can create legal and security risk even if the underlying form is nonfunctional, because visitors may bookmark, share, screenshot, or trust the URL. Require documented permission for third-party marks and remove real login language from demos unless the identity, purpose, and authorization are unambiguous.

Third-party rights review must also cover copied articles, documentation excerpts, icons, fonts, product imagery, embedded videos, datasets, customer screenshots, and generated assets that resemble protected material. A Site owner should be able to identify the source and permitted use for every non-original asset before the Site becomes public or is shared with external viewers. If the source cannot be verified, replace the asset or keep the Site owner-only until rights are cleared.

Public URLs create distribution risk even when the Site feels temporary

OpenAI documents Sites as supporting multiple audience states, including owner/admin-only, internal sharing, named external viewers, and public access when the workspace permits it. A public URL should be treated as internet distribution, not as a private preview link. Public means the content, forms, scripts, files, visible metadata, and linked destinations can be copied, indexed, forwarded, archived, screenshotted, or inspected by people outside the intended audience.

Named external viewers reduce reach compared with public publishing, but they do not eliminate exposure risk. External viewers can use the Site in view-only mode, and OpenAI states they do not become workspace members or receive editing and publishing rights. However, view-only access still reveals whatever the Site displays, downloads, collects, links to, or computes. A confidential pricing calculator, customer-specific demo, or partner roadmap may remain sensitive even if no recipient can edit it.

Public URLs also change incident response. If a Site accidentally exposes confidential content, the team needs a takedown path, a decision on whether cached copies or downstream shares matter, and a record of when the URL became available. For higher-risk launches, capture the final audience setting, URL, owner, approver, timestamp, and rollback contact before publishing. That evidence makes later privacy, legal, and security reviews faster and less dependent on chat history.

Analytics and visitor measurement require their own privacy review

Analytics can turn a simple brochure Site into a data-collection system. Before adding measurement, define exactly what will be collected: page views, referrers, device attributes, campaign parameters, form abandonment, click events, free-text searches, IP-derived location, account identifiers, or custom user properties. The privacy impact is very different for aggregate page counts than for event streams tied to named visitors or external client accounts.

For ChatGPT Privacy Controls, How to Implement ChatGPT’s Dreaming Memory System in Enterprise Workflows: Architecture, Personalization Patterns, and Privacy Controls is the most relevant adjacent resource. The enterprise memory and privacy architecture guide demonstrates how personalization and privacy controls must be designed together rather than inferred from a product name.

Analytics tags can also leak sensitive content through URLs, event names, button labels, form-field names, query strings, and referrer headers. A safe pattern is to use neutral event names, avoid sending free-text form content to analytics tools, strip secrets and identifiers from URLs, and test the network traffic generated by each page before launch. If a reviewer cannot inspect what is being transmitted, the Site should not be classified as low risk.

Custom domains increase trust, brand, and abuse obligations

Custom domains can make a Site feel official, which is useful for legitimate campaigns and dangerous for confusing prototypes. Before attaching a domain or subdomain, verify that the organization owns or is authorized to use it, that the name does not imitate a third party, and that the domain inventory identifies the business owner, technical owner, expiration path, and takedown contact. A forgotten campaign subdomain can become a long-lived trust surface after the original launch team moves on.

Use naming conventions that match the Site’s purpose. A temporary client demo should not use a production-like login domain unless it has the same security, privacy, and support posture as production. A public policy explainer may fit a marketing subdomain; an internal tool should not be moved to a public-looking domain simply because it is easier to share. Domain choice is a user-interface security control because it shapes visitor assumptions before the page loads.

Storage limits, quotas, and retention assumptions must be part of design

OpenAI’s Sites developer documentation describes storage capabilities and limits for Sites. Because those limits are part of the product boundary, do not design a Site as if it has unlimited database rows, object storage, uploaded file capacity, request volume, or retention. Confirm the current documented limits during design and again before launch, especially while Sites remains a public-beta capability with availability and behavior subject to workspace controls and documented constraints.

Storage-limit planning is a security and privacy issue, not only an engineering issue. When a form, upload feature, or generated report reaches a limit, the Site should fail predictably: reject the submission, show a clear message, avoid partial writes, and avoid exposing another visitor’s data through error handling. Do not let quota pressure push developers into client-side workarounds such as embedding private data in page code, URLs, browser storage, or downloadable files.

Retention planning should define what records are stored, why they are stored, who can retrieve them, how long they remain useful, and how deletion requests will be handled. If the Site is only a launch-week campaign, the safest storage plan may be no persistent visitor data at all. If the Site collects leads or support requests, route records into the approved system of record instead of allowing a prototype database to become an unmanaged customer-data store.

Do not design around unsupported private networks or background services

Sites should not be treated as a replacement for a private application platform, intranet service, VPC-hosted backend, long-running worker, job scheduler, or daemon process unless OpenAI explicitly documents support for that architecture. If the workflow depends on reaching a private database, internal admin panel, enterprise resource planning system, or non-public API, place that logic behind an approved backend that handles authentication, authorization, logging, and network access under your normal controls.

Background processing deserves a separate rejection test. If a Site needs to poll systems continuously, process queues, send scheduled reminders, run nightly reconciliations, transform large files after upload, or maintain persistent connections, move that work to infrastructure designed for background jobs. The Site can still serve as the front end, but the durable processing should happen in a service with monitored execution, retries, secrets management, audit logs, and operational ownership.

Private-network shortcuts are also dangerous during demos. A developer may be tempted to expose an internal API temporarily so a Site can fetch data for an executive review. Treat that as a production exposure unless the network, identity, logging, and data-minimization controls have been approved. “Temporary” public connectivity has the same breach potential as permanent public connectivity during the time it exists.

Apply a risk-based classification before every publish or audience expansion

Every Site should receive a risk classification before first publication and again before any audience expansion, custom domain attachment, new form, analytics tag, upload feature, authentication change, or external viewer invitation. The goal is not bureaucracy; it is to prevent a harmless internal prototype from silently becoming a public application that collects regulated or confidential data.

A useful classification record should be short enough that teams actually complete it, but specific enough to be auditable. Capture the Site name, owner, URL, intended audience, data collected, storage used, analytics used, custom domain status, third-party assets, prohibited-data decision, residency decision, approval names, and next review date. If a Site changes materially, update the record before changing the audience setting.

Recommended classification record

site_name: "Customer Summit Agenda"
owner: "Marketing Operations"
audience: "Public"
custom_domain: "events.sample.test"
forms_or_uploads: "No uploads; newsletter form routes to approved marketing system"
analytics: "Approved aggregate page and campaign measurement; no free-text capture"
regulated_data: "No PHI, no payment-card data, no child-directed content"
residency_requirement: "None identified by campaign owner and privacy reviewer"
third_party_rights: "Speaker headshots and sponsor logos approved for event use"
risk_class: "Moderate"
approvers:
  - "Marketing owner"
  - "Privacy reviewer"
  - "Security reviewer"
rollback_contact: "Web operations on-call"
next_review: "Two weeks after event close"

The most important habit is reclassification after change. A Site that begins as a static agenda becomes a different risk object when someone adds a sponsor lead form, embeds analytics, attaches a custom domain, invites external viewers, or publishes the URL broadly. Make audience expansion and feature addition deliberate security events, not incidental editing steps.

Governance lifecycle for safe ChatGPT Site publishing

A ChatGPT Site needs a lifecycle because the risk changes every time the Site moves from draft to preview, from preview to published, from owner-only to shared, or from internal to public. OpenAI documents Sites as a way to create, preview, publish, and share interactive websites and lightweight applications, and the same documentation makes clear that audience settings, workspace permissions, external viewer invitations, and publishing rights are separate governance decisions. The practical rule is simple: no Site should be treated as “approved” forever just because its first publish was approved once.

Recommended governance model: manage each Site as a small production application, not as a static page. A launch record should identify the owner, intended audience, data collected, uploaded files used, environment secrets, storage components, external links, third-party content, custom domain status, and prohibited-data screening outcome. That record becomes the baseline for later editor changes, audience expansions, external invitations, incident response, takedown, and permanent deletion.

Operational warning: OpenAI states that ChatGPT Sites does not support data residency or inference residency at launch. If a business process requires regional processing or storage guarantees, do not approve the Site for that process unless another approved architecture supplies the required controls outside Sites.

Lifecycle stages and required control gates

Creation and ownership gate

At creation, the accountable owner should document why a Site is needed instead of a document, form, internal app, or conventional web property. This decision matters because Sites can contain interactive behavior, visitor-facing forms, uploaded files, links, and storage-backed features. A marketing microsite with public product copy has different controls from an internal sales calculator that accepts customer attributes, and both are different from a client-facing prototype shared with named external viewers.

The owner should also identify whether the Site is being created in Work on the web or from Work or Codex in the desktop app, because OpenAI’s Sites documentation describes those as supported creation surfaces. The governance record should not assume that a draft created in one experience has the same review history as a Site revised elsewhere. If several collaborators participate, the owner remains accountable for the published result and should not delegate approval simply because another editor made the last change.

Review before version saving and first publish

The review gate should examine the Site as a running application. Reviewers should click through forms, error states, navigation paths, authentication prompts, storage-backed views, links, downloads, and any content generated or imported during creation. A text-only review is inadequate when the Site can collect visitor input, expose uploaded files, or direct users to third-party systems.

For AI Application Governance Framework, OpenAI’s Frontier Governance Framework Explained: What Enterprise AI Teams Need to Know in 2026 is the most relevant adjacent resource. The Frontier Governance Framework explainer supplies a broader risk-assessment model for deciding which Sites require formal review, restricted data, or escalation.

Later editor changes and version discipline

Later editor changes are where most drift occurs. A Site that was approved as internal-only may later gain a form, a customer logo, a new third-party script, a download link, or a public audience. The governance rule should distinguish low-risk edits from review-triggering edits. Correcting a typo in approved copy can be logged by the owner; adding a form field for email addresses, changing authentication behavior, adding a storage-backed feature, or replacing internal placeholder data with customer data should trigger a new review.

Recommended change rule: require a new saved version and approval whenever a change affects audience, identity, secrets, uploaded files, visitor data collection, storage, external links, payment flow, regulated-data risk, or brand representation. This rule avoids arguments about whether a change is “small” and focuses the review on impact. It also gives incident responders a previous known-good state when a Site must be rolled back, restricted, or removed.

Audience changes and external viewer governance

OpenAI documents several audience patterns for Sites, including restricting a Site to its owner and admins, sharing internally, sharing with named external viewers, and making a Site public when workspace policy allows. These choices are reach controls; they do not prove that the Site’s content, forms, storage, or server-side behavior are safe. Every audience expansion should therefore be treated as a new release decision, even when no code or copy changed.

Named external viewers require special handling because OpenAI states that eligible ChatGPT Business and Enterprise Site owners can share live Sites with named external viewers without adding those viewers to the workspace or making the Site public. OpenAI also states that external viewers can use the Site but cannot edit or publish it. That view-only property reduces authoring risk, but it does not reduce exposure risk for content, files, forms, links, or data returned by the Site itself.

Enterprise and Edu administrators should confirm that Sites are enabled for the relevant role and that the separate permission to invite external visitors is enabled only for roles that need it. After removing a direct invitation, administrators should retest the visitor experience because OpenAI warns that removing one invitation does not necessarily remove access granted through another audience setting. The evidence should include a signed-in test from the intended recipient class and, when feasible, a negative test from an account that should not have access.

Role-responsibility matrix

Pre-publication evidence checklist

1. Ownership: named Site owner, backup owner, business sponsor, and workspace administrator contact are recorded.
2. Purpose: the Site’s business purpose, intended users, and prohibited uses are documented in plain language.
3. Audience: current and requested audience settings are recorded, including whether access is owner/admin-only, internal, named external, or public.
4. External invitations: each named external viewer has a business sponsor, review date, and test result confirming the intended access level.
5. Authentication: any in-Site sign-in or identity-dependent behavior is documented separately from Site audience settings.
6. Data collection: every form field, upload prompt, free-text box, and generated output containing user data is listed with purpose and retention expectation.
7. Sensitive data: reviewers confirm the Site is not used for protected health information, direct payment-card processing, or users below the applicable age of digital consent.
8. Secrets: environment secrets are identified, stored outside client-visible code, and excluded from prompts, screenshots, sample data, and public pages.
9. Files and storage: uploaded files, stored objects, structured records, sample datasets, and deletion expectations are documented.
10. Links and third parties: outbound links, embedded content, analytics, payment processors, and third-party rights are reviewed.
11. Residency: the release record states that Sites does not support data residency or inference residency at launch and explains why the use case is still acceptable.
12. Testing: reviewers test the Site as the owner, as an intended viewer, and, where feasible, as an unauthorized user.
13. Version evidence: a version, snapshot, or equivalent release artifact is retained before publish.
14. Takedown plan: the owner knows who can restrict, unpublish, or delete the Site and how incident evidence will be preserved.

Incident response, takedown, and deletion

Incident response should start by preserving evidence before changing the Site, unless continued availability would increase harm. Capture the Site URL, audience setting, screenshots, version evidence, recent changes, invitations, affected data types, and the reporter’s account context. If the problem involves confidential information, impersonation, phishing, rights-infringing content, unsafe data collection, or a prohibited use, restrict the audience or take the Site down while the owner, administrator, security reviewer, and privacy or legal reviewer assess impact.

Takedown is a containment action, not the same as permanent deletion. A Site may need to remain preserved for investigation, legal review, customer notification, or internal lessons learned. Permanent deletion should occur only after the organization confirms that retention obligations, incident records, contractual duties, and downstream copies have been handled. After deletion or audience restriction, retest access from owner, internal viewer, external viewer, and unauthenticated contexts that match the original exposure path.

Recertification closes the loop. Low-risk internal Sites can be recertified on a longer cadence, while public Sites, Sites with external viewers, Sites collecting personal data, and Sites using storage or uploaded files should be reviewed more frequently and after every material change. A recertification that cannot identify the owner, purpose, audience, data inventory, and last approved version should result in restriction or takedown until the record is rebuilt.

Useful Links

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