Keys and tokens in the page: what Sentinel looks for before anything ships
Anything in a web page's HTML can be read by anyone who opens it: view source, save the page, or fetch it with a script. So a secret key in the page isn't hidden, it's published. Sentinel scans the full HTML of each build for the shapes of common keys and tokens and fails the page if it finds one, before the page goes anywhere.
How keys end up in front-end code
It's one of the commonest mistakes in AI-built sites. Someone asks for a form that saves to their spreadsheet or a page that calls a payment service, pastes their key into the request so the model can “wire it up”, and the model writes it straight into the page. The site works, and the key is now public: an API key exposed in HTML is as good as posted on a noticeboard. Automated scanners search the web and public code for exposed keys continuously, so a leaked one can be found and misused quickly. The guide on API keys in front-end code explains the general rule: a secret belongs on a server, never in the browser.
What the scan matches
The scan runs over the whole HTML of the page, head, styles and markup included, not just the visible text, and isn't case-sensitive. It looks for:
| Pattern | What it usually is |
|---|---|
sk- followed by 12 or more letters and digits | A secret key in the style several AI and API providers use |
sk_live_ | A live Stripe secret key |
pk_live_ | A live Stripe publishable key |
AKIA followed by 16 capitals and digits | An AWS access key ID |
api_key, api-key or apikey followed by : or = | A key assigned in configuration or code |
bearer followed by a 16-character or longer token | An authorisation token copied from a request |
The Report tab shows “No keys or tokens in the page” when it passes, with a note that it scanned for API keys, live Stripe keys, AWS keys and bearer tokens.
Why a publishable key is flagged too
Stripe's publishable keys are designed to be used in browsers, so it may seem odd that pk_live_ fails. On an Anticode page, though, there's no legitimate use for one: design-engine pages run no scripts, and payments go through a payment link from the owner's own provider, which needs no key in the page. A live key in a page is therefore a sign that something was pasted in by mistake, and often that its secret sibling is nearby.
Where Anticode keeps real credentials
The parts of Anticode that genuinely need secrets keep them out of pages entirely. Credentials for form connectors, such as a Slack webhook or an Airtable token, are sealed and write-only: once saved they can't be read back, and they're used by the server, not the page. Site functions that call the owner's own endpoint sign each call on the server instead of exposing a shared secret. If a feature you want seems to need a key in the page, it's the wrong design for that feature.
If a real key is found
- Assume it's compromised. If the page was ever public, or the key was ever in a repository, treat it as seen.
- Revoke or roll it at the provider. Create a new key and disable the old one in the provider's dashboard. Removing it from the page doesn't undo the exposure.
- Check for use. Look at the provider's logs and billing for activity you don't recognise.
- Remove it from the page. Ask for the change in words, or edit the text, so the scan passes.
- Move the job server-side. Use a connector, a site function or the Next.js export, where secrets live in server configuration.
Limits
- Known shapes only. Keys from many other services have formats the scan doesn't know. A pass means none of these patterns appeared, not that the page is free of secrets.
- False positives happen. A tutorial page that shows an example such as
api_key=will fail. Rewrite the example or describe it in words. - Builder scan, not publish gate. This check is part of Sentinel's scan in the builder; the server's publish gate checks scripts, handlers, script URLs, form targets and HTTPS, not keys.
- Pages only. App builds have their own code gate.
Questions people ask
Is it safe to put an API key in HTML?
Only if the provider designed that key to be public. A secret key in a page is readable by anyone. Sentinel flags common secret and live key patterns for that reason.
I removed the key from my page. Am I safe?
Not yet. If the page was public, revoke the key at the provider and issue a new one. Removing it stops further exposure but doesn't undo what's already been seen.
How do I find API keys in a page's source?
View the source and search for prefixes such as sk_, pk_live_, AKIA, api_key and bearer. Sentinel does this automatically for Anticode builds.