Scan and Redact Secrets Before You Publish HTML Artifacts

Table of contents

1. Why HTML reports leak secrets
2. Add a pre-publish secret scan
3. Redact, then re-generate (don't edit by hand)
4. Publish with safety defaults (BinHTML workflow)
5. What to do when you find a secret

Why HTML reports leak secrets

HTML artifacts leak secrets for boring reasons:

• the model echoes environment variables from logs
• a pasted stack trace includes a bearer token
• a screenshot URL contains a signed query string
• a debug panel prints request headers

The problem is not that the report is "interactive". It’s that the report is a *container for copied data*. If the input had secrets, the output can too.

If you want a more general hardening checklist (network egress, external scripts, etc.), start with Keep Generated HTML Self-Contained Before You Share It.

Add a pre-publish secret scan

Treat secret scanning as part of the *publish step*, not just something you do on Git commits. You want the scan to run on the exact bytes you are about to upload.

Two pragmatic options:

1. **Scan the generated HTML file** in CI before publishing. Tools like Gitleaks and TruffleHog are commonly used for secret detection and can fit into a pipeline.
2. **Scan the inputs that will be rendered**, like log extracts or JSON payloads, before they ever become HTML.

If you already use GitHub’s secret scanning for repositories, it’s still worth scanning generated artifacts separately. GitHub describes how secret scanning alerts work, and its REST API exposes endpoints for working with alerts, but repo scanning does not automatically cover a file you generate on the fly in a CI workspace unless you commit it.

Practical rule: if the artifact never lands in Git, scan it where it’s produced.

Redact, then re-generate (don't edit by hand)

When the scanner finds a hit, avoid manually "editing the HTML" as the fix. It’s too easy to miss copies, minified blobs, or duplicated strings.

A safer loop:

1. **Fix the source** (logs, prompts, templates, data extract).
2. **Re-generate the HTML** deterministically.
3. **Re-scan the output** until clean.

This is where an agent workflow helps: the agent can redact inputs, regenerate, and only then call the publish tool (via MCP docs) or a deterministic script can publish via the API docs.

Publish with safety defaults (BinHTML workflow)

Once the artifact is clean enough to share, publish in a way that assumes you might need to respond quickly:

• Prefer unlisted or private visibility for early reviews (and confirm plan limits on /pricing before you automate a workflow).
• Keep the artifact sandboxed and restrict what it can load or call out to.
• Use a stable workflow for reviewers: one link, clear naming, and a short "what changed" note.

If you’re iterating on a report, use Compare before you resend links so reviewers can focus on what changed instead of re-reading everything.

For multi-output handoffs, publish a project index link and keep that index non-executable (metadata + links). See Project Share Pages: One URL for a Multi-Artifact Handoff.

What to do when you find a secret

If you find a real secret in a draft HTML artifact, treat it as already leaked. The correct response is usually:

1. **Rotate the credential** (or revoke the token) in the system of record.
2. **Remove it from inputs** so it won’t be re-emitted.
3. **Re-generate, re-scan, and republish**.
4. **Expire or revoke the shared link** if it was already distributed.

Secret management guidance (like OWASP’s Secrets Management Cheat Sheet) consistently pushes toward "don’t put secrets in places they’ll be copied". Generated HTML is one of those places.

If your team needs post-share traceability, pair this with Source Access: The Audit Trail for AI-Generated HTML so you can answer "who saw what" and "what exactly was published" when something goes wrong.