AI Generated Code Audit and Cleanup

n8n, Make.com and Zapier automation with AI steps and a human approval check — fixed price, documented on handover.

What Does an AI Code Audit Cover?

An AI generated code audit, often called a vibe code audit, is a careful read of an app that an AI coding tool built. Eicra Soft Limited goes through the code, writes down every security, structure and reliability problem with the file it sits in, proves each one is real, and hands your developers a list in the order they should fix it.

We read your code. We do not rebuild your app.

Nothing is changed while we read. Your app keeps running.

Every problem we report, we can make happen again.

You get the list. Your own developer makes the fixes.

We say which parts of the code we did not read.

Request a code audit Send one repository

30 minutes 01 Scoping call · audit plan, free

3 days 02 Starter audit · one repository, $249

5 days 03 Standard audit · full stack review, $599

2 days 04 Repeat audit · new commit, $199

Monthly 05 Code quality gate · AI pull requests, $400 a month

Which Code Audit Services Do We Run?

Eicra Soft Limited runs six code audit services: codebase structure, security and secrets, dependencies, test coverage, production readiness, and cleanup of what you approve. Each one answers a different question about your app. You can buy one on its own, or combine them into a single pass. The first five only look and report. Only the sixth changes your code, and only after you have read the findings and said which ones to act on.

Codebase Structure Audit

You learn where the app will fight you when you try to change it. We follow how a request travels from the screen to the database, then name the repeated logic, the dead files, and the parts an AI tool invented once and never used again. Each one comes with the file it sits in.

Security and Secrets Review

You learn what a stranger could reach. We look for passwords and keys left in the code, pages that hand over data without checking who is asking, database tables open to anyone, and user input that reaches a query unchecked. Findings are grouped by how easy they are to exploit.

Dependency and Supply Chain Check

You learn what your app borrows from other people. We read the lock file and name packages that are unpinned, abandoned, or installed twice at different versions. Where a package has a known security warning, we name it next to the file that imports it.

Test Coverage Assessment

You learn what is untested and what that could cost you. We record which parts of the app no test ever runs, which tests check nothing useful, and which untested parts touch money, personal data or login. You get a ranked list of the tests worth writing first.

Production Readiness Review

You learn what happens when the app breaks at two in the morning. We check the error handling, the logs, how settings and passwords are kept apart between environments, and whether you can undo a bad release. Each gap comes with the change that closes it.

Remediation and Cleanup

You get the approved problems fixed. Each change is tied to a numbered finding from the report, kept in its own commit, and checked against the script that showed the problem. We do not refactor things because we would have written them differently.

Not included: rebuilding the product or changing what it does · redesigning the architecture inside an audit · certification or conformity assessment, because Eicra Soft Limited is not a certification body · third-party scanning licences, paid by you to the vendor.

How Does AI Generated Code Fail?

AI coding tools write code that runs, and that is exactly why the gaps survive to production: the application works, so nobody looks. The failures below are the ones that reach a launch or a security review, and each maps to a check in the audit. The security categories follow the OWASP Top 10, so a finding can be matched against the list your reviewer already uses, and research from DORA found in its 2024 report that more AI adoption went with lower delivery stability and slightly lower delivery throughput, not faster releases.

Credentials and API keys committed into the repository
Routes that return data with no authorisation check
Database rules left open to anonymous callers
Paths that work only because one record happens to exist

Failure Types Mapped to Audit Checks

Each failure below needs its own check. A clean scan of the code will not show a key buried in an old commit, and a passing test suite says nothing about a path no test runs. The table pairs each failure with the check that finds it, so the audit covers all five.

Failure type	What it looks like	Audit check
Exposed secrets, CWE-798	A live Supabase service key or payment secret sitting in the repository history	History sweep across every branch and commit
Broken access control, CWE-862	A Next.js route handler or API endpoint that trusts whatever the client sends	Entry point read against the data it can reach
Open data rules, CWE-732	A Supabase table with row level security (RLS) left off, readable by any anonymous caller	Policy read against the queries that use it
Untested critical path	Payment or login code no test ever exercises	Path list ranked by what the failure would cost
Silent failure, CWE-390	An error swallowed inside a serverless function on Vercel, so nothing is logged	Error handling read from throw site to log sink

The Audit Runs in Five Stages

An audit runs in five stages, and at the end of each one you decide whether to carry on. We read no code before the paperwork is signed. Nothing goes into the report until we have made the problem happen again. Whatever we produce along the way is yours to keep, even if you stop after the first stage.

Start at 01 if the application is live. Start at 02 if it is still in build.

Each Stage Ends With Your Decision

Every stage ends with a decision that is yours to make. We read no code until the paperwork is signed, and you approve the scope before the engineer starts reading. You can stop after any stage and keep everything produced up to that point.

Stage	What happens	What you decide
01 Scope	You name the repository and commit. We write the plan.	Give access, or stop here
02 Access	You issue read-only keys. We sign the paperwork first.	Start the sweep, or stop
03 Sweep	Automated checks narrow the code down to what matters.	Approve the read, or change scope
04 Read	An engineer reads that code and proves each problem is real.	Take the report, or extend it
05 Handover	You get the report, the scripts and the fix order.	Fix it yourself, or ask us

Repeat Audits After Every AI Sprint

An audit describes one commit. The next sprint of AI generated pull requests can undo it, which is why the reproduction scripts are yours to re-run rather than ours to rent back to you. For the build side of the same work, see our AI services; for checking what an AI system outputs rather than how it was written, see AI model testing.

Repositories Web apps, APIs, mobile, scripts

Access Read-only, in your environment

Contracts NDA and DPA before any access

Handover Report, scripts, fix order

Where Do We Look First in Your Code?

At the five places where AI generated code fails most often. Secrets left in the repository. Routes that skip the auth check. Database rules open to anyone. Paths no test touches. And what breaks on the next deploy. Each tab names the specific checks inside that area, so you can read the checklist before you hire anyone to run it.

Area one

Secrets Committed to the Repository

The first thing a stranger with your code would look for. We check every branch and the whole history, not only the files you see today. A key you deleted last month is still sitting in the history, and anyone with access can read it. Each one is listed with the commit that added it.

Every branch, not only main

Full commit history swept

.env files tracked in git

Keys bundled into client code

Tokens left in CI configuration

Revocation confirmed, not assumed

Area two

Routes That Skip the Auth Check

Whether your app decides who you are, or just believes what the browser tells it. We list every page and API the app exposes, then read each one against the data it can hand back. Hiding a button is not a check. The page that still works when you paste its address is the one we report.

Every route listed, then read

Checks on the server, not the screen

Ownership tested on each record fetch

Admin paths reached by direct URL

Token expiry and refresh behaviour

Rate limits on login and reset

Area three

Database Rules Open to Anyone

Whether your database would hand a whole table to a stranger. AI tools often leave row level security switched off, or write one rule and copy it everywhere. We read each rule against the queries that use it, and we ask the database directly as an anonymous user instead of trusting the dashboard.

Row level security read policy by policy

Anonymous role queried directly

Service keys used from the browser

Storage buckets left public

Foreign keys and cascade behaviour

Migrations applied in a known order

Area four

Paths No Test Ever Touches

Which untested code would actually cost you money. A coverage number hides this: an app can look well tested while payment, login and permission code has no test at all. We rank the untested parts by what a failure there would cost, and name the few tests worth writing first.

Paths that move money

Tests that assert nothing useful

Fixtures that mask real failures

Error branches never entered

A short list of tests to write first

Area five

What Breaks on the Next Deploy

Whether a bad release can be undone. We check that your live and test setups are really separate, that passwords sit outside the code, that errors reach somewhere a person reads, and that the undo button has actually been used. A release nobody can reverse is a risk a working app hides.

Environments genuinely separated

Secrets held outside the repository

Rollback path tried, not assumed

Logs reaching a sink someone reads

Errors surfaced instead of swallowed

Failed deploy leaves a known state

Where we are not the answer: if you need a signed certificate rather than evidence, a certification body or a large assurance firm is the honest route and we will say so on the first call. If the decision is really whether to rebuild from scratch, an audit will tell you that but will not do the rebuild. Eicra Soft Limited is a small team working remotely from Bangladesh, we hold no certification we have not been awarded, and we have no client case studies to publish yet. What we can show you is the method and a scoped audit plan for your own repository.

Proof You See Before You Pay

We publish method rather than promises: a written audit plan from the first conversation, findings drawn from your own repository, and every issue traceable to a reproduction script anyone on your team can run. Nothing in a report rests on our word alone, because a finding you cannot reproduce is a finding you cannot act on. Client case studies will be added here as engagements complete, with each client permission.

5 areas Secrets, access control, database rules, test gaps and deploy safety, every one of them agreed in writing before a single file is read. Covered in every audit

30 minutes One call turns your repository and what the application does into a written audit plan, and the plan is yours whether or not you continue. Scoping call costs nothing

3 files Findings report, reproduction scripts and the fix order, handed over at close so your own developers can re-run the checks. Included in every engagement

Free 30-minute scoping call Send one repository and tell us what the application does. You get a written note on what an audit of it would cover and what it would not tell you, whether or not you hire us.

Send one repository

Is It Safe to Share Your Repository?

Your code stays where it already is. We work with read-only keys that you issue and can cancel, inside the setup you choose, and we keep no copy after handover. The risky part of a code audit is not the app, it is the history: old commits, settings files and logs often hold live passwords and real customer records. That is where the controls sit, and it is why the data terms under Article 28(3) of Regulation (EU) 2016/679 are signed before anyone reads a line.

Contracts and access

What do we sign before access?

Every agreement below is signed before the repository, its history or its logs are opened. That means a mutual NDA, a data processing agreement wherever personal data appears in the code, and the transfer terms your regulator requires. Certifications are listed only when they are held.

NDA mutual, signed before the repository, its history or its logs are opened.

DPA processor terms wherever personal data appears in the code, fixtures or logs.

Transfers the transfer agreement your own regulator requires, signed before personal data moves.

Certifications we hold none we have not been awarded, which is why the controls above are contractual rather than badge based.

Handling during an audit

Where does your source code sit?

Your source code stays under your control for the whole audit. Reviewers work in the environment you nominate, with credentials you issue and can revoke. Sample records can be masked where real data must not be read, and any local copy is deleted when the agreed period ends.

Location Reviewers work in the environment you nominate, using credentials you control and can revoke.

Minimisation Fixtures and sample records can be masked or synthesised where real data must not be read.

Retention Any local checkout, scan output and note is kept for the period in the engagement letter, then deleted on confirmation.

Access Read-only rights, named reviewers only, and our credentials revoked by you at handover.

Does Your Codebase Need an Audit?

Most founders do not go looking for a code audit. They hit one of these six situations and then start looking. Find the row that sounds like your week. The last column names the service that answers it, so you can start there instead of buying a full review you do not need yet.

Signs and the Right Starting Point

Each row is a situation founders describe when they first get in touch, and the last column names the single service that answers it. Start from one row rather than the whole list, because one focused audit teaches you more than a review that tries to cover everything.

No.	The sign	Where to start
01	The app works but nobody dares change it	Codebase structure audit
02	An investor or enterprise buyer asked for a review	Security and secrets review
03	A developer quit after one week in the codebase	Codebase structure audit
04	Every new feature breaks something unrelated	Test coverage assessment
05	You are about to open the app to real users	Production readiness review
06	Your AI tool added packages nobody has reviewed	Dependency and supply chain check

None of these yet? Then you probably do not need us this quarter. The cheapest useful step is to run your own repository through a secrets scanner and read what it finds, because that is the one class of problem where a single miss is enough to matter.

Code Audit Questions Buyers Ask

Ten questions founders and engineering leads ask before they hand over a repository, answered without hedging. They cover what an audit is and finds, how it runs, what you provide, which AI tools it covers, code ownership, your data, who fixes what, what you receive and what we will not do. Where the honest answer is no, it says no.

What is an AI generated code audit?

An AI generated code audit is an independent read of a codebase written wholly or partly by an AI coding tool. An engineer reads the repository at a commit you name, records each structural, security and reliability issue with the file and line it lives in, reproduces it, and returns the findings in fix order. It is a review, not a rewrite.

Is AI generated code safe for production?

It depends on what nobody has checked yet. AI coding tools produce code that runs, and the common gaps are the ones no test exercises: secrets committed to the repository, routes with no authorisation check, database rules left open, and dependencies nobody pinned. Independent testing by Veracode, published in its 2025 GenAI Code Security Report, found OWASP Top 10 vulnerabilities in code generated by current large language models, which is why these checks run directly against your repository rather than being assumed away. An audit finds which of those are present in your repository rather than in the general case.

How do you audit an unknown codebase?

We start from the entry points rather than the file tree: how a request enters, how it reaches data, and what stands between the two. Automated sweeps run first to narrow the surface, then an engineer reads the code the sweep flagged, in context. Nothing enters the report until it has been reproduced from a clean checkout.

What do you need from us?

Four things, in this order:

1. Read-only access to the repository, at a branch and commit you name.
2. A short note on what the application does and who uses it.
3. Any environment the app needs to run, or permission to run it locally.
4. The name of one person on your side who can answer questions about intent.

Can you audit a Lovable build?

Yes, and also builds from Cursor, Replit, Bolt, v0, Claude Code and GitHub Copilot. The audit is tool agnostic because it reads the code that was produced rather than the prompts that produced it. What changes between tools is where the common gaps sit, and the report names which tool patterns it found.

Who owns code that an AI wrote?

Ownership sits with you under the terms of the tool you used, and the audit does not change that. What an audit can surface is code in your repository that appears to originate from a third party licence, so your own counsel can decide what to do about it. We report what we find and do not give a legal opinion.

Do you keep our repository?

No copy is retained after handover. Work happens in the environment you nominate wherever possible, with read-only credentials for named reviewers. Where a local checkout is needed, it is deleted on your confirmation at close, and the engagement letter names the retention period in writing before any access is granted.

Can you work alongside our developers?

Yes, and that is the usual shape. Your developers keep ownership of the codebase and make the changes. We hand findings over with reproduction steps so a fix can be verified rather than assumed. Where you would rather we implement the fixes, remediation is scoped and agreed separately after you have read the findings.

What is inside the audit report?

Three files. The findings report names each issue, the file and line it sits in, why it matters and where it sits in fix order. The reproduction scripts make each finding repeat from a clean checkout. The scope note names the commit, the branch and, in its own section, what the audit did not cover.

What will you not fix?

We do not rewrite your product, change what it does, or redesign the architecture inside an audit. We do not certify anything, because Eicra Soft Limited is not a certification body. We also offer remediation, which means we could in principle benefit from reporting more findings than exist, so every finding is reproduced from a clean checkout before it enters the report, findings are ranked by what the failure would cost rather than by what the fix would earn, and you are free to hand the list to your own developers and never speak to us again. And we do not promise behaviour on paths nobody exercised, which is why every report names the parts of the repository it did not read.

Is a code audit the same as a penetration test?

No. A penetration test attacks the running application from outside to see what an attacker can reach. A code audit reads the source itself, including the paths an attacker would never find from outside: a secret sitting in an old commit, a database policy nobody reviewed, a branch no test touches. Automated scanners such as Semgrep, Snyk or gitleaks narrow the surface in either case, but a scanner reports patterns while an audit reports findings that have been reproduced, mapped to the CWE weakness behind them, and ranked. Teams that need assurance for a buyer usually end up needing both, in that order.

How long does an audit take?

Long enough to reproduce every finding, and no longer. The time depends on how many entry points the application has, how much commit history has to be swept, and how quickly read access is granted. You get a working range after the scoping call, once we have seen the repository and the stack, rather than a number quoted before anyone has read anything.

Can you take over from another provider?

Yes. Send whatever the previous provider handed you and we will tell you what it covered, what it did not, and what still needs reading. Work already done properly is not rerun. Where an earlier finding cannot be reproduced from a clean checkout, we say so rather than carrying it forward unchecked.

Do we need an audit before launching?

Launch is the point where the cost of a missed finding changes. Before launch, an open database rule or a committed key is an internal problem. After launch, it is an incident involving real users and real data. Most teams audit at a gate: before a public launch, before a funding round, or before an enterprise buyer runs their own security questionnaire.