Source Access: The Audit Trail for AI-Generated HTML

Table of contents

1. What source access means for HTML artifacts
2. The minimum viable audit trail
3. How to package sources without leaking secrets
4. A BinHTML-friendly workflow
5. A checklist before you share

What source access means for HTML artifacts

An HTML artifact is an output surface: a report, dashboard, spec, or interactive summary an agent generated for a specific task. The viewer link is what you share.

Source access is everything you share alongside that viewer link to answer the reviewer’s real questions: Where did this come from? What inputs did it use? What changed between versions?

This is why source access is different from “view source” on a website. You are not trying to reverse engineer a product. You are trying to validate a one-off work output.

The minimum viable audit trail

If someone cannot reproduce (or at least explain) the artifact, they cannot confidently act on it. A practical audit trail usually includes:

• A stable link to the exact input snapshot (for code, that often means a commit permalink, not main).
• A short list of the inputs that mattered: files, URLs, tickets, or datasets.
• The generation context: what the artifact claims to be, and what it intentionally ignores.
• Version history or diffs, so reviewers can answer “what changed?” before they answer “is it correct?”.

A tiny trick that helps: when you’re linking to GitHub source, use permalinks (press y on a file page) so the link is pinned to a commit.

How to package sources without leaking secrets

Source access is a capability. If you enable it, assume recipients will read everything you expose. That makes the packaging decision the whole game.

Some practical rules:

1. Prefer references over raw dumps. Link to a commit permalink or an internal ticket instead of pasting full files.
2. Separate “inputs” from “credentials”. If the artifact needs secrets to generate, do not include those in any source bundle.
3. Make the boundary explicit. Write one sentence that says what was and was not in scope for generation.
4. Capture provenance, not noise. Frameworks like SLSA and in-toto are aimed at software supply chains, but the idea translates well: record what ran and what it touched so a reviewer can validate the story.

If your artifact is going to influence a decision (ship this change, approve this vendor, sign off this incident fix), treat the trail as part of secure development practice, not an afterthought.

A BinHTML-friendly workflow

BinHTML is designed for generated HTML artifacts: publish the HTML, share one link, and keep the governance outside the artifact itself. In practice, a clean workflow looks like:

1. Generate the HTML artifact.
2. Publish it via the API or MCP so you get a managed link instead of an attachment.
3. Decide whether recipients should have source access, and what that “source” actually contains.
4. If the agent regenerates the artifact, use Compare (and a compare-first habit) before you share the updated link.
5. If the task produces multiple artifacts, group the handoff behind a single project link so the reviewer has one URL to open.

If you want a broader checklist that covers visibility, expiry, and handoff hygiene, start with A Review Checklist for AI-Generated HTML Artifacts.

A checklist before you share

Use this as a last-pass review before you paste a link into Slack or a ticket:

• Can a reviewer identify the exact inputs (and their versions) the artifact used?
• Are any secrets, tokens, or private customer data exposed through the source bundle?
• Does the artifact explain what it did not look at?
• If someone disagrees with the output, do they have enough information to reproduce it or challenge it?
• If the artifact is updated, will the reviewer be able to see what changed (for example via a compare step)?

The point of source access is not transparency for its own sake. It is shortening the path from “interesting HTML” to “decision we can defend.”