{"slug": "your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it", "title": "Your AI built something private. A public link is the wrong way to share it.", "summary": "A developer building Thryvate, a platform for sharing AI-generated artifacts, argues that public URLs are the wrong default for private content. The access model requires viewer identity verification before rendering content, using an email allowlist instead of unguessable links. Each site is sandboxed on its own cookieless origin to prevent cross-site scripting attacks.", "body_md": "Building with AI got fast. You describe a thing, and a page, a dashboard, a small\n\ninternal report, or a client-facing microsite comes out. The awkward part is the\n\nnext step: you want exactly three people to see it, and the default way we share a\n\nbuilt thing is a public URL that anyone who gets the link can open.\n\nFor a landing page that is fine. For a client's numbers, an unreleased feature, a\n\ndraft you only want two colleagues to read, it is the wrong default. I kept hitting\n\nthis while building [Thryvate](https://thryvate.com) (disclosure: it is mine, this\n\nis a build-log, not a pitch), and the access model turned out to be the hardest and\n\nmost interesting part. Here is where I landed and the tradeoffs behind it.\n\nPaste-to-link hosts (Tiiny.host, Static.app, Netlify Drop, and friends) are great at\n\none job: take a file, give back a public URL, done. But \"public URL\" quietly decides\n\nthree things for you:\n\nFor a lot of AI-built artifacts, the whole point is that they are not for everyone.\n\nA URL that treats every viewer identically cannot express \"these people, nobody\n\nelse.\" So the model needs an identity for the viewer before it will show anything.\n\nThe rule I committed to is simple to say and annoying to build: no content renders\n\nuntil the viewer has proven who they are. Concretely, a private site does this:\n\nThe important word is *before*. Verifying after render leaks the content to anyone\n\nwho loads the page and closes the tab. Verifying before render means the bytes never\n\nleave the server for someone who is not on the list. That one ordering decision is\n\nmost of the security value.\n\nThe allowlist is the piece that makes forwarding harmless. The site is bound to a\n\nset of email addresses, not to knowledge of a URL. If a viewer forwards the link,\n\nthe recipient hits the same verification wall and bounces unless the owner added\n\nthem. Adding and removing people is the owner editing a list, and revoking is\n\nimmediate: drop the address and their next load fails.\n\nThis is a different mental model from \"unguessable link.\" An unguessable link is a\n\npassword you accidentally paste into Slack. An allowlist is a guest list the door\n\nchecks every time.\n\nTwo smaller controls ride on top of the allowlist because real sharing is messier\n\nthan a single switch:\n\nThey compose. You can require both an allowlisted email and a password, or set a\n\nprivate allowlisted site to also expire on Friday. The design goal was that the\n\ncommon cases (just me and two people; anyone at this company; public but only for\n\na week) are all expressible without a settings PhD.\n\nOne more thing that is invisible until it bites you: an AI-built page can contain\n\narbitrary HTML and JS. If every site renders on the same origin, one site's script\n\ncan reach another's storage and cookies. So each site renders on its own sandboxed,\n\ncookieless origin. It costs some convenience (no shared login state across sites,\n\nby design) and buys real isolation between things different people published.\n\nBeing honest about the ceiling, because \"private by default\" oversells easily:\n\nThe public-link hosts were designed for a web where you published things you wanted\n\nfound. A lot of what we build with AI now is the opposite: specific, personal, meant\n\nfor a named few. When the making is cheap, most of what gets made is not for the\n\nwhole internet. So the sane default for sharing it is private, with the owner naming\n\nwho gets in, and public as the deliberate exception.\n\nIf you have built something with AI and the \"now share it with just these people\"\n\nstep felt wrong, I would genuinely like to hear how you handled it. And if you want\n\nto see the access model above in practice, [Thryvate](https://thryvate.com) is where\n\nI built it.", "url": "https://wpnews.pro/news/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it", "canonical_source": "https://dev.to/thryvate/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it-138j", "published_at": "2026-07-15 13:31:51+00:00", "updated_at": "2026-07-15 14:03:45.848738+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-safety"], "entities": ["Thryvate", "Tiiny.host", "Static.app", "Netlify Drop"], "alternates": {"html": "https://wpnews.pro/news/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it", "markdown": "https://wpnews.pro/news/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it.md", "text": "https://wpnews.pro/news/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it.txt", "jsonld": "https://wpnews.pro/news/your-ai-built-something-private-a-public-link-is-the-wrong-way-to-share-it.jsonld"}}