AStarted by AXIS Editorial
"Get an audit" is advice makers hear constantly — from us included — usually with no explanation of what the deliverable contains. Here is what a competent audit of a small AI application actually covers in 2026, so you can scope one, price one, and read one.
The conventional layer (still most of the findings)
AI apps are web apps; the classic failure modes didn't go anywhere and AI-generated codebases reproduce them at scale:
- Authentication and authorization — session handling, role checks on every route (not just the UI), object-level access control (can user A fetch user B's data by changing an ID — the single most common finding in AI-generated backends).
- Input handling — injection of all flavors, file-upload trust, unvalidated redirects.
- Secrets and configuration — keys in code or client bundles, over-permissioned service accounts, missing rotation paths.
- Dependency posture — known-vulnerable packages, abandoned transitive dependencies, and in AI-built projects specifically: hallucinated or typo-squatted packages that were installed because a model suggested them.
- Data protection — encryption in transit and at rest, backup existence and restorability, deletion actually deleting.
The AI-specific layer
- Prompt injection surface — anywhere untrusted content (user input, uploaded documents, fetched web pages, inbound email) reaches a model that has tools or secrets in scope. The audit maps every such path and what an attacker reaches through it.
- System prompt and key extraction — can users exfiltrate your prompt, and does anything sensitive live in it (it should contain zero secrets — a surprisingly common finding).
- Model-output trust — is model output ever executed, rendered unescaped, or used to make authorization decisions? Each instance is a finding.
- Data flows to providers — what user data reaches which model APIs, under what retention terms, and whether your privacy policy matches reality.
- Cost-abuse surface — can an anonymous user make you spend unbounded API money (missing rate limits on generation endpoints is near-universal in first audits).
What the deliverable looks like
A findings report with severity ratings (typically critical / high / medium / low / informational), reproduction steps, and remediation guidance; a scope statement saying what was and wasn't examined; and ideally a re-test pass after you fix the criticals. For a solo-maker app, expect the useful range to be a focused 2-5 day engagement, not a six-week enterprise assessment.
What an audit is not
Not a guarantee, not a badge, not permanent — it's a dated snapshot of a moving system, which is why serious buyers look at audit date plus what changed since.
Auditors: what does your version of this scope add or drop for small AI apps? Makers: which of these layers have you actually had examined? To answer, start a thread on GitHub Discussions (the link is at the foot of this page).
Follow-up question: "What are the audit findings most specific to AI-generated codebases, versus AI apps generally?"
Patterns auditors report clustering in generated code: (1) authorization checked in the UI but absent on the API route — models scaffold both sides and secure one; (2) copy-paste divergence — near-identical handlers where a fix was applied to three of five; (3) dead code that still runs — abandoned endpoints from earlier iterations, unauthenticated and forgotten; (4) hallucinated dependencies, occasionally typo-squatted on the registry; (5) error handling that leaks internals because verbose debugging output was never turned off. None are exotic — they're the errors of a very fast junior with no memory, which is what unsupervised generation is.
Follow-up question: "Is a pentest the same thing? A provider quoted me a 'penetration test' at triple the price of a 'code review.'"
Different instruments, honestly different prices. Code review reads the source for flaws (white-box, broad coverage, finds what's in the code). A pentest attacks the running system like an outsider (black-box or grey-box, narrower but proves exploitability). For a solo AI app, the highest value per dollar is usually a source-assisted review — the auditor reads code and pokes the live app — sometimes sold as 'grey-box assessment.' Pure black-box pentests price higher partly for effort spent rediscovering what your repo would have shown for free. Ask any quoter which of these they mean; a provider who can't say clearly is answering a different question than yours.
Why the platform cares, stated plainly: audits are diligence assets. In any acquisition of a small app, technical diligence happens — the only question is whether it happens on your schedule (an audit you commissioned, criticals fixed, re-test attached) or the buyer's (findings surfacing mid-negotiation, each one a repricing event). The same report costs less and is worth more when it predates the deal. This is the entire logic of exit-readiness, applied to code.
Follow-up question: "How do I prepare so an audit doesn't waste billed hours on my mess?"
Auditor-cited time sinks, all fixable free before day one: (1) a README that actually builds the project — auditors bill setup time; (2) an architecture sketch, even one paragraph — what talks to what, where data lives; (3) an inventory of your external surface: routes, webhooks, cron jobs, third-party integrations; (4) your dependency manifest current and lockfile committed; (5) test credentials for a staging environment so nobody audits production. Providing these can compress a 5-day engagement toward 3 — the discount is real and you control it.