2026-05-23
Keep Generated HTML Self-Contained Before You Share It
A practical checklist for making AI-generated HTML artifacts safe to share: avoid external dependencies, limit outbound connections, and keep review controls outside the artifact.

Table of contents
- The failure mode: remote dependencies
- Make the artifact self-contained
- Restrict outbound network (viewer-side)
- Sandbox the renderer (viewer-side)
- A BinHTML-friendly publishing workflow
The failure mode: remote dependencies
Agent-generated HTML often looks harmless because it is “just a report”. But HTML is also a runtime. If the artifact includes remote scripts, third-party fonts, external images, or calls out to APIs, then the link you share is no longer a stable document. It is a page that can change based on what those remote endpoints return.
That creates three predictable problems:
- **Accidental data leaks**: the artifact can embed identifiers in URLs (query strings, paths) and then send them to third-party hosts through image loads, script loads, or network calls.
- **Non-reproducible review**: the artifact a teammate opens tomorrow might render differently than what you saw today because a CDN asset changed or a dependency disappeared.
- **Security confusion**: a shared artifact that looks like a standalone first-party page can trick reviewers into trusting it more than they should.
The fix is not “never share HTML”. The fix is to share HTML the same way you share any other untrusted output: with strong defaults and clear boundaries.
Make the artifact self-contained
Before you publish, try to make the HTML artifact stand on its own:
- Prefer inline CSS over remote stylesheets.
- Prefer inline SVG icons over remote image URLs.
- Avoid remote fonts; default system fonts are boring but reliable.
- Avoid remote scripts entirely. If the artifact needs a little interactivity (filters, expand/collapse), keep it minimal and make sure it does not fetch anything.
- Never embed secrets in the HTML (tokens, internal URLs with credentials, customer data you would not paste into a ticket).
If you must reference third-party assets (for example a charting library), treat that as a conscious decision and add integrity verification. MDN documents Subresource Integrity (SRI) as the browser feature that lets you pin an external script or stylesheet to an expected hash so it cannot silently change.
Restrict outbound network (viewer-side)
Even if you try to keep the artifact self-contained, the sharing layer should assume an artifact may attempt network calls. This is where Content Security Policy (CSP) helps.
CSP is a response-header mechanism (and can also be applied via a meta tag) that lets the renderer restrict what the document is allowed to load. In practice, the high-signal directives for hosted artifacts are:
connect-src: restricts where scripts can send requests (fetch/XHR/WebSocket).img-src: restricts where images can be loaded from.script-srcandstyle-src: restrict where scripts and styles can come from.
If you are building an artifact viewer, you can use CSP to enforce “no outbound network by default” and then selectively allow what you actually need for rendering. The W3C CSP spec and MDN’s directive references are a good starting point if you want to make those restrictions explicit and testable.
Sandbox the renderer (viewer-side)
A shareable artifact is safest when it renders inside a controlled viewer, not as a naked page. The browser gives you a practical primitive for this: the iframe sandbox attribute.
MDN calls out an important footgun: combining allow-scripts with allow-same-origin is strongly discouraged because it can make the sandbox ineffective. If you need scripts for benign interactivity, be deliberate about the sandbox tokens you allow and keep the boundary clear: the viewer owns navigation, controls, and identity, not the generated HTML.
If you want a higher-level framing of why this boundary matters, start with Why AI-Generated HTML Should Be Sandboxed Before You Share It.
A BinHTML-friendly publishing workflow
A practical workflow for teams looks like this:
- Generate the artifact (report, dashboard, review packet).
- Make a quick “self-contained” pass: remove remote dependencies, strip secrets, and keep any interactivity local.
- Publish the HTML so you get a managed viewer link (via the API or MCP).
- If the agent revises the artifact, use Compare before you re-share the updated link.
- If you need reviewers to verify how the artifact was produced, pair the link with a minimal audit trail (see Source Access: The Audit Trail for AI-Generated HTML).
The goal is not to make every artifact perfect. It is to make shared artifacts predictable: stable to view, safe to open, and easy to review.
Sources
- https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/connect-src
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/img-src
- https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
- https://www.w3.org/TR/CSP/