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.