Artifact tool publishes to claude.ai without disclosing egress at consent time; feature name collides with a common noun in the offer, misdirecting consent

Preflight

• [x] Searched existing issues — the closest, #72055 and #74589, are related but distinct (referenced below); this consent/egress-disclosure framing is not filed.
• [x] Single report.

---

The Artifact tool renders a file to a page hosted on claude.ai (Anthropic servers). When the assistant offers to produce "a one-page HTML/PDF version of the artifact," neither the offer nor the approval names the mechanism or states that approving it uploads content off the user's machine. The user reasonably reads it as producing a local file of their own document and approves — silently publishing to the vendor cloud.

Consent gap — the offer's own wording misdirects. "Artifact" (capitalized) is the product; "artifact" (lowercase) is an ordinary word for a produced document, which the assistant naturally uses to mean the user's own file. The phrase "a one-page HTML/PDF version of the artifact" has an innocuous meaning precisely because "the artifact" reads as the user's report — the same word that is also the name of the publishing feature. So at the moment of consent: the tool name is unstated, the egress is unstated, and the one word overlapping the product name denotes the user's own document, not the feature — reassuring rather than warning. Verbatim from the incident:

Assistant: "Want me to also produce a one-page HTML/PDF version of the artifact (nicer to send than a terminal paste), or is the plaintext what you'd forward?" User: "make the one-page HTML version"

Neither line names the product or indicates upload; "the artifact" is the user's report, discussed as such for many prior turns. The approval routed to Artifact and published to claude.ai.

The model makes no visibility decision. In this invocation the call carried no visibility parameter — the model set no public/private choice; visibility was left to a platform default the user never sees and cannot verify. Users therefore cannot treat "it was private" as a safeguard — and per #72055 below, an Artifact has been reported by its author as publicly accessible.

Impact / near-miss. Silent egress of sensitive material to vendor cloud on an innocuous-sounding, arguably misleading approval. Enabled by default where available; no per-call "this leaves your machine" signal. Highest-sensitivity users — vulnerability researchers doing coordinated disclosure, and anyone handling embargoed/regulated data — are exactly those most harmed.

Incident: the tool published a vulnerability reproducer to a researcher's claude.ai before they understood it published at all. In this instance the published content reproduced an already-disclosed, patched vulnerability, so no embargo was broken — that was incidental, not protective. The only safeguard against broader exposure was a private default the user did not set and could not verify, and which the report in #72055 indicates is not reliably private.

Related / corroborating issues

• #72055 — reporter says an Artifact published their server's directory structure unintentionally, as a public URL (their claim, unverified here).
• #74589 — no delete/unpublish from within Claude Code; removal requires the separate claude.ai web UI.

Suggested mitigations

1. Name the egress at consent time — the permission prompt must read "this uploads content to Anthropic's servers (claude.ai)"; the model-facing tool description must state it publishes off-machine.
2. Disambiguate the name — because "artifact" is a common noun that appears naturally in the assistant's own phrasing (e.g. "a version of the artifact"), surface the feature to users as "Publish to claude.ai" / "Hosted page," not "Artifact."
3. Classify it as a network/egress tool with a distinct, clearly-labeled permission (like WebFetch), not something that reads as local file authoring.
4. Model guidance: when a user asks the assistant to render an existing document into a file format (e.g. "a one-page HTML/PDF version of the artifact"), default to writing a local file; use the hosted publish only when the user explicitly asks for a shareable/hosted link, and say "this publishes to claude.ai" when doing so.
5. Off-by-default / explicit opt-in in sensitive environments; surface the existing disableArtifact kill switch (poor discoverability) and allow enforcing it via managed policy.
6. Provide delete/unpublish from within Claude Code itself — today an artifact can only be removed via the separate claude.ai web UI, not from the CC session that created it, so the model cannot retract what it published (ref #74589). And never let a private default silently become public (ref #72055).

---

Reported by a security practitioner doing coordinated vulnerability disclosure.