Password-Protect a Website Built With AI

Not every website is meant for everyone. A client preview, an internal handbook, a page for a club, a draft you want two people to read before launch: a small group should open it, and everyone else should see nothing. Ask an AI to "add a password" and you usually get a prompt that looks convincing and protects nothing. This guide shows what the common AI publishing tools offer for private sharing, why a password written into the page is not protection, and how to put a real check in front of a site you built with AI.

Where the check happens decides everything

Every password scheme comes down to one question: when does the server hand over the page? If it checks the password first and sends the files only afterwards, the protection is real. If it sends the files first and a script in the page then asks for the password, the content has already arrived in the visitor's browser, and the prompt is a curtain, not a lock.

OWASP, the open security project that publishes the Top 10 list of web application risks, puts it in one sentence: "Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata." Everything else in this guide follows from it.

What the AI publishing tools offer

The tools that build sites with AI increasingly publish them too. None of their help pages describes a shared password, but several offer another way to keep a published page private:

ChatGPT Sites

A new Site starts out limited to its owner and workspace admins, and you widen it from Share. The options OpenAI lists are selected people or groups, named external viewers, everyone in the workspace, and anyone on the internet once public publishing is enabled. For limited sharing, visitors sign in with the account that received the invitation, and you remove a person from the sharing controls to end their access. That is real access control, run by OpenAI, but it assumes your viewers have or create an account, and OpenAI describes no way to hand someone a password instead. OpenAI also treats a Site's audience setting and any sign-in built into the Site as separate controls, so check the audience setting, not only the login screen.

Claude artifacts

Anthropic's help article starts from privacy: artifacts are private to you until you share them. On Pro and Max you choose between only you and anyone with the link, and you can invite people by email, a feature in beta; Team and Enterprise add sharing inside the organization. In all of these cases, as Anthropic puts it, "Everyone needs a Claude account": without one, a person cannot open a shared artifact, even with the link. The exception is a legacy artifact published from a chat, whose public link anyone can open without an account. Unpublishing revokes that link, and Anthropic notes that the same artifact cannot be published again afterwards. The article mentions no password.

Gemini Canvas

A Canvas page or app is shared through a public link. Google's help says shared links only open in gemini.google.com, and that anyone with the public link to an app can view and edit the data associated with that app. Again, there is no password option in the article, so treat a Canvas share link as public.

Lovable and Bolt

Lovable's Invite only setting, on its Free and Pro plans, lets the people you add open the published app after they log in with the invited address; Business and Enterprise add workspace-only publishing. Bolt's private sites, on paid plans, are visible to your team and to people you invite by email or through a trusted email domain, and Bolt notes that a site with a custom domain can only be published publicly. Neither documents a shared password.

Why a password prompt in JavaScript is not protection

Ask an AI chat to "put a password on this page" and the usual result is a small script: a box appears, you type, the script compares your input with a value stored in the page, then shows or hides the content. It feels like a lock. It is a costume, for three reasons:

1. The content has already been delivered. The browser downloaded the whole page, the hidden text included, before the box appeared. Anyone can open the page source (Ctrl+U in most desktop browsers, or the developer tools) and read it.
2. The answer travels with the question. The value the script checks against sits in the same file. If the AI stored a hash instead of the plain password, it can still be guessed offline, as fast as the attacker's computer allows, with no server in between to slow it down.
3. Scripts can be switched off. Turn off JavaScript, or open the site's other files directly by their addresses, and the box never runs. Images, PDFs and subpages are usually reachable on their own.

A test that takes thirty seconds: open the "protected" page, view its source and search for a sentence that should be hidden. If you can find it, so can anyone.

That does not make every client-side check useless. A prompt that stops a curious colleague from stumbling onto a draft is fine, as long as nobody mistakes it for security. For a client's unreleased work, staff information or anything you would not post publicly, the check has to happen on the server.

What server-side protection looks like

On a properly protected site, the server keeps the password, or the list of people allowed in. A visitor who has not proved access gets a password page or a sign-in page and nothing else: not the HTML, not the images, not the scripts. After a correct password, the server gives the browser a signed cookie, every later request carries it, and the server checks it again each time. The files with your content never reach anyone who has not passed the check, so there is nothing to read around.

Password and invite-only sites on AI-Hosted

On AI-Hosted, powered by VibeDeploy, every site has an access setting that the web server applies before it sends a single file:

• With a password. One shared password for the whole site. A visitor types it once, and that browser stays unlocked for 24 hours.
• Invite only. You list email addresses, and each person receives a personal access link by email. People who are not on the list cannot get one, and removing an address ends that person's access.
• Only me and My team. Only you, or members of your team, after they sign in to their account.
• Specific networks. Only visitors from IP addresses or ranges you list, such as your office or a VPN.

These settings are included from the Maker plan, EUR 15 a month (EUR 144 a year), which also gives you three sites and three custom domains. To use one, upload the site, open its settings, choose who can see it and save. Then open the exact address you will share in a private browser window and check that the lock appears and opens.

Two honest limits. The password covers the whole site; to protect one page on its own, publish it as a separate site. And the password, invitation and team settings are enforced by the server that delivers the site's files, so a site that runs a container app takes the container off its public address while one of those settings is on. Specific networks is the setting that works together with container apps.

When ChatGPT Sites is the better choice

If everyone who should see the site is already in your ChatGPT workspace, or happy to sign in with a ChatGPT account, Sites' own sharing can beat any shared password. Each viewer is identified, you remove one person without changing anything for the others, and there is no password that can be forwarded by accident. The same holds for Claude artifacts shared inside a Team or Enterprise organization. A shared password wins when your audience has no account with the AI company and should not need one: a client, an outside reviewer, the members of a local club.

If you are weighing a move for other reasons too, moving a ChatGPT Site to your own hosting walks through the whole switch, and the ChatGPT Sites custom domain guide covers putting a Site on your own domain without moving it.

Pick the right lock

• One client reviewing a draft: a shared password, sent separately from the link.
• Colleagues: team sign-in, so access follows your team list.
• An intranet page used from the office: a network allowlist.
• Health records, payment card data or anything regulated: none of the above makes a website the right place for it. Keep such data in systems built for it.

For the bigger picture of what a host does after launch, read how AI-hosted websites work, and the pricing page lists what each plan includes. Prices include VAT where it applies.

Sources

• OWASP Top 10:2025, A01 Broken Access Control: access control is only effective in trusted server-side code. Fetched 13 October 2026.
• OpenAI Help Center, Creating and using ChatGPT Sites: sharing options, sign-in for invited visitors, removing viewers, and audience settings versus sign-in inside a Site. Fetched 13 October 2026.
• OpenAI, ChatGPT Sites developer guide: access options and external invitations. Fetched 13 October 2026.
• Claude Help Center, Share artifacts: who can open shared and published artifacts, email invitations and unpublishing. Fetched 13 October 2026.
• Claude Code docs, Share session output as artifacts: a page Claude Code shares with a public link opens without a claude.ai sign-in. Fetched 13 October 2026.
• Gemini Apps Help, Create docs, apps and more with Canvas: public share links, where they open, and data in shared apps. Fetched 13 October 2026.
• Lovable Docs, Publish your project: Public, Invite only, Workspace and Custom audiences. Fetched 13 October 2026.
• Bolt Help Center, Publish your project to a live website: public and private sites, invitations, trusted domains and the custom-domain restriction. Fetched 13 October 2026.