ArtifactFlow

Guide · Browser isolation

How should AI-generated HTML run safely?

Treat generated HTML as untrusted executable code. Run it on a separate cookieless origin inside a tightly sandboxed iframe, apply a strict response-header content security policy, grant access briefly and deliberately, and document what the browser boundary cannot prevent.

Read ArtifactFlow's security model → Inspect the threat model ↗

Begin with the risk

HTML can be a program even when it looks like a document.

A generated dashboard, calculator, report, or diagram may contain JavaScript. If it runs on the same origin as an authenticated application, browser same-origin rules can expose session-backed endpoints, DOM state, cookies, and storage that were never intended for the artifact.

Prompt instructions, a clean-looking source file, and pattern scanning do not turn arbitrary executable content into trusted application code. The architecture must still contain a deliberately hostile artifact.

The load-bearing boundary

Separate identity from execution with two real origins.

Authenticated app origin

Owns login, authorization, search, editing, versions, and audit. Untrusted artifact bytes never execute in this origin or its DOM.

Cookieless artifact origin

Serves only bounded preview routes. It has no application session cookies and exposes no login, dashboard, or management surface.

Isolation is the security boundary.

Scanning, sanitization, and in-document JavaScript guards can add friction for common attacks. Browser-enforced origin separation, iframe sandboxing, and response-header policy must carry the security claim when those advisory controls are bypassed.

Browser controls

Use several independent restrictions around the isolated origin.

  • Opaque iframe sandboxDo not grant allow-same-origin, top navigation, forms, popups, downloads, or other powers that the artifact does not need.
  • Response-header CSPDeny external resources and connections with a policy such as default-src 'none' and connect-src 'none', plus form, frame, worker, object, and embedding restrictions.
  • Short-lived accessAuthorize the person on the app origin, then issue a narrowly scoped signed URL or content-bound draft capability that expires quickly.
  • Private storageKeep authoritative artifact bytes outside the public web root and serve only the authorized version through the artifact runtime.
  • Runtime separationEnsure the artifact host cannot accidentally expose application routes and the app cannot accidentally serve executable artifact documents.

Unsaved previews

The first preview needs the same boundary as every saved version.

Rendering an unsaved draft in the editor DOM creates the exact origin confusion that the saved-preview architecture avoids. A safer flow lets an authenticated Editor obtain a short-lived capability bound to the intended artifact origin, workspace, nonce, content byte length, and digest. The browser posts the matching bytes directly to the isolated frame, where they are reflected once without persistence.

The resulting preview should behave like the eventual saved artifact. External CDN scripts and APIs should not appear to work in the draft and then fail after save.

Residual risk

Containment protects the application, not every decision a viewer can make.

A hostile sandboxed document may still persuade a viewer to type sensitive information or may navigate its own frame to another site. Browser engines can differ at the edges, and some network mechanisms have browser-dependent enforcement. The isolated origin keeps application cookies and other tenant data out of reach, but it does not make deceptive content benevolent.

Maintain attack fixtures across server hardening, early browser guards, static markup, dynamic DOM APIs, and multiple browser engines. Record unsupported browsers and manual release checks instead of describing a broader guarantee than the evidence supports.

Evaluation checklist

Questions to ask before accepting any generated-HTML preview design.

  1. Can artifact bytes ever execute in the authenticated application origin or DOM?
  2. Are the app and artifact hosts separate HTTPS origins with no shared application cookies?
  3. Does the iframe omit same-origin, navigation, form, popup, and download permissions?
  4. Does response-header CSP deny ordinary network, subresource, worker, nested-context, and form behavior?
  5. Are saved and unsaved previews both short-lived, authorized, and tied to the exact intended purpose?
  6. Do browser-level attack fixtures verify the boundary while the threat model names residual risks honestly?
ArtifactFlow security architectureThe complete current preview flows, defenses, and documented residuals. Production self-hostingRequired origins, runtime roles, TLS, private storage, and boot checks. What is an AI artifact vault?Why a durable artifact system needs safe consumption as well as storage. Threat model and evidence ↗Authoritative attacker cases, controls, tests, and residual risks.