# Your AI built something private. A public link is the wrong way to share it. > Source: > Published: 2026-07-15 13:31:51+00:00 Building with AI got fast. You describe a thing, and a page, a dashboard, a small internal report, or a client-facing microsite comes out. The awkward part is the next step: you want exactly three people to see it, and the default way we share a built thing is a public URL that anyone who gets the link can open. For a landing page that is fine. For a client's numbers, an unreleased feature, a draft you only want two colleagues to read, it is the wrong default. I kept hitting this while building [Thryvate](https://thryvate.com) (disclosure: it is mine, this is a build-log, not a pitch), and the access model turned out to be the hardest and most interesting part. Here is where I landed and the tradeoffs behind it. Paste-to-link hosts (Tiiny.host, Static.app, Netlify Drop, and friends) are great at one job: take a file, give back a public URL, done. But "public URL" quietly decides three things for you: For a lot of AI-built artifacts, the whole point is that they are not for everyone. A URL that treats every viewer identically cannot express "these people, nobody else." So the model needs an identity for the viewer before it will show anything. The rule I committed to is simple to say and annoying to build: no content renders until the viewer has proven who they are. Concretely, a private site does this: The important word is *before*. Verifying after render leaks the content to anyone who loads the page and closes the tab. Verifying before render means the bytes never leave the server for someone who is not on the list. That one ordering decision is most of the security value. The allowlist is the piece that makes forwarding harmless. The site is bound to a set of email addresses, not to knowledge of a URL. If a viewer forwards the link, the recipient hits the same verification wall and bounces unless the owner added them. Adding and removing people is the owner editing a list, and revoking is immediate: drop the address and their next load fails. This is a different mental model from "unguessable link." An unguessable link is a password you accidentally paste into Slack. An allowlist is a guest list the door checks every time. Two smaller controls ride on top of the allowlist because real sharing is messier than a single switch: They compose. You can require both an allowlisted email and a password, or set a private allowlisted site to also expire on Friday. The design goal was that the common cases (just me and two people; anyone at this company; public but only for a week) are all expressible without a settings PhD. One more thing that is invisible until it bites you: an AI-built page can contain arbitrary HTML and JS. If every site renders on the same origin, one site's script can reach another's storage and cookies. So each site renders on its own sandboxed, cookieless origin. It costs some convenience (no shared login state across sites, by design) and buys real isolation between things different people published. Being honest about the ceiling, because "private by default" oversells easily: The public-link hosts were designed for a web where you published things you wanted found. A lot of what we build with AI now is the opposite: specific, personal, meant for a named few. When the making is cheap, most of what gets made is not for the whole internet. So the sane default for sharing it is private, with the owner naming who gets in, and public as the deliberate exception. If you have built something with AI and the "now share it with just these people" step felt wrong, I would genuinely like to hear how you handled it. And if you want to see the access model above in practice, [Thryvate](https://thryvate.com) is where I built it.