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.
Top comments (5)
The moment an agent can mint a public URL, the real question is what else that same agent can reach. If it runs where outbound and internal reach are scoped by the network, publishing a link stays just that instead of turning into a data-exposure path.
Completely agree that network scope is the containment boundary. Most "an agent published something bad" stories are really "an agent could reach something it shouldn't" stories underneath. Egress filtering, no internal or metadata-endpoint access, narrowly scoped credentials: that's the layer that keeps a publish step from quietly becoming an SSRF or exfil path.
The thing I'd add is that it's orthogonal to who can reach the artifact afterward, and you want both. Network isolation governs what the agent can pull in; access control on the link governs what leaks out to viewers once it exists. A perfectly egress-locked agent can still mint an "anyone with the link" URL to a half-finished doc, and a perfectly access-controlled publish tool doesn't help if the agent could read internal data and bake it into the page first.
There's also a wrinkle worth naming: the publish tool is itself a sanctioned hole in that network boundary. It's the one egress path you've deliberately allowed, so it inherits the exact exfil risk the network controls exist to stop. That's the case for giving it its own policy (private by default, revocable, logged) rather than leaning on the network scope alone, since the publish call is precisely where content is meant to cross the line.
Publishing is where agent autonomy needs the strongest gates. Drafting, previewing, attaching media, posting, editing, and deleting should be separate steps with visible verification. The moment an agent can affect the public web, the workflow needs receipts, not just confidence.
"Receipts, not just confidence" is the perfect way to put it. The framing I keep coming back to is that the gate should scale with reversibility: drafting and previewing can be fully autonomous because they're cheap to undo, but anything that changes the public surface (publish, edit, delete) should leave an append-only trail and, ideally, be reversible after the fact rather than only confirmed before it.
The piece people underrate is revocation. Pre-publish confirmation gets all the attention, but the more valuable capability is pulling or rolling back something an agent already pushed live, with a record of who, what, and when. Confidence fails silently; receipts plus a kill switch fail loud.
Curious where you'd draw the human-in-the-loop line: at publish, or only at edit/delete of already-public content?
I would put the human line at first publish for anything with real audience or brand risk, then loosen it only inside pre-approved lanes.
So the rule is not “humans approve every post forever.” It is: humans approve the lane, the constraints, the rollback path, and the first few examples. After that, low-risk publishes can be autonomous if receipts, monitoring, and revocation are mandatory. Edit/delete still deserve stricter gates because they rewrite history.