The password check that isn’t
try { return jwt.decode(token); }
// decode ≠ verify. any token passes.
Looks like authentication, compiles like authentication, authenticates nothing.
← mudhawi labs
AI wrote the
software.
AI wrote the
software.
Who checked it?
AI made it possible to build software without knowing how to build software. It did not make it possible to judge that software without knowing how to judge it. The audit is the verification: an independent review of your AI-built product, scoped and priced in full before it begins.
read on01 / the problem
You own something you cannot inspect.
You had an idea. You described it, and AI tools turned it into working software. Or you paid someone who used those tools, faster and cheaper than any agency quote you got before 2024. Either way, the product exists, it runs, and customers may already be using it.
Here is the uncomfortable part. “It runs” and “it is sound” are different claims. Software can look finished on the screen and still leak customer data, silently lose records, fall over the first week real traffic arrives, or carry a security hole that a bored teenager finds before you do. If you cannot read the code, you cannot tell which of these you own. The demo cannot tell you. The AI that wrote it cannot referee itself. And the person who built it, however honest, is grading their own homework.
This is not an argument against building with AI. Building with AI is the sane default now. It is an argument for doing what serious owners have always done with assets they cannot personally inspect: bring in an independent inspector before the stakes get high.
If your product also uses AI agents, meaning software that takes actions on its own, such as sending messages, moving data, or spending money, the question gets sharper.
What exactly is it permitted to do, and what stops it from doing more?
The classic patterns we look for.
scroll to page through the evidence →The query that trusts strangers
db.query(`INSERT INTO docs
VALUES ('${file.name}')`);
The oldest vulnerability on the web, regenerated fresh by a model that has read every warning about it.
Tests that test nothing
expect(response).toBeDefined(); // 94% coverage. 0% assurance.
The suite exists to be green, not to catch anything.
The payment nobody validates
await charge(customer, req.body.amount); // TODO: validate amount server-side
The model knew. It wrote the TODO itself, then shipped the charge anyway.
The claim with no source
"تم التحقق من المعاملة بنجاح."
// verified against: nothing.
An Arabic-language product asserting verification it never performed. Some findings need an auditor who reads both of the product’s languages.
Your codebase here
status: unread auditor of record: assigned on request
Every system has its own patterns. The audit finds yours before someone else does.
02 / the audit
One engagement. Scoped, quoted, and fixed before it starts.
The verification audit
You give us access to the code, whatever documentation exists, and 90 minutes on a call to explain what the product is supposed to do and what worries you. We read the system the way a buyer’s engineer would: line by line where it matters, end to end where it counts.
A findings report
Ordered by severity. Every finding says what the issue is, why it matters to your business, and what fixing it involves. Plain language first, technical detail second.
A one-page executive brief
The whole picture on a single page: fit for a board seat, an investor, or your own desk drawer.
A 60-minute readout call
We walk you through the findings, you ask anything. You leave knowing exactly where you stand and what to do first.
Five working days from the day access is granted.Fee
Quoted per engagement, after the scoping call and before anything is committed. The quote is a single fixed figure for the whole engagement, agreed in writing before we receive access. It does not move afterwards, there is no hourly billing, and there are no change orders. If the system turns out to be larger than it looked, that is our estimating error, not your invoice.
Re-audit after fixes
Available only to past audit clients, verifying remediation of previously reported findings. Quoted against the original engagement, and substantially less than it. That is the only follow-on we offer.
Agentic systems
For products with agentic components, the engagement letter states explicitly whether prompts, tool permissions, safety gates, and logging are inside the audit’s scope, so there is no ambiguity about what was and was not examined.
What it is, precisely
A point-in-time review. It tells you the state of the system as it stood when we examined it. It is not a warranty, not a guarantee against future defects, and not a promise that nothing was missed. No honest reviewer sells those. What it is: an independent, expert, signed judgment you currently do not have.
What it is not
A development shop. The lab does not fix what it finds, rebuild your product, or take a retainer. Inspection and repair stay separate, so no engagement creates an interest in what the next one finds.
How your code is handled
Each engagement runs in an isolated environment created for that client alone and wiped afterward, with the deletion documented. Access is read-only and revoked at delivery. If any AI tooling is used in support of an audit, the engagement letter discloses exactly what and how, and you opt in before it happens. Clients who prefer a fully manual review can have one, at an adjusted price.
The verification itself, the reading and the judgment, is never delegated to AI. Every engagement has one auditor of record, who performs the review end to end and signs every finding in the report.
03 / how it works
From enquiry to answer in about two weeks.
Intake
You complete the form below. Ten minutes, no technical knowledge required. You receive an acknowledgment immediately.
Discovery call
If the fit looks right, we book a short call: what you built, what you are worried about, whether an audit is actually the right instrument. If it is not, we will say so and point you elsewhere.
Engagement letter, then access
Scope, price, confidentiality, and handling terms signed before we see a line of code.
Five working days
We audit. You wait, briefly.
Readout
Report, executive brief, and 60 minutes of straight answers.
04 / terms of engagement
Rules that make the finding worth having.
One auditor of record.
One named person performs the review end to end and signs the report. Their name is in the engagement letter before you grant access.
No fixes, no rebuilds, no retainers.
The lab does not fix what it finds, rebuild your product, or hold a retainer. The only follow-on offered is a re-audit that checks whether reported findings were resolved.
The judgment is never delegated to AI.
Tooling may support the work. The reading and the conclusions are performed by the auditor of record. Where tooling is used, the engagement letter states what and how, and you opt in before it runs.
Every report is signed.
Every finding carries the name of the person who reached it. You can put a question to that person and get an answer.
05 / sample report
Read a report before you buy one.
The best way to judge an audit is to read one. This sample is drawn from the lab’s public teardown of an open-source, AI-built application: same structure, same severity ordering, same plain-language standard as a client report. Findings with security implications were disclosed privately to the maintainers first and are redacted here until fixed.
Why the lab publishes a sample at all. An audit is a judgment you cannot inspect before you buy it, which is the same problem the audit exists to solve. Publishing one is the only honest answer: read the reasoning, check the receipts, and decide whether this is the standard you want applied to your own system.
The research behind this practice is on the lab’s research page.
06 / intake
Request an audit.
Ten minutes, plain English, no technical vocabulary required. Where you do not know an answer, say so; “I don’t know” is useful information, and guessing is not.