AI website security scan before every publish

Why generated pages need their own scan

A model writing a web page optimises for something that looks right. It will happily paste an analytics snippet, point a contact form at a placeholder form service, add an onclick to a button or leave a test key in a comment. None of that shows in a screenshot. An AI website security scan has to read the markup itself, after every change, because each edit (yours, the model's or an agent's) is a new chance for one of those to creep in.

The twelve checks in four groups

Policy and scripts: A Content-Security-Policy with a default source; scripts blocked by that policy and no script tags; no inline event handlers such as onclick.
Forms: Text fields typed and length-capped; every field labelled; every form using POST to a path under this site's /api/; form-action locked to the site in the policy.
Links and transport: New-tab links carry noopener; every src, href and action uses HTTPS; a referrer policy is set.
Content: Nothing that looks like an API key, live Stripe key, AWS key or bearer token; every image has a text alternative.

The reasoning behind each rule, and how to check it by hand on any site, is in the AI website security checklist. The alt text and label checks are accessibility rules rather than security ones; they're here because they're checked on the same final HTML and are missed just as often.

Two places it runs

In the builder, the scan runs after every build, visual edit, code edit, change and restore. The results appear in the Report tab under Sentinel, with a count passed and a line of detail for each check, and on a multi-page site the detail names the page that failed. Pressing Publish runs the scan again on every page that would go live and refuses if any check fails.

On the server, publishing re-checks the page independently, so a browser that's been tampered with can't send unsafe HTML and have it accepted. The server parses the page with a real HTML tokenizer, decodes character references in attributes the way a browser would, and then checks again on the raw text as a second net. It refuses:

anything that isn't a complete HTML document;
scripts, frames, plugins, a <base> tag, a meta refresh or a link that loads script;
inline event handlers;
javascript: URLs, data URLs that aren't images, and styles that run script;
forms that don't POST to the site's own /api/ paths, or buttons that override the target;
anything loaded over plain HTTP, in markup or in CSS.

It doesn't repeat all twelve: rules such as labels and the referrer meta tag are covered in the builder, while the server concentrates on what could hurt visitors once a page is public. Published pages are also served with a policy header that forbids scripts, frames and plugins, so even a bypass couldn't run code.

Fixing a failure

When publishing is blocked, a card in the chat lists each failed check, says why it matters, and says what the fix is. If every failure can be repaired automatically, a Fix and publish button patches the HTML and tries again. The automatic fixes are mechanical: adding Anticode's standard policy and a strict referrer policy, removing script and frame tags, stripping event handlers, turning http:// into https://, pointing stray forms at the site's own endpoint, typing and capping fields, labelling unlabelled fields and adding noopener to new-tab links.

Two failures always need a person. A secret in the page should be revoked at its provider and then removed; if a connector needs it, store it there, where credentials are sealed and never reach the browser. A missing image description needs words only you can write, or a decorative image marked as such.

What Sentinel doesn't cover

The page, not the server behind it. It checks the HTML a visitor receives. Account security, server validation and data storage are separate; the security baseline adds a rule for sites that collect data.
Pattern matching for secrets. It looks for common key formats. A secret in an unusual format can slip through, so don't paste keys into page content at all.
Apps have their own gate. Model-written apps are checked by a separate app code gate with one automatic repair pass.
No scan of other sites. It runs on Anticode builds; it isn't a scanner you can point at any URL.

Questions people ask

Can I turn Sentinel off to publish anyway?

No. The builder won't publish a page that fails, and the server refuses pages that fail its own checks whether they come from the builder, the CLI or an AI assistant.

Does the server run every one of the twelve checks?

No. It re-runs the checks that matter once a page is public: scripts, inline handlers, javascript: URLs, form targets and HTTPS, plus a complete-document check. The rest run in the builder before publishing.

Will the automatic fix change how my page looks?

Rarely. The fixes add policy tags, attributes and labels, or remove script and frame elements that published pages can't run anyway.

Can visitors see the result?

Yes. Each published site has a public security report computed from its live pages; see the security report.