What an Application Security Audit Actually Finds in an AI-Built App

Someone asks whether your app has been security audited. You say something like yes, meaning the AI flagged nothing while it built, the tools never complained, and nothing has gone wrong. That is not an audit. The distance between those two things is exactly what this post is about.

An application security assessment is a structured review of your code, infrastructure, logins and dependencies by a person who knows what to look for. For AI-built apps, what that person finds is remarkably consistent. The same five problems, over and over, and none of them visible while the app works.

What Is an Application Security Audit?

A structured examination of four surfaces: the source code, the infrastructure configuration, the authentication flows, and the dependency chain, done by a human reviewer who knows where applications actually fail. Not a linter. Not a dependency scanner. Not asking the AI that built it whether it did a good job.

The standard definitions in the field say roughly this. StackHawk's widely-read guide calls it "a comprehensive assessment of the security posture of an application or system."^[2]

Accurate, and worth noticing the date on it: November 2022, three years before the current generation of AI coding tools existed. The category was defined for code where every line was a decision someone made, and that assumption is the one that no longer holds.

Why Are AI-Built Apps a Different Audit Target?

Because their failures are absences, not mistakes. AI coding tools generate confident, working code and scaffold the happy path. What they do not do is make the dozen unglamorous decisions that keep a working app from being an exposed one, and the person prompting rarely knows those decisions existed.

The result is a specific structural pattern. Configuration steps skipped because nothing was blocking. Placeholder values promoted to production because nothing failed. Access policies scaffolded as disabled stubs and never enabled.

We wrote about the measured version of this: roughly 45% of AI-generated code carries a known vulnerability, a rate that has not improved in two years, with the failures clustered in exactly the classes a casual reading never catches.

A hand-written app fails where a developer decided badly. An AI-built app fails where nobody decided at all.

What Does an Audit Actually Find in an AI-Built App?

Five findings account for most of what a structured review turns up in apps built with tools like Cursor, Lovable, Bolt or Replit. Each one is ordinary, consequential, and invisible from the outside.

• Service keys visible in the browser. A key written into the frontend during scaffolding, readable by anyone who opens the developer tools. Whether that is dangerous depends entirely on what the key can do, which nobody checked.
• Row-level security missing or disabled. The database rule that stops one user reading another's data. Tools scaffold the tables; they do not always scaffold the rules, and a builder testing alone never notices, because they were always the only user.
• Secrets in version history. A key committed early, deleted later. It is gone from the code you see and fully present in the history anyone with repo access can read. Rotation is the only fix, and rotation requires knowing.
• No server-side input validation. The form checks your data politely in the browser; the route behind it trusts whatever arrives. The AI built validation for user experience, not for hostile input.
• Public storage buckets. File storage configured with permissive defaults during setup. Uploads and internal documents reachable by URL, no login required.

None of these announce themselves. Every one of them ships inside an app that works.

What Happened With Moltbook?

Moltbook is the cleanest before-picture on record. A social network for AI agents, launched January 28, 2026, built by a founder who is proud of exactly the thing that matters here.

Within days of launch, researchers at the cloud-security firm Wiz found the database misconfigured: the row-level security layer was missing entirely.^[1] The key in the app's client code was a publishable key, safe by design when the access rules are on. With the rules off, it handed full read and write access to anyone, no account needed.

The exposure included 1.5 million API authentication tokens, 35,000 email addresses, and thousands of private messages between agents.

Two details make this a fair story rather than a gotcha. Moltbook patched fast: fully fixed within about three hours of Wiz's report. And the failure was not carelessness in any ordinary sense.

It was a fast builder using the best tools available, shipping a real product that real people used. The tools did what they do: they made it work. Nobody involved knew there was a decision that had not been made.

Wiz found it in days. The builder had not found it at all. That gap, between how long an exposure takes to find when someone knows where to look and how long it survives when nobody does, is the entire case for an audit.

What About the Security Checklist You Already Ran?

Checklists verify that decisions were made correctly. They are weak against decisions that were never made. Most were also written for hand-built apps, so they check the places developers err, not the places AI tools silently default.

Here is the concrete version. "Enable row-level security" is on every checklist, and an AI-built app often passes it, because a policy technically exists in the schema. The audit catches that the policy is a scaffolding placeholder that blocks nothing and has been waving everything through since launch.

Present is not the same as working, and only a reader who knows the pattern looks past the first answer.

This is the same gap an acquirer's technical due diligence runs into: the standard line items are correct and incomplete. The list was built for a world where someone chose every line.

What Does the Assessment Cover, and What Does It Cost?

Four reviews, and for a small-to-medium AI-built app they add up to days of work, not weeks:

• Source code: credential exposure, input validation, what the routes trust
• Infrastructure: storage permissions, database access policies, who can touch what
• Authentication: sessions, token storage, third-party sign-in wiring
• Dependencies: known vulnerabilities in the package tree

The honest answer on cost is that it scales with three things: surface area (how many routes, forms and integrations exist), data sensitivity (payment and health data raise the bar), and how many separate systems are involved. AI-built apps are usually the bounded case, one framework and one managed backend, so both the scope and the price are knowable up front.

What you get is not a certificate. It is a written map of what touches your data, what was found, and what to fix in what order, which is the document every other production-readiness question keeps turning out to need.

The Part Worth Sitting With

The Moltbook finding was not exotic. A first-pass review by someone who knows where AI-built apps fail catches it in under an hour, because it is the second thing on the list they check. What made it a headline was not the sophistication of the flaw. It was that nobody who knew the pattern had ever looked.

Your app works. That was never in question, and it answers nothing.

If it holds real users and real data and no one outside the build has done a structured review, the five findings above are not a scare story. They are a description of the base rate, and finding out which ones apply to you is a bounded, days-long piece of work.

The builders who come out of this well are the ones who found out from a reviewer instead of a researcher.