A working AI-built product answers one question: does it run? An AI code audit answers the next one: will the product hold up when real users, real personal data and a customer’s security team arrive? This article covers the audit of software whose code was written largely by AI tools. Audits carried out by AI tools are a separate question, answered in the section on choosing a provider.
The article follow name the five review areas, the four engagement stages, the three deliverables, and how an audit compares with an automated scan, a penetration test and a secure code review. For the wider route from prototype to live product, read the founder’s guide to ai-generated code in production.
TL;DR
An AI code audit is an independent review of a product whose code was written largely by AI tools such as Lovable, Bolt, Replit or Cursor, checking whether the product is safe and maintainable for real users. The audit supports one decision: launch, sell to an enterprise customer, raise funding or hand the product over to engineers.
- Five review areas make up an AI code audit, each run as a workstream with its own evidence: access and data security, architecture and code quality, critical workflows, deployment and operations, and ownership and handover.
- Four engagement stages structure the audit: scoping, review, report and read-out, and an optional remediation and re-test stage that the contract defines separately.
- Three deliverables come out of the audit: findings with evidence, a prioritised action plan (fix now, can wait, where to start) and a technical handoff that a team or an AI coding tool can act on.
- An AI code audit comes first for a pre-launch AI-built product; a penetration test is added when the threat model or a customer calls for proof that the running product resists attack, and a secure code review fits a mature codebase that needs security-only depth.
Preparing for launch, an enterprise security review or an engineering handover?
A scoped AI-built product review gives you evidence-backed findings, a prioritised fix order and a technical handoff. See what Sunbytes reviews before you commit to the next milestone.
What is an AI code audit?
An AI code audit is an independent review of a software product whose code was written largely by AI tools, checking whether the product is safe and maintainable enough for real users. The term means an audit of AI-generated code, not an audit performed by an AI tool; AI audit tools are one input to the review, not the review itself.
Products built with Lovable, Bolt, Replit or Cursor reach a working state quickly, and that is what those tools are for. The tools do not decide who may read which data, where the keys to paid services are stored, or what happens when a payment fails halfway. An AI code audit checks those decisions across the whole codebase, at the points where code generated from different prompts meets.
The risk is measurable. The Veracode 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks: the generated code introduced an OWASP Top 10 vulnerability in 45% of the coding tasks.
An AI code audit is not a certificate and not a penetration test. The audit reads source code, configuration and infrastructure settings, and it produces findings with a fix order rather than a pass or fail stamp. Founders also search for the same service as a vibe code audit or a vibe coding audit.
When an AI-built product needs a code audit
An AI-built product needs a code audit before the first moment someone outside the founding team depends on the code or inspects it. Five events mark that moment:
- Real users or personal data are about to go in. From that point, GDPR Article 32 requires security measures appropriate to the risk.
- An enterprise customer sends a vendor security questionnaire. Many questionnaires follow from NIS2 (Directive (EU) 2022/2555) Article 21(2)(d), which requires in-scope organisations to manage supply chain security, including their relationships with direct suppliers and service providers.
- An investor starts technical due diligence.
- You hire the first engineer or hand the product to an agency.
- Bugs or outages cluster in the weeks after launch.
If none of the five events applies yet, for example a prototype with test data and no paying users, the audit can wait until one of them does.
What an AI code audit covers: five review areas
An AI code audit covers five review areas, and each one runs as a workstream with its own checks and its own evidence: access and data security, architecture and code quality, critical workflows, deployment and operations, and ownership and handover. For a buyer, the useful scope question is what the reviewer verifies in each workstream and what proof comes back in the report. The failure patterns themselves are described in the founder’s guide under where AI-built products break and, for security, in vibe coding security risks.
| Audit workstream | What the reviewer verifies | Evidence in the report |
|---|---|---|
| Access and data security | Authorization enforced across relevant roles and records | Tested role and endpoint, evidence of unauthorized access where found |
| Architecture and code quality | Duplicated logic, coupling, maintainability constraints | Affected modules, examples, remediation approach |
| Critical workflows | Failed transactions, error states, recovery behavior | Test scenario, observed result, expected behavior |
| Deployment and operations | Configuration, monitoring, backup and release controls | Configuration findings, missing controls, recommended actions |
| Ownership and handover | Documentation, tests, dependencies and support responsibilities | Missing artifacts, ownership gaps and handover requirements |
A finding enters the report only after the reviewer has validated it. For access and data security, the reviewer reproduces the issue with test accounts in at least two roles and records the request and the response. For critical workflows, the reviewer runs the failure scenario and records the observed result next to the expected behaviour. A suspected issue that cannot be reproduced is reported as a risk to investigate, with the reason it could not be confirmed.
Security findings carry an OWASP Top 10:2025 category where one applies, for example A01:2025 Broken Access Control for a role that can open another customer’s records. Findings about code quality, tests, documentation or ownership are reported without an OWASP label, because the OWASP list classifies security risks, not engineering quality. For EU products that hold personal data, the access and data security evidence also supports GDPR Article 25 (data protection by design and by default) and Article 32 (security of processing).
Not sure which of the five areas is weakest in your product?
An AI-built product review checks all five in one pass and explains every finding in plain English: what we found, why it matters for your launch, and what to fix first. Engineering and security are reviewed together, so you get one prioritized list instead of two reports that disagree.
AI code audit checklist: 12 checks for an audit proposal
An AI code audit checklist for buyers tests the proposal, not the product: 12 checks show whether the scope, the evidence and the terms cover what the audit has to prove. Use it to compare offers before signing.
| # | Check in the proposal | What a complete answer looks like |
|---|---|---|
| 1 | All five workstreams in scope | Each workstream named, with exclusions stated |
| 2 | Roles and records tested | The user roles and data types the reviewer will test access for |
| 3 | Critical workflows named | Signup, payment or other flows listed, with the failure scenarios to run |
| 4 | Environments covered | Which environments and which configuration the reviewer reads |
| 5 | Dependencies and licences | Whether third-party packages are checked for known vulnerabilities and licence conflicts |
| 6 | Evidence per finding | Location, reproduction steps or test result, and severity for every finding |
| 7 | Validation method | How findings are confirmed, and how unconfirmed risks are labelled |
| 8 | Prioritisation method | How severity and fix order are set against your decision and date |
| 9 | Report format and read-out | A sample finding or report extract, plus a read-out with the decision owner |
| 10 | Confidentiality and access | Read-only access, named reviewers, an NDA and how code access ends after the audit |
| 11 | Independence | Who builds or fixes the product, and whether the reviewer is separate from that work |
| 12 | Re-test terms | Whether re-testing is included, how many rounds and within what period |
Checks 6, 7 and 12 are the ones a scanner-based offer cannot answer: a scan output has no reproduced evidence, no validation step and no re-test terms.
How the AI code audit process works
An AI code audit engagement runs in four stages, and each stage has a client input, a reviewer activity and an output that marks the stage as done. Stages 1 to 3 are the audit itself. Stage 4, remediation and re-test, is a separate scope that the contract has to define.
| Audit stage | Client input | Reviewer activity | Output or acceptance point |
|---|---|---|---|
| 1. Scoping | The decision the audit supports, environments, user roles, read-only repository access | Agrees workstreams, critical workflows and exclusions; confirms access and confidentiality terms | Signed scope with workstreams, workflows in scope and report date |
| 2. Review | Answers to reviewer questions; a test account per role | Reviews code, configuration and deployment across the five workstreams; tests critical workflows and role access | Draft findings, each with evidence |
| 3. Report and read-out | Decision owner and technical lead attend the read-out | Prioritises findings and walks through evidence and fix order | Final report accepted: findings, prioritised action plan, technical handoff |
| 4. Remediation and re-test (optional) | Fixes by your team, your AI coding tool or a partner; list of findings claimed as fixed | Re-tests each claimed fix against the original evidence | Re-test result per finding: closed, partly closed or open |
Remediation and re-testing are not part of the audit by default. Agree three terms before scoping closes: whether a re-test is included, how many rounds, and within what period after the report. Without those terms, a fixed finding has no agreed way to be closed.
What to prepare before the audit
Five inputs let the review start on day one:
- Read-only access to the code repository.
- A list of environments (development, staging, production) and third-party services such as payments, email, login and AI model APIs.
- The user roles and what each role may see or change.
- Known issues, bugs and outages so far.
- The decision the audit must support, and its date.
Code access is the founder’s first confidentiality question, and the answer to ask for is concrete: only named reviewers see the code, access is read-only, and an NDA covering the code and the findings is signed before access is granted. At Sunbytes, code access is handled under an ISO/IEC 27001:2022-certified information security management system (ISMS).
Timeline and cost
The timeline and cost of an AI code audit depend on four drivers: the size of the codebase, the number of user roles and integrations, the number of environments, and whether a re-test is included. A fixed scope agreed in the first stage sets both before the review starts. Our ai code audit cost explains how each driver moves the price.
What you receive: audit deliverables
An AI code audit delivers three things: clear findings, a prioritised action plan and a technical handoff. Each deliverable is written so a non-technical founder can decide and an engineer or an AI coding tool can act.
- Clear findings: what was found, why it matters, and the evidence (file, endpoint, request and response).
- Prioritised action plan: what to fix now, what can wait, and where to start.
- Technical handoff: instructions your team or an AI coding tool can act on.
| Field | Content |
|---|---|
| Title | Any logged-in user can read other customers’ invoices |
| Severity | High · OWASP A01:2025 Broken Access Control |
| Where | Invoice endpoint, GET /api/invoices/{id} |
| Evidence | Logged in as test user A, requesting an invoice ID that belongs to test user B returns B’s invoice with name, address and amount. |
| Business impact | Every customer’s personal data is open to every other customer. The finding is a security vulnerability; it becomes a personal data breach only if the access logs show that another account’s invoice was actually opened. If that is confirmed, GDPR Article 33 requires notifying the Autoriteit Persoonsgegevens within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to the customers affected. |
| Fix | Check on the server that the invoice belongs to the logged-in user’s account before returning it; add an automated test for cross-account access, and check the access logs for cross-account requests. |
| Effort | Small: one shared access check, applied to every endpoint that returns customer records. |
A scanner export is not an audit report. A scanner lists pattern matches with severity scores; an audit finding adds the business impact, the evidence that the issue is reachable and its place in the fix order. A full example of a code audit report shows how the three deliverables fit together.
AI code audit vs penetration test vs secure code review
An AI code audit is the first check when the decision is whether an AI-built product is ready for real users. A penetration test or a secure code review is added when the risk calls for more depth in one direction, and the choice depends on the threat model and the data the product holds as much as on a customer request.
| Situation | Recommended check | Why |
|---|---|---|
| Pre-launch or newly launched AI-built product; the decision is launch, sale, funding or handover | AI code audit | Covers engineering and security across five workstreams and produces a fix order |
| The product holds payment, health or other high-impact personal data, or is a likely target | AI code audit, then a penetration test | The threat model calls for proof that the running product resists an attacker, once the audit fixes are in |
| A customer or auditor asks for test evidence from the running system | Penetration test, after or alongside the audit | The evidence has to come from attacking the live system, not from reading code |
| Mature codebase, engineering quality under control, security depth needed in specific modules | Secure code review | A line-by-line security review of the modules that carry the risk |
Automated scans stay in the delivery pipeline in every case. GDPR Article 32(1)(d) expects a process for regularly testing, assessing and evaluating security measures, and a one-off audit or test does not replace that process. Choose a secure code review when the codebase is mature and the open question is security depth in specific modules.
How to choose an independent AI code audit provider
An independent AI code audit provider is one whose reviewers did not build the product and do not depend on the fixing work for their result. Seven criteria show whether a provider can deliver that:
- Reviewer qualifications: named reviewers with engineering and security experience on the stack your product uses.
- Independence from implementation: the reviewer did not build the product and is separate from the team or tool that generated the code.
- Engineering and security coverage: both disciplines review the same codebase, so the report has one fix order instead of two.
- Evidence quality: a sample finding shows location, reproduction or test result, severity and business impact.
- Remediation separation: the audit is contracted separately from any fixing work, so findings are not inflated to sell fixes.
- Confidentiality: read-only access, named reviewers, an NDA and a defined end to code access.
- Re-test terms: whether re-testing is included, how many rounds and within what period.
Segregation of duties is a named control in ISO/IEC 27001:2022, Annex A 5.3, and the same principle applies to an audit: the party that builds or fixes the code should not be the only party that checks it. The full list of questions to ask is in choose an AI code audit provider.
AI audit tools and scanners belong in the pipeline and can feed the review, but they do not judge business rules, role design or the fix order for a specific launch. The full argument is in the founder’s guide under who should review AI-generated code, and in ai code review.
After the audit: who fixes what
After an AI code audit, every finding gets an owner, a fix route and a closing condition before work starts. The owner is a named person on your side, even when a partner or an AI coding tool makes the change. The fix route is your own team, your AI coding tool working from the technical handoff, or a partner under a separate contract.
A finding closes only when there is evidence that the fix works: the original reproduction steps or test scenario run again and return the expected result, and the change is linked to the finding. Findings that cannot be fixed before the decision date are accepted in writing by the decision owner as known risks, with a target date.
Fix-now findings that expose personal data come first, and three situations need to be kept apart. A security vulnerability means personal data could be reached; on its own it creates no GDPR notification duty. A confirmed personal data breach means the logs or other evidence show that personal data was actually accessed, changed or lost. A reportable breach is a confirmed breach that is likely to result in a risk to the people affected: GDPR Article 33 then requires notifying the Autoriteit Persoonsgegevens within 72 hours of becoming aware of it, as the EDPB Guidelines 9/2022 on personal data breach notification explain. When the findings point to structural problems, the keep, refactor or rebuild decision is covered in the founder’s guide under fix, refactor or rebuild, and in refactor or rewrite.
How Sunbytes reviews AI-built products
Most risks in AI-built products emerge where code, user permissions, data and critical workflows connect. That is why Sunbytes approaches its AI-built product review as an independent assessment of product readiness, rather than a reason to redesign the product.
Our engineering, QA and security specialists combine manual review with automated tools to validate findings and provide evidence-backed recommendations. The review typically takes five business days from complete access, with scope and data handling agreed upfront. You receive a plain-English report showing what needs fixing before wider use and what can wait.
When deeper security testing is needed, our Cybersecurity Solutions team can conduct a separate penetration test or secure code review. If remediation requires additional engineering capacity, a dedicated software development team can support the fixes under a separate agreement. You remain free to work with your own team or another provider.
Sunbytes brings 15+ years of experience, 300+ delivered projects across 20 countries and ISO/IEC 27001:2022 certification to its technical reviews.
Explore our AI-built product review or discuss your AI-built product with our team before your next launch, enterprise deal or engineering handover.
