DEV Community: Alex

Your AI wrote the HTML. Now decide what that page is allowed to talk to.

Alex — Sun, 19 Jul 2026 15:49:46 +0000

Locking down who can open a page is the part everyone thinks about. You put it behind auth, you invite people by email, you set an expiry. Done.

Then the page loads and starts making requests you never looked at.

This is the part I got wrong for a while, and I only really got pushed on it last week when someone on Indie Hackers said, roughly: private mode is only real if auth gates every asset before any bytes leave the server, and generated HTML can still leak through embedded data, public JSON, images, and third party scripts. They were right, and the second half of that sentence is the interesting half.

Why AI-generated pages make this sharper

When you write a page by hand, you know what is in it. When you ask a model for "a dashboard for this data" you get back something that works, and somewhere in it there may be a font from a CDN, an analytics snippet it added out of habit, a chart library pulled from unpkg, an image hotlinked from wherever the model saw one. None of that is malicious. It is just the model producing the most common shape of the thing you asked for.

Now put that page behind a private link and hand it to a client. Every one of those outbound requests is a third party learning that someone opened your private page, and roughly when. An image URL alone can carry data in its query string.

So "private" has two halves:

Inbound: who can get the bytes.
Outbound: what the bytes can reach once they run.

Most sharing tools solve the first and quietly ignore the second.

The inbound half, briefly

For completeness, because the outbound half only matters if this part holds. Opening a site mints a short-lived signed token, and every sub-resource is served under that same token. There is no separate unprotected asset URL sitting on a CDN. On a gated site the token lives 120 seconds, so a copied asset URL is dead almost immediately. Expiry is checked before a token is ever minted, and on the data path too, so an expired link cuts off stored data the same way it cuts off content. Responses are private, no-store.

That is table stakes. Now the interesting part.

The outbound half: default deny, then approve out loud

The rule I landed on is that a published page can only load its own bundled assets unless the owner says otherwise. Concretely, the content renders in a sandboxed, cookieless, per-site origin under a CSP where script-src, style-src, font-src, connect-src and frame-src are 'self' only, and each approved origin is woven into those directives explicitly. No wildcards. The host pattern is validated strictly before it ever reaches a CSP string, because a source expression is just text and text is injectable.

Default deny is easy to write and horrible to ship, for one reason: it fails silently. The browser blocks the font, the page renders slightly wrong, and the owner has no idea why. So the deny has to come with a mouth. At publish time the files are scanned for external origins and the owner is told which ones were found and would be blocked. They approve the ones they meant, and the rest stay blocked. The approved set lives on the site as a list you can add to and remove from later, not a one-time dialog you clicked through.

Two honest limits on that scan. It is regex over the common static shapes (a CDN script tag, a fonts link), so anything assembled at runtime slips past it, and it does not look at images at all, because img-src is open anyway. It exists so nobody ships a half-rendered page. The CSP is the thing that enforces. The scan only tells you what the CSP is about to do, and it is best effort at that.

The framing I got back from that same thread, which I liked better than my own: approved hosts should read as capabilities. "This page can contact these three origins." That is a sentence a non-technical owner can actually evaluate. A publish-time warning is a moment; a capability list is a property of the thing.

The gap I have not closed

img-src still allows any https: origin.

That was a convenience call, because pages hotlink images constantly and blocking them made the first-run experience feel broken. It is also, precisely, the side door: an image request is an outbound request, and its URL is a channel. Tightening it to the same approve-per-origin rule as everything else is the obvious fix and it is the top thing on my list. It means teaching the publish scan to look at images too, which it does not do today. I am writing this down here partly so it stays uncomfortable.

The failure test worth stealing

The best thing to come out of that whole exchange was a test, not a feature: can an expired page still trigger an outbound request from cached HTML?

It cuts through the marketing, because it does not ask what your policy says, it asks what a copy of your page does after you have revoked it. And the honest answer has a boundary in it. Anything we serve, we can cut off: page, assets, stored data, all gated before a token exists. But CSP is a response header. It travels with the response, not with the file. If a viewer saves the page to disk, that saved copy is out of reach of any expiry you set, and it will happily make whatever requests were baked into it.

My first instinct was to write that this argues for tightening the outbound half at publish time rather than at serve time, on the logic that what you never allowed into the document cannot be triggered later from a copy of it.

That is wrong, and the reason is worth spelling out, because it is the trap. Tightening at publish, in a system like mine, still means adjusting a header that gets sent at serve time. The document itself is never rewritten. The <img src="https://..."> stays exactly where the model put it, so a saved copy fires it regardless of what the policy said while the page was live.

The only design that actually survives the test is rewriting the document at publish: inlining or proxying every external reference so there is no foreign URL left in the file to fire at all. That is a much bigger change than the img-src fix, it breaks things people reasonably expect to work, and I have not built it.

I am leaving the wrong version above rather than quietly deleting it, because it is the more natural thought, and if you are designing this you will probably have it too. It sounds like an architectural principle. It is really just a header.

If you are building something similar

Three things I would do again:

Make the deny default and the approval explicit, per origin, no wildcards.
Scan at publish and tell the owner what you are about to block, in plain words. Silent security gets ripped out by the first user who thinks your product is broken. Then stay honest with yourself about what the scan misses, because a convenience feature starts feeling like a guarantee surprisingly fast.
Write the gap down where users can see it. It is worse marketing and much better engineering.

I build Thryvate, which publishes what you make with AI as a private hosted site, so this is the problem I stare at. But nothing above is specific to it. If your AI is generating HTML that other people will open, you own both halves of the word private, whether or not you have looked at the second one.

What is the outbound story where you work? I am curious whether anyone has actually shipped strict img-src without the support burden eating them.

Your AI built something private. A public link is the wrong way to share it.

Alex — Wed, 15 Jul 2026 13:31:51 +0000

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 (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.

The problem with a link anyone can open

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:

Anyone with the link is in. Forward it once and you have lost the guest list.
You cannot tell who actually opened it, only that "someone" did.
Search engines and link unfurlers can reach it, so "unlisted" is not "private."

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 model I settled on: verify before a byte loads

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 viewer lands and gets an email-verification step, not the content.
They enter their email, click the link, and only then does the page load.
Their email is checked against an allowlist the owner controls. Not on it, not in.

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.

Allowlist, not a forwardable link

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.

Password and expiry, layered on top

Two smaller controls ride on top of the allowlist because real sharing is messier
than a single switch:

A per-site password, for when you want a lightweight gate without curating emails.
A link expiry, for "this is fine to see this week, not next month."

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.

The origin decision: sandboxed and cookieless

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.

What this is not

Being honest about the ceiling, because "private by default" oversells easily:

It is not DRM. A verified viewer can screenshot or retype what they can see. The model controls who gets in, not what an authorized person does afterward.
It is not anonymity for the viewer. The point is the opposite: the owner knows the verified email of who is looking.
It is not a replacement for real access control inside a complex app. This is for sharing an artifact, not for building a multi-tenant product's permission system.

Why I think the default should flip

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 is where
I built it.

Your AI built a static page. It can't store anything. Here's the fix I settled on.

Alex — Fri, 10 Jul 2026 14:26:23 +0000

An AI can build you a full page in one prompt now. A leaderboard, an RSVP form, a little internal dashboard, a guestbook. It looks done. Then someone types their name into the form, hits submit, and nothing happens, because there is no server on the other end. It's just HTML sitting in a bucket.

I kept hitting this. The generated page was 90% there and the last 10% was "wire up a database," which quietly means: stand up a backend, get API keys, handle auth, deploy it, keep it running. For a page you built in four minutes to share with a few people, that is a wildly lopsided amount of work. So most of these pages just stay read-only forever, or die in a folder.

I build a hosting product for AI-generated sites (Thryvate, it's mine, disclosing up front), and this was the most common dead end people hit. So I spent a while on the storage half specifically. This post is about what I landed on and the tradeoffs, not a pitch. If you're wiring your own AI-built pages to Supabase or Firebase, some of this might save you a step.

The constraint that shapes everything

The page is static. The person who "wrote" it was an AI, prompted by someone who may not code. There is no build step they control, no env file, no place to safely put a secret. So the usual answer, "just add Supabase," breaks on step one: a public static page can't hold a service key, and asking a non-dev to set up row-level security is a non-starter.

That pushes you to one design: the data layer has to be ambient. Present on every page with zero setup, no keys in the HTML, and the trust boundary enforced by the host, not by code the page ships.

What I ended up with

A single global the page can assume is there:

// save a record; the collection is created on first write
await window.THRYVATE.append('rsvp', { name: 'Sam', coming: true })

// read it back
const { records } = await window.THRYVATE.query('rsvp', { order: 'desc', limit: 50 })
records.forEach(r => console.log(r.value.name, r.value.coming))

No fetch, no endpoint, no key. Each record comes back as { id, value, created, actor } and you read your own fields off record.value. The AI generating the page only has to know this one object exists, which turns out to be easy to teach it, because it's a tiny surface.

A few decisions inside that were less obvious than they looked:

Collections are created on first write. No migration, no schema step. The person prompting the AI never says "create a table." The first append to a new name makes it. This matters more than it sounds: every explicit setup step is a place a non-dev abandons.

Identity is resolved by the host, and the page can't lie about it. There's a viewer() call that returns who is looking at the page, but only when the site is actually behind auth:

const me = await window.THRYVATE.viewer()
// private site, signed-in viewer -> { id: 'sam@work.com', kind: 'viewer' }
// public or password-only          -> { kind: 'anonymous' }

The rule I enforce: if you want to show WHO did something (a high score, a clock-in, a comment), you call viewer() and write that identity into the record yourself. You cannot read back the actor on someone else's record to display it, that field is redacted in-page down to just a kind. Otherwise any guestbook becomes an email scraper. It took a couple of rewrites to get that boundary in the right place: useful enough to build a real leaderboard, locked down enough that a public page can't harvest who visited.

"Current state" vs "full history" is one flag. Append-only logs are honest but annoying when you actually want the latest value per key (a settings row, the current status). So query takes latest: true and folds to the newest record per key field. You get an event log for free and a state view when you want it, without two different storage models.

Where this is the wrong tool

Being honest about the ceiling, because dev.to will (correctly) push back otherwise:

It's records-in, records-out with equality filters and ordering. No joins, no server-side aggregation, no transactions. If you're building something with real relational needs, you want an actual backend and the setup cost that comes with it.
The whole point is the page can't hold a secret, so anything requiring server-side trust (charging a card, calling a paid API with your key) is out of scope by design. That belongs on a server.
It's tied to the page being hosted somewhere that provides the runtime. A raw file on S3 won't grow a window.THRYVATE on its own.

The takeaway that isn't about my product

If you're the one gluing AI-generated pages to a database, the thing worth stealing is the constraint, not the implementation: assume the page can hold no secrets and the person shipping it won't configure anything. Design the data layer so identity and access are enforced by the host and the page just calls a verb. Once you accept that, a lot of the "which BaaS" debate collapses, because most of them assume a setup step your actual user will never do.

Curious how others are handling the storage half for vibe-coded pages. Are you defaulting people to Supabase and eating the setup, or avoiding stateful pages entirely?

I gave my AI a "publish this" tool over MCP. Here is what that tool actually has to do.

Alex — Mon, 06 Jul 2026 10:03:36 +0000

The making got 10x easier. The last mile did not.

You can now ask an AI to build a working thing: a dashboard, a small app, a one-pager, a report. It hands you code or a file, and then you hit the dumb wall. The artifact exists, but getting it in front of a specific person means exporting, finding hosting, wiring auth, or just sending a zip that kills the moment.

So I started building the missing verb. Not "generate," which is solved, but "publish this." One sentence to the AI, and the thing it just built becomes a real, hosted, live site behind access control. I build Thryvate, so this is the design I landed on, but the interesting part is not the product, it is what a publish tool actually has to guarantee once an autonomous agent is the one calling it. Full disclosure up front so you can weigh the rest.

Here is what I learned the tool has to do, past the obvious "accept some HTML."

1. Update in place, or you get link rot on every iteration

The naive tool signature is publish(html) -> url. That is wrong the moment the agent iterates. The user says "make the header smaller," the agent regenerates, and if publish mints a fresh URL every time, the link you already shared to a client is now stale.

So the real contract is closer to:

publish(html) -> { site_id, url }
update(site_id, html) -> { url }   // same url, new version

The agent has to carry site_id across turns and default to update once a site exists. "Publish this" on turn one and "tweak it" on turn five must land on the same URL. That single decision (stable identity separate from content) removes the most common footgun of agent-driven publishing.

2. Every update is a version, and rollback is one call

Once an agent can overwrite your live site unattended, you need an undo that does not depend on the agent having kept the old output. If turn five produced broken HTML, "ask the AI to regenerate the good version" is not a recovery plan, it is a prayer.

So every update is an append, not a replace, and there is a first-class rollback(site_id, version). The agent is allowed to move fast because a human (or the agent itself) can step back instantly. Treat published versions like git history, not like a single mutable file.

3. The access model is the actual product, not a checkbox

This is the part I underestimated. Paste-to-link hosts (Tiiny, Static, Netlify Drop, and friends, all genuinely good at what they do) give you a public URL: anyone with the link can open it. That is exactly right for a landing page and exactly wrong for the thing your AI built for one client.

When an agent publishes on your behalf, the safe default has to be private, because the agent cannot judge sensitivity. So the tool's access surface is where most of the design went:

set_visibility(site_id, "private" | "public")
set_allowlist(site_id, ["a@co.com", "b@co.com"])   // invite by identity
set_view_password(site_id, "...")                   // optional second factor
set_link_expiry(site_id, "2026-08-01T00:00:00Z")    // auto-dark after

The wedge is verified access, not a secret URL. A private site should make every viewer verify their email before a single byte of the page loads, so "who can see it" is an allowlist you control, not a link that gets forwarded into a group chat. A shared link that anyone can forward is not access control, it is hope.

4. Render it in a sandbox, because the AI wrote it

You are hosting arbitrary AI-generated HTML and JS on your domain. Serve it from the same origin as your app and one generated fetch or cookie read can reach places it should not.

The fix is boring and non-negotiable: sandboxed, cookieless origin per site. Each published page runs isolated from your session and from every other site. When the author is a language model, "assume the payload is hostile" is just the correct default, even when the author had good intentions.

5. Give the published page a data backend, or it is only ever a brochure

The thing that surprised me most: as soon as the AI can publish a live page, people immediately want that page to do something. Collect an RSVP. Record a high score. Take a form submission. A static file cannot, and asking a non-technical user to "stand up a backend" puts the wall right back.

So the published page ships with a tiny global SDK, no keys, no setup:

// inside the AI-generated page
await window.THRYVATE.append("rsvps", { name, email });
const { records } = await window.THRYVATE.query("rsvps", { order: "desc", limit: 50 });

Now the AI can build a working guestbook, a poll, a signup, or a leaderboard, and it just persists. The publish tool is not shipping a document, it is shipping a small application with somewhere to put its data.

The tool surface, in one place

Pulling it together, a "publish this" tool an agent can safely drive ends up being roughly:

publish / update with stable site_id (no link rot)
versioning + rollback (fearless iteration)
set_visibility / set_allowlist / set_view_password / set_link_expiry (private by default, verified access)
sandboxed per-site origin (untrusted author)
an in-page data SDK (published pages that actually do things)

None of these are exotic on their own. What is new is that the caller is an autonomous agent, so the defaults have to be safe without a human in the loop for each step: private not public, versioned not overwritten, sandboxed not trusted.

If you are wiring your own agent to ship things to the web, I think those five are the load-bearing pieces, whatever you build it on. And if you would rather not build the plumbing, that is the whole reason Thryvate exists: your AI publishes what it made straight to a hosted, private-by-default site, and you control who gets in. Happy to answer anything about the access model in the comments.

What changes when an AI agent can publish to the public web

Alex — Sat, 27 Jun 2026 18:14:32 +0000

I've been building agent workflows for a while, and one capability keeps coming up that the ecosystem hasn't fully reckoned with: letting an AI agent publish a document to the public internet and hand someone a link.

It sounds trivial ("save HTML, return a URL"). It isn't. The moment an autonomous agent can mint a public link, you've handed it a primitive that touches access control, data exposure, and reputation. This post is about the design questions that surface once you take that seriously, written by someone who builds in this space. Disclosure up front: I work on Thryvate, a document-sharing tool with an MCP server. More on that at the end, but the problems below are general.

The naive version

The first version everyone writes is a tool that takes content and dumps it to object storage behind a public CDN URL:

publish(html) -> https://cdn.example.com/a8f3c2.html

Ship that and an agent can now share its work. It can also now:

expose a half-finished draft to anyone who guesses the URL,
leave that URL live forever with no way to pull it back,
publish something containing a customer's name with zero record of who saw it.

For a human hitting "publish" deliberately, those are acceptable defaults. For an agent doing it as one step in a longer plan, they're landmines.

What "publish" should actually mean for an agent

A few properties turn the naive primitive into something you'd trust an agent to call:

1. Default to private, opt into public. The safe default for an agent-minted link is not "world-readable." It's "only people on this list" or "only people with the password." Public should be an explicit parameter someone has to set, not the fallback.

2. Revocability. Anything an agent publishes, you must be able to un-publish instantly. A live link is a liability with a half-life, and the ability to revoke is what makes it safe to let the agent create them liberally.

3. Expiry as a first-class field. "This link dies in 7 days" should be a parameter on the publish call, not a cron job you remember to write later. Most agent-published artifacts are ephemeral by nature.

4. Per-viewer visibility. If the agent is sharing a deck or report, the human almost always wants to know who opened it and when. That telemetry is also how you detect a leak, since an unfamiliar viewer is a signal.

5. Idempotent updates. Agents iterate. The second draft should update the same URL, not spray new ones. The link is the stable handle, and the content behind it changes.

Where MCP fits

Model Context Protocol is a clean place to expose exactly this surface. Instead of an agent shelling out to aws s3 cp, you give it a small set of typed tools:

publish_site(content, visibility="private")
set_link_expiry(site, days=7)
add_to_allowlist(site, email)
get_analytics(site)

Now the access-control model lives in the tool layer, where it can be enforced and audited, instead of being improvised by the model inside a bash command. The agent reasons about intent ("share this with the investor"), and the tools enforce policy (private by default, expiring, owner-scoped). That separation is the whole game: the model is creative, the tools are strict.

The part I keep getting wrong

The temptation is to let the agent set everything, including visibility. Resist it. The single most useful guardrail I've landed on: the agent can draft and stage a link, but flipping something to fully public stays a deliberate, reviewable step. It keeps the worst failure mode at "a draft sat private a little too long" instead of "an agent published the wrong thing to the open web."

Closing

Disclosure: I build Thryvate, a document-sharing app that ships an MCP server doing roughly the above, with private-by-default links, allowlists, expiry, and per-viewer analytics. None of the design points here are specific to it, though. If you're wiring publish-to-web into your own agent, these are the questions worth answering first.

I'm genuinely curious how others are handling revocation and default visibility for agent-published artifacts. Drop a note if you've shipped this.