Security and sharing guide
Securely Share Generated HTML: Sandboxed Artifact Links
Generated HTML should be treated as untrusted content until it has passed a review. Secure sharing is a chain of decisions: remove secrets, render inside the right boundary, choose who can open the link, and tell the recipient what the link represents.
Last reviewed 2026-08-02
01
1. Treat generated HTML as untrusted input
An agent can produce useful markup and still include a value that should not leave the workspace. The first security step is source review: look for API keys, access tokens, internal URLs, personal data, customer identifiers, hidden comments, local file paths, and data copied from a private system.
Do this before the HTML is uploaded or sent to a browser viewer. Once sensitive data is embedded in an artifact, changing the visibility setting does not undo the exposure to the people or systems that already received it.
- Scan source and generated data for secrets and credentials.
- Replace real customer data with representative values when the review does not require it.
- Check comments, data attributes, serialized state, and embedded JSON as well as visible text.
02
2. Use sandboxed rendering for generated documents
A generated report or prototype may contain scripts, styles, and interaction. It should be rendered in a controlled sandboxed viewer rather than being treated as code that belongs to the surrounding product page. This is a boundary for the artifact experience, not a promise that every document is harmless.
Keep the product boundary clear: BinHTML is for publishing complete HTML documents as managed artifact links. It is not a server-side runtime for application code, and it is not a replacement for security review of the source itself.
03
3. Choose private or unlisted deliberately
Private visibility is for owner-only iteration. Unlisted visibility is for direct-link sharing when the recipient should be able to open the artifact without it becoming a public discovery page. Neither choice should be treated as a substitute for removing sensitive content.
Before sending the link, name the audience and the sharing channel. If the URL is copied into a public issue, an open chat, or a document with a wider audience, an unlisted link can travel beyond the people you intended.
- Private: keep the artifact inside the owner's workflow while it is being prepared.
- Unlisted: share directly with a known audience when search discovery is not wanted.
- Public discovery: use a separate public page or website when the content is genuinely meant for search and broad access.
04
4. Keep search boundaries and share boundaries separate
Artifact and project share pages are intended for direct sharing and are marked noindex. That is useful for keeping generated work out of organic search, but it does not make the content confidential. The people who hold an unlisted URL can still share it, and the source may still reveal more than the rendered view suggests.
Use public, indexable guide pages for explanations of the workflow. Use artifact links for the generated output itself. This separation keeps the site discoverable for the problem while keeping individual work products out of the search index.
05
5. Add an expiry and revocation plan
Temporary review work should have a retention decision. If an artifact is only needed for a short review, choose an expiry that matches that job. If the link has already been shared, revoke it when the work should no longer be available. For recurring reports, document who owns the artifact and whether the same URL will be updated.
Expiry is a lifecycle control, not a security guarantee. It works best alongside source redaction, deliberate visibility, and a clear handoff message.
06
6. Run a pre-share checklist
A small checklist is more reliable than relying on the generator to remember every boundary. Run it for the source and the rendered page, then keep the final link next to the review context so recipients know what they are opening.
- No secrets, tokens, private identifiers, or accidental internal URLs remain.
- The document renders as intended in the sandboxed viewer.
- Visibility, expiry, and source access match the audience.
- The handoff names the artifact, owner, current version, and review purpose.
Continue the workflow
Use the reference that matches the next decision, then publish a representative document and review the resulting link.
Sandboxed HTML security
Read the product-specific explanation of sandboxed generated HTML rendering.
Visibility documentation
Choose private, unlisted, or public access based on the real audience.
Expiry and retention
Plan temporary review links and understand when to revoke them.
Frequently asked questions
Check current product answers around sharing, security, and artifact behaviour.
Ready to publish one?
Start with a real document, then keep the review link close to the context that produced it.