A security audit shouldn't turn into a second development project for the person who built the application. For a typical AI-built product, we can start with the codebase and a small amount of context.
Our process is designed around that constraint.
Before the audit: what we need from you
The engagement starts with access to your git repository. That's the primary input. We clone the repo, and everything we do works from that codebase.
We'll also ask you three questions: what does the app do, who uses it, and what data does it handle? The answers take five minutes and help us prioritize. An internal dashboard that displays marketing metrics has a different risk profile than a patient portal that handles medical records. We calibrate the audit accordingly.
That's the total time commitment on your end before the report lands. There's no lengthy onboarding, no requirement to walk us through the codebase, no week of back-and-forth meetings. The code tells us what we need to know.
Phase 1: Automated analysis
The first phase is automated. We ingest your repository into our analysis pipeline, which examines the codebase across eight categories: authentication and session management, authorization and access control, input validation and injection, data exposure and privacy, infrastructure and configuration, error handling and logging, API security, and dependency health.
The automated layer identifies structural patterns: it flags files that contain hardcoded credentials, endpoints that accept unvalidated input, authentication flows without rate limiting, database queries built with string concatenation, and a few dozen other known vulnerability patterns.
This phase produces a complete map of potential issues, ranked by severity. It's thorough but not subtle: it finds everything that matches a pattern, whether or not it's actually exploitable in context. That's where the next phase comes in.
Phase 2: Expert review
The automated findings go to a human reviewer who does three things.
First, they validate each finding. The automated layer flags a hardcoded string that looks like an API key; the reviewer confirms whether it's a live credential, a test value, or a false positive. An endpoint accepts raw user input; the reviewer traces the data flow to determine whether it actually reaches a dangerous operation or gets sanitized downstream. Not every flag is a real finding, and the report should only contain issues that matter.
Second, they identify what the automation missed. Automated analysis excels at pattern matching. It's less effective at understanding business logic, the kind of vulnerability where the code is syntactically fine but the application flow allows something it shouldn't. A user upgrading their own role. A payment amount modifiable on the client side. An admin endpoint that's hidden from the UI but still accessible via direct request. These require a human reading the code with the application's purpose in mind.
Third, they prioritize. A finding that's technically a vulnerability but requires an authenticated admin user to exploit in an application with one admin is different from a finding that's exploitable by any anonymous visitor. Context determines severity, and severity determines what you fix first.
What the report looks like
The output is a structured findings report. Each finding includes five elements:
Title and severity. A clear description and a rating: Critical, High, Medium, or Low. Critical means the issue is actively exploitable and could result in data loss, unauthorized access, or system compromise. Low means it's a deviation from best practice that should be addressed but doesn't represent an immediate threat.
What we found. A plain-language explanation of the issue, specific enough that anyone on your team can understand it. We reference exact files and line numbers so there's no ambiguity about where the problem is.
Why it matters. The practical impact: what could happen if this issue is exploited. Not theoretical risk frameworks, but concrete outcomes. "An unauthenticated user can access any other user's records by modifying the ID in the URL" is more useful than "the application has an authorization vulnerability."
How to fix it. Specific remediation guidance. Not "implement proper authentication" but "replace the current JWT implementation with a session-based auth flow using HTTP-only cookies, add token expiration, and implement a token refresh mechanism." The guidance should be actionable enough that a developer (or another AI coding tool) can implement the fix directly.
Code reference. The exact file, function, and line number where the issue exists. No searching required.
A typical audit report for an AI-built application contains 12 to 18 findings: two to four Critical, four to six High, four to six Medium, and one to three Low. Applications built with more capable tools like Cursor tend to have fewer critical findings than those built with browser-based tools like Bolt or Lovable, but the overall pattern (missing hardening, not broken logic) is consistent.
What happens after the report
You get the report and a walkthrough call. We go through every finding, answer questions, and discuss priorities. If your app has four critical findings and six high ones, we'll tell you which three to fix first and why.
From there, you have two options. You can take the report and fix the issues yourself, or have your development team handle it. The remediation guidance is specific enough to work as a task list. Many developers use the findings as prompts, feeding them back into Cursor or Claude to generate the fixes.
Or you can engage us for a hardening sprint, where we implement the remediations directly. A hardening sprint typically takes one to two weeks depending on the number and complexity of findings. The audit fee gets credited toward the sprint, so you're not paying twice for the same problem.
What an audit doesn't cover
We audit the codebase, not the infrastructure it runs on. We don't assess your hosting configuration, DNS setup, CDN configuration, or cloud provider settings; those are separate disciplines. We also don't perform penetration testing (active exploitation of vulnerabilities). What we do is a thorough code-level security review with expert validation.
We also don't audit ongoing changes. The report reflects the state of the code at the time of the audit. If you push significant new features after the audit, those features haven't been reviewed. For applications under active development, we recommend periodic re-audits, but that's a conversation, not an automatic upsell.
How long it takes and what it costs
A standard audit takes three to five business days from the time we receive repository access. The timeline depends on codebase size and complexity, but most AI-built applications are compact enough to fall within that window.
Pricing is flat-rate: $1,500 to $3,000 depending on scope. You know the cost before we start. There are no hourly charges, no surprise add-ons, and no ambiguity about what's included.
When an audit makes sense
Whether an audit is worth doing depends on the stakes. If the application stores sensitive information, serves paying customers, or operates in a regulated environment, the cost of a serious security failure can exceed the cost of a review by orders of magnitude.
A side project with no users and no sensitive data may not need a formal audit yet. The threshold changes when other people begin relying on the software or when the consequences of a mistake become material.
The purpose of the audit is practical: give the builder a concrete, prioritized list of what must change before the application is treated as production-ready.