airtight

Airtight

AI writes your code. Who checks it?

Correct-looking code can still be unsafe, and the gap is rarely where people expect. Asked for "a login endpoint", a competent model writes a good one: the password gets a memory-hard KDF, the cookie gets httpOnly, the record lookup carries the owner. It knows all of that unprompted.

What it does not write is the part nobody mentioned. No rate limit, so the endpoint can be ground through a password list at full speed. No attempt counter, so nothing ever locks. No log line, so the grinding is invisible while it happens and unreconstructable afterwards. The developer asked for a login endpoint, not for one that survives contact with an attacker.

The default AI mistake is omission, not incompetence. Weight the gates accordingly: the ones that catch a missing bound, a missing counter, a missing record are the ones earning their place. Airtight is the part of the request nobody makes.

Scope — state it honestly, always

Airtight covers the well-known safe-coding mistakes AI makes by default: the errors that recur in nearly every AI-assisted app because the developer asked for a feature, not a safe feature.

Airtight does not cover:

• business-logic errors that require domain knowledge (should this user be allowed to refund that?)
• unknown flaws in third-party dependencies
• poor architecture
• memory safety in systems languages — buffer overflows, use-after-free, format strings. The registry is web-shaped. In C, C++ or unsafe Rust it has something to say about a request handler and nothing at all about the allocation underneath it. Say so rather than implying a clean pass.

Never say or imply the code is "secure" or "fully covered". Say what was checked and what was not. A safety tool that overpromises loses trust the first time it misses. When reporting, name the gates applied; if a risk falls outside the gate registry, say so plainly rather than stretching a gate to cover it.

The gates are yours to keep unless a guard holds them