Security overview
How Send Artifact protects your data.
What the platform receives, who can open it, and what an artifact can and cannot do in a reader's browser. None of it rests on unguessable links — every open is checked, server-side, against the access you set.
Publishing is a one-way snapshot
When your agent publishes, the platform receives exactly one thing: the HTML file it sent. There is no integration back into your Claude account, your project, or your conversation — the platform has no way to reach into them, and nothing in an artifact can "ask Claude for more." What you published is the entirety of what we hold.
Each republish creates an immutable version at the same URL, so you always know exactly what a reader saw and when. Deleting an artifact is yours to do at any time. One honest corollary: an artifact is a flat, self-contained page, and anyone allowed to open it can read its source — so don't put secrets (API keys, credentials, private records) in the HTML itself.
Who can open an artifact
Every artifact is private by default — it opens for nobody but you until you widen it. From there: guests (exactly the people you invite, by email or company domain, after verifying), link (anyone holding the URL, unlisted), or public (anyone; listed on your handle page and indexable). Two properties make this real access control rather than security-by-unguessable-URL:
- The decision runs on the server, on every request — for the page and for every file behind it. Revoking someone's access takes effect immediately; a stale cookie for a removed address opens nothing.
- The underlying files are never directly addressable. Non-public content is served through signed URLs that expire in minutes, so a copied file link goes dead almost immediately.
A reader who opens a private link sees the same not-found page as a wrong link — the page never confirms that a private artifact exists. From there they can verify their email and ask you for access: you're told who asked, and nothing changes until you act.
On link and public artifacts you can additionally ask readers who they are: capture (they type an email — unverified) or verified (they prove it with a one-time code or Google before anything renders). Analytics flag verified and merely-claimed addresses differently — a typed email is never presented as a proven one. Comments ride the same gate: whoever can open the artifact can comment, nobody else, and you can switch commenting off per artifact.
What an artifact can do in a reader's browser
Artifacts are interactive — real JavaScript runs, which is what makes calculators and prototypes work. So the platform treats every artifact as untrusted code and puts two walls around it:
Your session, your dashboard, and the API live on the app's origin. Artifact content is served from a separate content origin, and the browser's same-origin policy forbids code on one from touching the other. This is the wall between an artifact and you — and the artifact's side is kept deliberately empty: no cookies, no sessions, no keys, so even a maximally hostile artifact finds nothing on its own origin worth taking.
Inside the page, each artifact runs in a sandboxed iframe: no access to the page around it, no shared storage with other artifacts. This is the wall between one artifact and everything else. Within it, running the author's JavaScript is just running the author's JavaScript.
The layer that matters most: artifacts are egress-locked. Every response serving artifact content carries a Content-Security-Policy enforced by the reader's own browser. Artifact JavaScript can attempt any network request it likes — the browser checks each one against a policy that names only the artifact's own files plus a short allowlist of public script libraries: places code may be loaded from, never endpoints data can be sent to. An external fetch, an image beacon, a pasted-in tracker — the browser simply never sends them. What a reader types into an email-gated artifact, and the fact that they viewed it at all, cannot be silently shipped to any third-party server.
The platform surface itself
- Zero third-party dependencies. The server runs on Node.js built-ins alone — no npm packages, no framework, no supply chain of transitive dependencies to compromise.
- No customer password database. Customer sign-in is a one-time emailed code or Google (which must itself assert the email is verified). A separate marketplace-review account uses one generated credential stored only as a one-way scrypt hash and is not available as a customer sign-in method.
- API keys are stored only as hashes. A key is shown once at creation; the platform can verify it but never recover it. Rotating revokes every old key immediately.
- Everything is served over TLS.
The practice behind it
- A written threat model, kept current — reviewed against the code and re-versioned with every security-relevant release; findings tracked to closure.
- Adversarial review of every release that touches the walls above — verified in a real browser, not assumed from configuration.
- A deliberately small surface. Zero dependencies and a compact codebase mean the entire platform can be audited end-to-end.
Formal certifications such as SOC 2 are on the roadmap as the customer base grows — the practices above are what they will attest to. Honest guidance for today: a good fit is prototypes, demos, proposals, dashboards with business data, customer-facing docs — the things you'd share as a link anyway, now with real access control in front. Not yet: credentials inside the HTML, regulated data (health records, card numbers), anything your compliance team would need a certification for.
Found a security issue, or want to talk through a use case before sharing something sensitive? support@sendartifact.com — you'll get an answer from the person who wrote the code.