The app code gate: twelve checks on every program the model writes
When Anticode's model writes an app, Sentinel reads the code before you see it and runs twelve security checks: one complete document under 400 KB, nothing loaded from or sent to other sites, no frames, no code built from strings, forms only through anticode.send, storage that works in the sandbox and no camera or location. Anything it catches goes back to the model once to be fixed, and publishing refuses an app that still fails.
Why check code the sandbox already contains
An app build runs inside a sandboxed frame whose policy allows no network, no frames and no form posts, so most dangerous code would simply fail there. The gate isn't the only wall; it's the early warning. A model that reaches for fetch to load live prices produces an app that looks finished and breaks the moment it runs. Catching that in the code, before anyone sees the app, means the model fixes it while it still has the context, and you never meet a half-working build. AI generated app security checks also give a plain record of what the code does and doesn't do, which the site's security report shows publicly.
The twelve checks
| Check | What it looks for |
|---|---|
| One complete HTML document | Starts with a doctype, has a head and a body, ends with the closing html tag |
| Under 400 KB | The same size cap as one published page |
| No scripts from other sites | Any script tag with a src |
| No stylesheets from other sites | Linked or imported CSS from anywhere but Google Fonts |
| No network calls | fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon, peer connections, service workers, importScripts and dynamic imports |
| Nothing loaded from or sent to other sites | Any absolute address in the code other than links, Google Fonts and standard namespace identifiers |
| No frames or plugins | iframe, frame, object, embed and similar elements |
| Stays on its own page | Opening windows, or changing the location of the page or its parent |
| No code built from strings | eval, new Function, and timers given a string to run |
| Forms stay in the app | A form that posts or has an action, instead of handling its submit event |
| Storage that works in the sandbox | Cookies, IndexedDB, the Cache API and the storage manager |
| No camera, microphone or location | getUserMedia, screen capture and geolocation |
Some things are allowed on purpose. Links to other sites are fine: Anticode's runner opens them in a new tab with no opener. localStorage works, because the runner answers it from memory and keeps it on the visitor's device. Fonts from Google Fonts are the one outside resource permitted. And a contact, booking or newsletter form reaches the owner through anticode.send; see app form sending.
The repair pass
After the model finishes writing, the gate runs. If anything fails, the build log shows a repairing step listing the failed checks, and the code goes back to the model with those failures and a request to fix them. This happens once. The repair must fix every security check except the document-shape one, along with the design gate and a readable declaration for any owner content the app shows.
Later steps can't undo the work. When a new build is reviewed in a headless browser and when a first build is polished, any edit that makes a check worse than before is thrown away and the earlier code stands. The results appear with the build, so you can see each check's status before you publish.
At publish, and afterwards
- The server reads the code itself. Publishing an app names a build, and the server takes that build's code from its own storage rather than accepting code from the browser, so only code Anticode's model wrote can be published.
- Every security check must pass, then the design gate, before the app goes live.
- The daily integrity scan re-runs them on the published code; see backups and integrity.
False positives
The checks read the code as text, so they can trip on words rather than behaviour. An app that teaches JavaScript and prints fetch(url) as an example will fail the network check, and a quiz that keeps a full web address in one of its strings, just to display it, will fail the outside-sites check. Asking for the example to be written differently, or the address shown without its protocol, usually clears it. A variable that happens to be called location is fine; only changing the page's real location fails.
Limits
- One automatic repair. If something still fails, ask for a change in words, or the app won't publish.
- Rules about reach, not logic. The gate checks what the code can touch. It doesn't check that a calculator's maths is right or that a game is fair.
- No exceptions for real data. An app can't be granted network access to fetch live data, however the request is worded. If you need a server, the Next.js export is the route.
Questions people ask
Can an Anticode app call an API?
No. Network calls fail the gate and are blocked by the sandbox. Anything that would need a server is simulated with sample data and labelled as demo data.
Why was my app blocked from publishing?
At least one security or design check still fails after the repair pass. The build's checks list which; ask for a change that removes it and publish again.
Is localStorage allowed?
Yes. It's answered by Anticode's runner and kept in the visitor's own browser. Cookies, IndexedDB and the Cache API aren't available in the sandbox.