How We Keep AI-Written Code Secure: Defense in Depth for the Age of Generated Code
Contents
You can't keep AI-written code safe by "being careful."
Hand the work to an AI and the code grows several times faster than a person writes it, and the holes grow at the same pace: a permission left unclosed, a secret left sitting in the code, an input check that never got written. Once you've taken the speed, one person reviewing by eye no longer keeps up.
We moved the defense from attention to machinery, in six layers
Not one thicker wall, but several nets of different kinds layered together. From the outside in, each one has a distinct job and a distinct thing it stops.
Figure 1: Six layers, stacked from the outside in
Deep dive: why nothing rides on a single wall
There is no perfect defense, and something gets through every layer. That is exactly why we stack them rather than betting on one: when one is bypassed, the next one stops it.
The perimeter: drop it before a line of code runs
The outermost layer sits at the edge, sifting out bots and suspicious automated access before anything reaches the application. Indiscriminate scanning for vulnerabilities mostly disappears here, before a single line of our code runs.
Figure 2: Two nets that act before the application is reached
Deep dive: shrink the target before sealing holes
The signup form runs Turnstile behind the scenes to block bulk account creation by bots and automated abuse of the form. Before sealing holes, we simply don't let the suspicious traffic in. Reducing the size of the target is the first job.
Authentication is the one thing we don't build ourselves
Auth is where incidents start most easily, so the core is delegated rather than implemented here, keeping our own code minimal. Authentication is the one area we never have an AI write from scratch.
Figure 3: Delegating removes the room to build the mistake
Deep dive: what stops happening when there is no password
Passkeys use public-key cryptography with keys bound to the domain, so a user lured to a fake site has no key to hand over — phishing structurally fails. With no password in existence, neither leaks nor reuse damage occur. Session fixation and token forgery, the classic own-implementation mistakes, don't arise either, because we don't implement them.
The data boundary: bind every row to its owner, and close what opens by default
Past authentication lies the data boundary. Even if a permission check is forgotten one layer above the API, at the database layer that row returns only to its owner.
Figure 4: Putting the defense at the deepest point
Deep dive: a freshly created function is open by default
The awkward part is the initial state. A newly created function or table tends to end up reachable by anyone logged in, because the database hands its permissions to every authenticated user by default. Left alone, an ordinary user can call an elevated-permission function they should never reach (privilege escalation). So default-open grants are explicitly revoked, the function search path is pinned (to stop an attacker injecting a malicious schema and hijacking the elevated permission), and least privilege is maintained. Our standards also require enabling row-level security at the moment a table is created.
The customer-facing surface connects over MCP from a tool the customer has approved. With no credential held locally, key loss and key reuse cannot happen in the first place. Approval can be revoked at any time, and calls are rate limited.
The code itself: tip it to the safe side before it is written
Rather than fixing things afterwards, the standards decided up front are fed to the AI every time. The earlier something is caught, the cheaper it is to fix.
Figure 5: Four standards that tip the code to the safe side up front
Deep dive: what each one prevents
Allowlist validation and parameterized queries stop SQL injection and malformed values; escaping stops cross-site scripting. Keeping secrets in a vault means that if source ever leaks, the keys do not go with it. The double check on uploads stops disguised files. A security check also runs in the background while code is being written, stopping a dangerous pattern the moment it tries to get in.
CI as gatekeeper: a bundle of machine checks
Everything written passes through the CI gate. A person may think "it's probably fine", but if the machine goes red, it stops there.
Figure 6: Six checks that must all be green before a merge
Deep dive: it isn't only the code being watched
The information security management system itself is wired into CI. Controls and their evidence are held as documents that are the single source of truth, and the machine watches for "compliance drift" — controls and implementation gradually parting ways — and stops it. Security rules are not paperwork on a shelf here; they are something a machine polices.
Finally, layer a differently-descended pair of eyes, and a person
Holes like an unclosed permission can be missed in unison by AIs of the same lineage. A defect that several differently-angled reviews all slipped past was caught by an AI from a different family.
Figure 7: Shifting the shared blind spot with a difference in lineage
Deep dive: how this differs from a conventional, human-review-centred system
The absence of a perfect defense is equally true of systems built around human review. What differs is whether the defense rests on human attention or on machinery. Human-centred review varies with the reviewer's concentration and experience, and drops things as volume grows. Every layer above runs without tiring, without forgetting, at the same strictness on every PR.
So a system mass-produced with AI, put through this defense in depth, is not inferior in security to a conventional system built around human review. A machine net, never tired and never off guard, covers evenly. Speed of production and solidity of defense can coexist. That is the conclusion this year has led us to.
- Two-track review with Claude and Codex: surfacing blind spots with a different AI lineage
- How our micro-SaaS tech stack changed in a year
- What MCP changed: giving AI hands
- Posts on our development work (dev category)
Everything above is about defending our own code. Turning the same view outward — continuously inspecting how your company looks to an attacker — is PentaTrail / CTEM.
Appendix: what each layer does, and what it stops
Table 1: the six layers
| Layer | What it does | What it stops |
|---|---|---|
| Perimeter | Sifts out bots and suspicious automation at the edge | Indiscriminate scanning, automated bulk access |
| Delegated auth | Delegates the core to passkeys and external login | Phishing, password leaks, session fixation, token forgery |
| Data boundary | Binds every row to its owner, closes default-open grants | Tenant crossing, privilege escalation |
| Coding standards | Feeds pre-agreed standards in on every pass | Injection, XSS, embedded secrets, disguised files |
| CI gatekeeper | Runs a bundle of machine checks, blocks until all green | Regression, misread authorization, supply chain, committed keys |
| Two-track review | Layers a different AI lineage, with a person at the end | Defects a single lineage misses in unison |
Table 2: the checks running in CI
| Check | What it stops |
|---|---|
| Secret scanning | Intrusion via a key or token committed by mistake |
| Permission gate | Elevated-function and anonymous-access holes reaching a merge |
| Permission tests | A sealed hole reopening through a later change |
| Integration tests | Behaviour, including auth and permissions, being misread |
| Types, build, lint | Deviation from the standards |
| Dependency gate | Pulling in a freshly published malicious version via auto-update |
Table 3: the standards decided before writing
| Standard | What it stops |
|---|---|
| Validate input against an allowlist, parameterize queries | SQL injection, malformed values |
| Escape values rendered to the screen | Cross-site scripting |
| Keep secrets out of code, in a key vault | Keys leaking along with the source |
| Check extension and content type on uploads | Disguised files getting in |
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
