The things that help you read
Text, headings, tables, supported images, links, and CSS layouts. A report can still have hierarchy, color, typography, and a distinctive point of view.
AI-GENERATED HTML / A READER’S GUIDE
Is AI-generated HTML
safe to open?
A reading page should not need permission to run your life.
Not automatically. AI can generate harmful code as well as useful pages. On share/artifacts, submitted scripts and forms are removed, and published HTML is isolated from the main app with browser-enforced restrictions. This reduces code-execution risks; it does not verify the page’s claims or make every link trustworthy.
These protections apply to HTML published through share/artifacts—not every HTML file you download or open elsewhere.
01 / KEEP THE EXPLANATION. LIMIT THE BEHAVIOR.
A designed document.
Not a place to run code.
The things that make it an app
Submitted JavaScript, forms, embedded pages, objects, workers, refresh redirects, and API connections. A report cannot use these to collect input or run a live workflow.
Supported HTTPS images and fonts, including CSS background images, can still contact outside hosts. A static page is not necessarily an offline page.
02 / A SMALL, CHECKABLE EXAMPLE
The update stays.
The executable extras do not.
This example combines two lines of report content with a click handler, script, password field, and embedded page. The text below is displayed as code, never executed.
Before publishing
<h3 onclick="alert('clicked')">Weekly update</h3>
<p>9 of 12 tasks complete.</p>
<script>alert('running')</script>
<form><input type="password"></form>
<iframe src="https://example.com"></iframe>After sanitization
<h3>Weekly update</h3>
<p>9 of 12 tasks complete.</p>The heading and paragraph remain. The click handler, script, form controls, and iframe are removed.
The output is checked against the same sanitizer used for publishing. This excerpt shows the remaining body content; normal document metadata is added separately.
03 / MORE THAN ONE CHECK
How are published pages protected?
Only supported HTML is kept
A DOM-based allowlist sanitizer removes unsupported elements and dangerous attributes before the page is stored for delivery. It is not a promise that every sentence or destination link is safe.
The report is separate from the app
Published HTML is served from a separate content origin inside a sandboxed frame. It is not inserted into the trusted app’s document. Your report’s design and code are kept apart from the account interface.
The browser enforces additional limits
A Content Security Policy blocks submitted scripts, form submissions, API connections, nested frames, objects, and workers. The empty iframe sandbox adds another boundary around the published document.
Show the main browser restrictions
script-src 'none'
connect-src 'none'
form-action 'none'
frame-src 'none'
object-src 'none'
worker-src 'none'
base-uri 'none'This is a selection of the content-page policy, not the full header. Separate directives allow supported images, fonts, and CSS. These restrictions concern submitted HTML; the platform’s own trusted controls are separate.
04 / WHAT YOU SHOULD STILL CHECK
Less executable code
does not mean zero risk.
- Facts can still be wrong
- Check important claims, calculations, and sources. Sanitization is not fact-checking or an endorsement of the author.
- Links can lead somewhere else
- A normal link may remain in the report. Check its destination before following it, especially if the next page asks you to sign in, pay, or download a file. A convincing design is not proof of legitimacy.
- External assets can make requests
- HTTPS images, fonts, and CSS background images may load from their hosts. Those hosts can receive network information such as your IP address. Avoid remote assets when that exposure is inappropriate.
- Readers can copy what they see
- Access controls limit who can open a page; they cannot recall screenshots, saved copies, or content already loaded. Noindex is an indexing instruction, not a password or privacy guarantee.
Want to limit the audience? Use private sharing. Do not put passwords, API tokens, or unrelated private source material into a published report.
05 / BEFORE YOU SHARE
Review the message.
Then review the audience.
- Check the facts, links, and any external images or fonts.
- Remove secrets and information the audience should not see.
- Open the published result and check the layout after sanitization.
- Choose access deliberately and test the recipient experience.
Need forms, live calculations, or API-connected dashboards? Use a full application with the appropriate security design. Compare a static artifact with a web app.
MAKE SOMETHING WORTH READING
Start with the explanation.
Leave the app behavior out.
Your agent can make a useful report without scripts or forms. Start with a worked example, bring your approved context, and review the page before publishing.