How to Audit an AI-Generated App Before Production

Quick Answer

To audit an AI-generated app before production, work through seven checks in order: secrets, access control, database rules, dependencies, injection and input handling, LLM feature risks, and rate and cost limits. Most of them can be started in an afternoon with free tools. The reason to bother is simple: Veracode's 2026 GenAI Code Security Report, published July 28, found that AI models pass about 56% of its security tests on average, roughly flat against the year before, while the generated code almost always compiles and runs. Working code and safe code are different things.

Why Does AI-Generated Code Need Its Own Audit?

AI coding tools are good at producing something that works on the happy path. They are less reliable at the parts nobody asked for: who is allowed to see a record, what happens when a request is malformed, and which keys end up in the browser.

Two patterns show up repeatedly in research:

• Exposed data from default settings. An UpGuard study published in late September 2026 checked about 300,000 domains that use Supabase and found 16,326 databases with publicly readable tables, about 5%. UpGuard attributes much of it to row-level security being on by default only for tables made in the Supabase dashboard, not for tables created through the API that coding agents use. Supabase's position, as reported by Cybernews, is that projects are secure by default and that customers control their configuration.
• Packages that do not exist. A USENIX Security 2025 paper (Spracklen et al., arXiv:2406.10279) tested 16 models on 576,000 code samples and found hallucinated package names in at least 5.2% of outputs from commercial models and 21.7% from open-source models. A fake name is an invitation for someone to publish a malicious package under it.

For the wider research behind these checks, including the RedAccess findings on exposed AI-built apps, see Thousands of AI-Built Apps Were Found Leaking Sensitive Data: What Businesses Should Audit Before Launch.

The Seven-Step Audit

1. Hunt for secrets

Scan the whole repository history, not just the current files.

gitleaks git -v .

gitleaks looks for passwords, API keys and tokens in git repositories and files. Then check what ships to the client. Supabase's own guidance is that a secret key (the old service_role key) bypasses row-level security and must never be used in a browser or shipped app, while the publishable key is meant to be public. Firebase API keys are public by design and protected by Security Rules and App Check, but Firebase's docs say a Gemini Developer API key should never be included in your code or configuration files.

2. Test access control with two accounts

Create two users. Log in as the first, copy a request that reads or edits one of its records, then replay it with the second user's session and with no session at all. If the record comes back, you have an insecure direct object reference. OWASP's broken access control guidance is explicit that access control is only effective in trusted server-side code or a server-less API, so hiding a button in the UI does not count.

3. Check the database rules

For Supabase, enable row-level security on every table in an exposed schema, then write policies that tie rows to the signed-in user.

alter table public.orders enable row level security;

create policy "Users read their own orders"
  on public.orders
  for select
  to authenticated
  using ( (select auth.uid()) = user_id );

Two traps from Supabase's docs: a policy written to anon using ( true ) gives every visitor read access, and raw_user_meta_data can be edited by the user, so it should not drive authorization.

For Firestore, Firebase's documentation says never to use the open test rules in production because they let anyone overwrite your entire database. A minimal owner-only rule looks like this:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

4. Audit dependencies

npm audit --audit-level=high
npm audit signatures

npm audit checks your dependency tree against registry advisories and needs a lockfile. npm audit signatures is separate and verifies registry signatures and provenance. Neither tells you whether a package is the one you meant to install, so read every dependency the assistant added and confirm that each name, publisher and download history looks real.

5. Review injection and input handling

Search for queries built from strings. Injection remains a top category in OWASP's 2025 web list, and generated code still produces it.

// Avoid: user input concatenated into SQL
db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);

// Prefer: parameterized query
db.query("SELECT * FROM users WHERE id = $1", [req.params.id]);

6. Review the LLM features

If the app calls a model, test it against the OWASP Top 10 for LLM Applications (2025 edition). Four categories matter most for a typical product: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency and LLM10 Unbounded Consumption. In practice, that means trying to make the model ignore its instructions, checking that it cannot see other users' data, listing every tool or action it can trigger and removing the ones it does not need.

7. Add rate limits, cost limits and logging

OWASP's API Security Top 10 lists unrestricted resource consumption as a risk because missing limits let attackers exhaust resources or run up third-party bills. Set per-user rate limits, a hard monthly spend cap on every model provider, and alerts when usage spikes. Keep logs that show who called what, without storing raw secrets or full prompts that contain personal data.

What Should the Audit Report Contain?

A useful report is short and ranked. For each finding, record where it is, how to reproduce it, how severe it is and what the fix is. Add a retest column so a fix is verified, not assumed. Keep a separate list of things you could not check, such as third-party SaaS settings, so the gaps are visible.

When Should You Bring In Outside Help?

Bring in a specialist when the app handles payments, health or other regulated data, when it has LLM features with tool access, when you are about to raise money or be acquired, or when nobody on the team wrote the code and nobody fully understands it. An independent reviewer also finds problems the original author has stopped seeing.

Which Companies Audit AI-Generated Apps? 5 Teams Worth Shortlisting

The firms below offer code audit, security testing or QA services. Figures come from each company's own website and are self-reported, so confirm them directly before signing anything.

1. Dev Technosys

• Founded: 2010
• Team Size: 250+
• HQ: Jaipur, India
• ISO 27001:2022 certified, ISO 9001:2015 certified and CMMI Level 3 appraised
• Five-stage AI-built app audit: discovery, code and architecture audit, AI functionality and data audit, security and risk audit, and a report with a prioritized remediation roadmap
• Core Services: AI-built app audit, AI code audit, LLM integration review, AI app rescue, application security assessment

Dev Technosys leads this list because its audit covers the same ground as the checklist above under one process: generated code and architecture, secrets and data exposure, LLM integrations and the risk and compliance review that sits on top, with findings ranked by risk. For a team that wants an outside party to do steps one to seven and hand back an action plan, that scope is the practical answer.

Best For: Teams with an AI-built app that need an independent audit with ranked findings and a fix-first roadmap.

2. Apriorit

Apriorit, a software engineering firm with a Lynn, Massachusetts address on its site, says it was founded in 2002 and employs 400+ people. Its software code audit service covers code review, architecture analysis, DevSecOps pipeline review, threat modeling, dependency scanning and cryptographic controls, and it references OWASP, CIS and FIPS. ISO 27001 and ISO 9001 badges appear on its site. Apriorit suits teams that want an engineering-led audit of a custom codebase rather than a scan report.

3. Software Secured

Software Secured, a Canadian application security firm that says it has operated since 2010, offers secure code review as a white-box service that combines static analysis with manual review of critical modules and a 120-point checklist. It also lists AI pentesting, and its site cites 2,000+ pentests in the last five years. Software Secured suits fast-growing SaaS teams that need code review and penetration testing in one engagement.

4. Trail of Bits

Trail of Bits, a security research firm that says it was founded in 2012, lists software assurance services with deliverables that include reports, exploit proofs of concept, CI-ready Semgrep and CodeQL rules and fuzzing harnesses. Its site cites 656 audits and 988 publications, and AI and machine-learning security is one of its practices. Trail of Bits suits teams with security-critical code that want research-grade review and rules they can keep running in CI.

5. Fluid Attacks

Fluid Attacks, which carries a "since 2001" tagline on its site, offers secure code review that pairs manual review with its own static analysis tooling. Its platform also covers dynamic testing, software composition analysis, penetration testing as a service and generative-AI remediation help, and it says it is a CVE Numbering Authority. It is partly a platform vendor, so ask how much of the work is human review. Fluid Attacks suits development teams that want continuous code and penetration-test coverage with human review.

Frequently Asked Questions

Is AI-generated code less secure than human-written code?

Not automatically, but studies show it often passes fewer security tests than it passes functional ones. Veracode's July 2026 report put the average security pass rate at 56%, so every generated change needs the same review as any other code.

How long does an AI-generated app audit take?

It depends on the size of the app and the scope, so expect a range from a few days for a small app to several weeks for a large one. Ask the vendor for a written estimate and a list of what is out of scope.

Can I audit an AI-generated app myself?

Yes, the seven checks above are a sound start for a developer. An outside audit adds an independent view and is worth the cost when the app handles regulated data, payments or LLM tools with real permissions.