An AI-generated landing page can look ready for a client while carrying a live credential in a JavaScript block, an HTML comment, or a copied configuration snippet. To scan HTML for API keys before sharing is not a ceremonial security step. It is the difference between catching an accidental exposure in the draft and discovering it after the link has been forwarded, cached, or pasted into a ticket.
The risk is especially common when teams ask an AI assistant to produce a working prototype. The output may include placeholders that look like keys, real values copied from a prompt, or client-side code that was never meant to contain a privileged credential. A polished page does not make the underlying code safe to distribute.
At Synergetics Worldwide, Dwight Brenner asked one question about the new AI-built pricing microsite: "What happens when a prospect hits view-source?" The room treated this as pedantic until he read the answer aloud from line 41 — a live Stripe test key, plus a comment reading // swap before demo. The demo had been three weeks earlier.
Know what a key scan should inspect
A useful HTML secret scan examines more than visible page text. It should inspect the full document, including inline JavaScript, CSS, HTML comments, metadata, hidden fields, JSON blobs, embedded configuration, and copied command examples.
API keys and tokens commonly appear in code patterns such as Authorization: Bearer ..., api_key=..., x-api-key, or provider-specific prefixes. Passwords, database connection strings, private keys, session tokens, webhook URLs, and cloud credentials deserve the same attention. A key that is valid only in a staging environment is still an access credential, and staging systems often contain production-like data or integrations.
Do not rely on a browser preview alone. Browsers render what they are designed to render, not every artifact in the source. An HTML comment containing a token will not appear on the page, but it remains available to anyone who can view source or download the document.
Scan before a link exists
The safest point to detect a secret is before the HTML becomes a shareable asset. Make scanning part of the publishing workflow rather than a separate task someone is expected to remember after the deadline has become decorative.
In HTMLvault, paste or generate the HTML in the editor and review automatic secret-scanning findings before creating the secure link. The scanner is regex-based and runs at zero token cost, and it flags nine categories: api_key, ssn, financial, passport, address, person, dob, email, and phone. For this workflow, api_key is the category that catches tokens, bearer credentials, and password-shaped strings. Treat a finding as a stop sign until someone determines whether it is a real credential, a placeholder, or a false positive.
This workflow matters for teams publishing through an API as well. If an internal tool, AI workflow, or automation creates links programmatically, route generated HTML through the same controlled publishing path. HTMLvault exposes the scanner directly: call scan_html over the REST API or the MCP server (the same tool surface available to Claude, ChatGPT, Zapier, Clay, and Gemini) to inspect content before create_link ever runs. A fast workflow that bypasses inspection is fast in the way a missing guardrail is fast.
Separate public identifiers from secrets
Not every string that resembles a credential should be removed. Some services use publishable identifiers in client-side code by design. Analytics measurement IDs, public map identifiers, and certain client-side application keys may be intended for browsers to receive.
The question is not whether a value has the word “key” in its name. Ask what the value can do if copied by an unknown person. If it can read private data, write data, send messages, administer an account, bypass a quota, or impersonate a service, it does not belong in distributed HTML.
When a value is intentionally public, document that decision. This helps the next reviewer distinguish an approved client-side identifier from a credential that simply survived because everyone assumed someone else had checked it.
Triage a finding without guessing
When a scanner flags a value, first determine whether it is active. Search the relevant service's credential inventory, check the environment where it was issued, and identify its permissions. Do not paste the suspected value into chat, email, or a public issue to ask whether it is real. That turns an internal finding into a broader distribution event.
If the value is active, revoke or rotate it promptly. Deleting it from the HTML is necessary, but it does not invalidate copies already created during drafting, testing, or sharing. Rotation replaces the exposed credential with a new one; revocation disables it entirely. Which action makes sense depends on the service and whether the credential is still required by an application.
Then remove the value from the document and replace it with a neutral placeholder such as YOUR_API_KEY only if the recipient genuinely needs implementation guidance. For a sales proposal, client report, or campaign landing page, the better answer is usually to remove the configuration example altogether.
A flagged string can be a false positive. Long random IDs, example hashes, and opaque application references sometimes resemble tokens. Do not train people to dismiss alerts by default. Mark the finding as reviewed, preserve the rationale in your normal change record, and tune organizational rules where the pattern repeatedly creates noise.
Keep privileged work off the client
A scan catches accidental exposure, but architecture prevents the same mistake from recurring. Browser-delivered HTML is client-side material. Anyone receiving it can inspect, copy, and modify it. A secret embedded there should be treated as disclosed.
Move privileged API calls to a server-side service or backend workflow. The browser can call your controlled endpoint, and that endpoint can use the credential without returning it to the visitor. Apply authentication, authorization, rate limits, and narrow credential scopes based on what the workflow actually needs.
There are trade-offs. A server-side proxy adds implementation work and may introduce latency. For a static demonstration, replacing live API behavior with mocked data can be the cleaner option. For a production-facing page, the operational cost of a small backend is generally lower than the cost of letting a reusable credential circulate in page source.
Protect the page after it passes scanning
A clean scan does not mean the document is harmless. It may still contain a client list, pricing, proposal terms, employee information, or material that should not remain available forever. Secret scanning and controlled sharing solve related but different problems.
Before publishing, use PII detection to identify personal information such as email addresses, phone numbers, Social Security numbers, dates of birth, passport numbers, physical addresses, and names. That detection is the same regex engine as the secret scan, so it identifies common structured patterns without consuming AI tokens. Review the results and use one-click redaction where the recipient does not need the original value.
Teams and Enterprise plans can add a second scan layer on top of the regex pass using BYOK AI: connect your own Anthropic, OpenAI, or Google API key and the AI review catches context the patterns miss — an unlabeled credential, a client name in prose, a comment that describes a system rather than matching a format. You supply and control that key, and HTMLvault never funds the tokens.
Set an expiry that matches the purpose of the share. A one-hour or one-day link may suit an internal review of generated HTML. A proposal may need a longer window, but it should still have an end date rather than quietly becoming a permanent file repository. On Free, links expire after 30 days and data is retained for 90; Pro makes expiry configurable from one hour to never and lets you configure retention windows separately, from auto-delete up to two years, so content disappears when the business purpose ends.
Password protection can add a useful access layer for a sensitive link, but it is not a substitute for removing secrets. If a live API key is in the source, every authorized recipient can still copy it. Links are never indexed by search engines, which removes one exposure path but not the forwarding path. For higher-control teams, custom roles and permissions, organization-wide publishing rules, and PII audit logs provide the governance IT needs; SSO/SAML is a paid add-on on Teams and included with Enterprise.
Use analytics without adding exposure
Sales and marketing teams often need to know whether a proposal or landing page was opened, how long it held attention, and whether a recipient reached the pricing section. That is a legitimate reason to share HTML as a link rather than an attachment.
Use a branded subdomain or your own custom domain so recipients see a recognizable sender identity — Pro includes one white-label domain, Teams one to three depending on seat band, and Enterprise three. Track total views, unique visitors, repeat visits, country and city, device and browser, referrer source, scroll depth, and time on page according to your team's policy. Per-recipient tracked URLs, created with create_recipient_links, show which stakeholder engaged, while server-side channel attribution from UTM parameters helps RevOps understand how a link reached them. If you inject your own tracking codes, remember that those snippets are part of the document the scanner inspects.
The boundary is straightforward: collect the analytics needed for a business decision, disclose and govern the practice appropriately, and do not use tracking as an excuse to keep sensitive content online indefinitely. Expiry and retention controls remain useful even when engagement is strong.
Make the check repeatable
The best process is short enough that people actually use it. Before each publish, inspect scan findings, verify whether any suspected secret is active, remove or rotate real credentials, review PII, and set access, expiry, and retention controls appropriate to the audience.
For recurring workflows, make that sequence part of the automation design. Have the automation call scan_html first and only proceed to create_link or create_links when the findings are cleared or explicitly reviewed; use patch_link to tighten expiry after the fact rather than leaving a link open because changing it felt like extra work.
The person publishing a proposal, report, or generated landing page should not have to choose between moving quickly and passing security review. A reliable HTML scan gives them a practical answer: remove what cannot be shared, control who receives the rest, and leave a record that makes approval easier rather than ceremonial. The rep gets the link out before lunch, and the security lead gets the one thing he has never had — proof that the source was checked before anyone could forward it.