Give AI-generated reports a private URL your team can actually use.

AI agents can produce polished HTML summaries, QA reports, research dashboards, and model evaluations. The last mile is usually awkward: the file exists locally, but the team needs a secure link.

• Generated reports are hard to review when they stay on one machine
• Public static hosting is risky for internal analysis
• Manual uploads break repeatable agent workflows

Let the agent write the artifact locally, then use a human-owned CLI session or scoped environment secret to publish it. The report generator does not need to invent hosting or authentication, and the private viewer URL stays stable while the underlying version changes.

• Works with local scripts, CI jobs, and coding agents
• Supports create-once and update-later flows
• Keeps token handling outside the generated report

npx @internalpage/cli publish ./agent-report.html --slug agent-report

Treat the generated file as content that authorized viewers can inspect. The publishing token belongs in the CLI config, local environment, or CI secret store—not in the prompt, HTML source, agent transcript, or committed configuration.

• Give the agent a publish command without exposing the token value
• Review generated links, scripts, and embedded data before publishing
• Remove customer secrets and raw production credentials
• Rotate a token if it appears in output or logs

Google sign-in limits who receives the page; it does not make embedded secrets safe.

Choose a stable slug for each recurring report series. Future runs can replace the page behind that slug, allowing runbooks, tickets, and bookmarks to keep pointing at the same destination.

• Use one slug for each audience and report lifecycle
• Publish only after generation and validation succeed
• Create a new slug when access rules or ownership change

npx @internalpage/cli publish ./agent-report.html --slug agent-report --json

Use this pattern for outputs that humans read after generation, not for agent services that must run continuously or perform privileged actions from the browser.

• LLM eval dashboards
• Security or dependency audit pages
• Customer research summaries
• Data pipeline health reports
• Pull-request walkthroughs and release summaries

Open the local file first, then verify the published page with the same care as other generated code. Check the title, data freshness, links, external assets, responsive layout, and both allowed and denied access paths.

• Make generation time and source data clear in the page
• Confirm charts and assets render without local file paths
• Test an authorized and unauthorized Google account
• Keep the generator and publish command under version control