Exposed API keys in an AI-built application: what an auditor sees

An application delivered in three days welcomes its first users and everything seems to work. An auditor opens it and checks the same three places. What they find, why the demo hides it, and what a business owner can require without reading code.

An auditor opening an AI-built application first looks for exposed API keys. On Hacker News (February 2026), a commenter claiming to audit these sites daily writes they found 'at least 30'. Measurement points the same way: large-model-generated code passes security tests 56% of the time, versus 55% a year earlier (Veracode, 2026 GenAI Code Security Report, July 28, 2026).

The first three places they look

The Hacker News comment names all three: founders ship Cursor-, Lovable-, or Bolt-built applications, obtain first users, celebrate, and leave exposed API keys, broken authentication, and exploitable endpoints in production. In business terms: a technical password sent with the page to visitors' browsers, an entry door not checking who knocks, and forms trusting incoming input. We detailed the first two in the public database test and our own visible key; the third deserves the same treatment without an instruction manual.

Why the demo reveals nothing

Veracode separates two things in its July 28, 2026 report. Code correctness, starting and doing what is expected, is solved: models compile and screens appear. Security has barely moved in a year, 56% versus 55%, with 44% of generation tasks producing a flaw. Breakdown is more telling than the average: 83% success for SQL injection and 87% for encryption algorithms, but 15% for cross-site scripting and 12% for log injection. The best tested model reaches 68%. An application can therefore pass your demo, serve ten clients, and remain open where nobody looks.

Nobody reviews

A French professional describes the same trend on r/developpeurs (July 2026), and we should specify they sell audit services: more sites are AI-assisted, often built by non-developers, democratising creation while multiplying basic flaws because nobody reviews code. Their most useful observation concerns SME-owner clients: they want a clear, understandable report, not an unreadable jargon-filled file. The request is reasonable and poorly served by the market.

What an owner can require without reading code

Four requests fit in French and can be verified. Ask for a list of technical keys and passwords, where each is stored, and written confirmation none is sent with pages to browsers. Ask for the rule stating who may read and modify each data type. Ask for proof of a test for that rule that fails when it is broken. Ask for the latest verification date. At Maestro these emerge from the method rather than goodwill: tests precede code, Félix runs them at each step, and keys live in macOS Keychain rather than project files. Our August defect showed both sides: the visible key came from us, and a tester spotted it.

What this does not replace

Human auditing remains superior, and we will not claim otherwise. Someone professionally trying to break your application finds things no automatic check seeks because they reason about your business, money flows, and users. Specialist scanners such as the Hacker News commenter's also belong before launch. Integrated verification helps prevent a thirty-page audit of avoidable mistakes and keeps its cost tolerable, related to the application that works without being secure.

Ask for the list tomorrow morning

Write to your provider or open your tool and request one thing first: every technical key and access credential, with storage location and last rotation date beside each. A clear one-page answer tells you someone handles it. An embarrassed answer tells you where to start, without reading a line of code.