Authentication & access control
Session handling, JWT signature verification, route-level guards, ownership filters and cross-tenant isolation. This is a high-impact surface we test explicitly.
Service · AI code audit
Audit the code your AI shipped.
Cursor, v0, Lovable, Copilot or any other AI got you to a working product faster than felt possible. Now real users, production load or due diligence demand certainty about what's actually in the codebase. We read it the way a senior engineer would read it for an acquisition, name what's broken or risky, and tell you what to fix first.
What it is
An audit by humans
of code an AI wrote.
Your AI built it. We make sure it won't break, leak, or get exploited.
AI coding tools ship surface-level features fast. They can also introduce subtle ownership-filter bugs, public Supabase tables, leaked service keys, hallucinated dependencies and unprotected API routes, confidently, in code that passes a casual review. These are plausible failure modes worth verifying before they surface under load, under external audit, or in an incident postmortem.
We read your codebase the way an engineer reading it for acquisition due diligence would: line by line, with the failure modes of your specific AI tool in mind. You get a severity-ordered written report, a live walkthrough, and 30 days of follow-up while you fix things.
What we audit
Eight surfaces we read carefully.
Secrets & configuration
Credentials in the repo or git history, server keys leaking into the client bundle, environment-variable hygiene and the boundary between public and private config.
Data integrity & privacy
Database access rules (Supabase RLS, Firebase rules), PII in logs, GDPR exposure, prompt-to-database flows and what happens when the AI is asked to write a query.
Dependencies & supply chain
Lockfile hygiene, hallucinated or typosquatted packages, vulnerable transitive dependencies, package source and the npm install your AI ran without asking.
LLM-specific risk
Prompt injection paths, system prompt exfiltration, missing rate limits on expensive model calls, content moderation gaps and the trust boundary around model output.
Infrastructure & runtime
CORS configuration, error-handling surface, logging, rate limiting, deployment topology and what's exposed to the public internet that probably shouldn't be.
Performance & cost
N+1 queries, runaway loops, runaway model spend, caching gaps and the operations that turn a $20 user into a $2,000 user overnight.
Operability
Observability, alerting, on-call surface, recovery paths and whether anyone will know when something breaks at 3am.
Audit by sector
Risks and controls in your operating context.
Professional services
Less time on documents, proposals, research, reporting and client management.
See approach →Real estate & property
Lead automation, viewings, documentation, incidents and multilingual communication.
See approach →Hotels & hospitality
24/7 support, multilingual replies, request handling, upselling and review analysis.
See approach →Distribution & B2B industry
Quoting, sales support, forecasting, technical documentation and operational follow-up.
See approach →Illustrative catalogue
Sample findings from a synthetic audit.
Composite examples showing the type of risk and level of detail in the report; they do not describe client projects or results.
Every name, tool, path, account, response and effect in this catalogue is fictional or composite. It exists only to illustrate possible findings and must not be read as a real case, confirmed incident or client result.
Criticalv0
Public Supabase tables behind a private-looking UI
In this fictional sample, the app gated every screen behind a login, but row-level security was disabled on three tables. The anon key, meant to be public, could read the full customer list from a browser.
CriticalLovable
Service-role key shipped to the browser
In this fictional sample, a Supabase service_role key was inlined into the JavaScript bundle so the storage upload would work. Any visitor with DevTools could write arbitrary rows to any table the project owned.
CriticalCursor
Cross-tenant leak via missing ownership check
In this fictional sample, the invoice detail endpoint accepted any id in the URL and returned the row. Two seeded accounts could read each other's invoices by changing a number.
MediumClaude Code
Hallucinated dependency in the lockfile
In this fictional sample, the AI-suggested package did not exist in the first commit and later appeared as a lookalike name with a postinstall payload.
HighChatGPT-built MVP
Prompt injection into an agent with database write access
In this fictional sample, support-form text flowed untreated into the agent context. An adversarial input caused the agent to call an over-permissioned deletion tool.
How it works
Five to ten business days.
Read access to your repository is enough to start. We don't need to deploy anything to your infrastructure, and we don't need credentials beyond what a normal code reviewer would.
01
Kickoff
30-minute intake call: which tool built it, which stack, what's in production, where the seams are. We confirm scope and sign anything you need signed.
02
Static & dynamic audit
Line-by-line read of every meaningful file. Automated tooling on top of the read, not instead of it. Runtime probing of public endpoints where applicable.
03
Live walkthrough
60-minute call covering the report, severity, fix order and the questions your team will have once they've read it.
04
30-day follow-up
Slack or email window for clarifications, fix reviews and a second look at anything you change. Re-audit at cost if the codebase shifts substantially.
Public methodology
What we check and how we check it.
We agree the scope and threat model before review. Manual evidence leads; automated tools support the review, but do not replace human judgement or justify a promise of absolute security.
Methodology reviewed:
Minimum review coverage
Auth
Identity and authorization
Sessions, token signatures, route guards, account recovery and authorization decisions derived on the server rather than from client-controlled data.
Secrets
Secrets and configuration
Environment variables, git history, client bundles, logs and the boundaries between public, private and privileged keys.
Tenancy
Cross-tenant isolation
Manipulable identifiers, ownership filters, RLS, storage and negative tests across two seeded tenants when the authorized environment permits it.
Supply chain
Supply-chain integrity
Lockfiles, package provenance and lifecycle, vulnerable versions, lookalike names, install scripts and consistency between source and deployment.
Inputs
Input validation
Boundary schemas, file uploads, SQL queries, commands, webhooks and outputs that reach HTML, logs or downstream systems.
LLM
LLM-specific risk
Prompt injection, tool permissions, context exposure, treatment of untrusted output, usage limits and model-cost controls.
Deployment
Runtime and operations
Headers, CORS, errors, logs, public exposure, runtime configuration, monitoring, backups and recovery paths visible within scope.
Review stages
- 01
Scope and threat model
We inventory repositories, environments, sensitive data, roles, trust boundaries, exclusions and authorized tests.
- 02
Manual and assisted static review
We trace data and privileges through code, configuration, migrations and lockfiles; scanners contribute signals that we then verify.
- 03
Dynamic and negative testing
In an authorized environment, we test controls with adversarial inputs, distinct roles and cross-tenant access without destructive activity outside scope.
- 04
Severity and reporting
Each finding includes reproducible evidence, contextual impact, priority, a proposed fix and concrete retest steps.
- 05
Walkthrough and retest
We review the report with the team and verify agreed fixes against the original case and a regression test.
Severity rubric
Severity combines impact and likelihood in the agreed context; we do not simply copy a scanner score. Timelines are prioritization targets, not universal guarantees.
| Level | Criteria | Target response |
|---|---|---|
| Critical | Direct compromise of data, accounts or privileged control that is reproducible with few barriers. | Contain immediately; fix before launch or continued exposure. |
| High | Material impact with a credible exploitation path or a missing essential control. | Prioritize in the current cycle and add a temporary mitigation if still exposed. |
| Medium | Limited impact or exploitability, or risk that depends on several conditions. | Plan the fix and regression test in the next reasonable cycle. |
| Low | Hardening, minimal exposure or a defence-in-depth improvement. | Track and resolve alongside related maintenance. |
Methodology references
We use these public standards to structure coverage, name weaknesses and communicate severity. The agreed scope and system evidence still determine each conclusion.
- OWASP ASVS 5.0.0Verifiable requirements for technical security controls in web applications.
- OWASP Top 10:2025The current awareness document covering the most critical web application risks.
- OWASP Top 10 for LLM Applications 2025Risks and mitigations specific to the LLM and GenAI application lifecycle.
- MITRE CWEA common taxonomy for describing the technical causes of software and hardware weaknesses.
- FIRST CVSS v4.0A framework for communicating technical characteristics and severity, contextualized with impact and likelihood.
Sample report
How we document a finding.
Fictional sample · not a client case
This report is a synthetic composite. Names, code, paths, accounts, responses and metrics are invented solely to demonstrate the deliverable format; they do not represent a real audit or client result.
Fictional project
LedgerFox · Next.js and Supabase B2B SaaS
Sample scope and assumptions
The sample assumes a read-only review and non-destructive testing in staging, agreed in advance with the system owner.
- Repository, lockfile, migrations and environment-variable template.
- Login flows, invoice API, admin panel, database and storage.
- Authorized staging with two seeded accounts from separate companies.
- Payments, provider console and production infrastructure controls are excluded.
Fictional finding · SYN-AUTH-001Critical
Invoice endpoint allows one tenant to read another tenant's data
The invoice identifier comes from the URL and the query returns that row without binding it to the session tenant. The UI hides other tenants' invoices, but the control is absent from both the API and the sample database policy.
Reproducible sample evidence
- Fictional path app/api/invoices/[id]/route.ts, lines 24–31: the query filters by id only.
- Using the seeded Tenant B session, GET /api/invoices/inv_tenant_a_104 returns 200 with Tenant A JSON.
- The fictional invoices table has no RLS policy comparing tenant_id with the authenticated identity.
Impact
An authenticated user who obtains or guesses another identifier could read another company's invoices, totals and contact details. In this synthetic scenario, cross-customer confidentiality is broken.
Proposed remediation
- Derive the user and tenant from the server-verified session; never accept tenant_id from the client.
- Require tenant_id in the query and an equivalent RLS policy as an independent control.
- Use opaque identifiers only as defence in depth, not as authorization.
- Add a negative cross-tenant case to the regression suite.
Retest criteria
- The Tenant B account receives 403 or 404 for Tenant A's invoice.
- The Tenant A account continues to receive 200 for its own invoice.
- A direct query under the authenticated role is also denied by RLS.
- The negative test runs in CI and fails if cross-tenant reads return.
Limitations and exclusions
- The review is a snapshot of the code, configuration and environment included on the agreed date.
- It is not legal or compliance certification, nor a guarantee that no vulnerabilities remain.
- Destructive load, social engineering and exploitation of third parties are excluded unless expressly agreed.
- Provider-internal controls are assessed only as far as the available configuration makes them visible.
- Any intrusive production testing requires written authorization and a specific scope.
Apply this to your codebase
The diagnosis fixes scope, assets, environments and permissions before any code is shared. If you already have that information, contact us directly.
What you get
Five things by the end.
Written report (PDF)
Severity-ordered findings with file paths, line references, why it matters and a fix sketch. Readable by both engineering and non-technical stakeholders.
Loom walkthrough
15-minute recording of the report, for the cofounder, investor or director who didn't make the live call.
60-minute review call
Live discussion of severity, fix order and the calls that need a human in the loop.
30-day follow-up window
Slack or email for clarifications, fix reviews and a second pair of eyes on the patches.
Turnaround: 5–10 business days
Typical SMB AI-built codebase, kickoff to written report. Larger or multi-repo audits scoped separately.
Who this is for
Three situations this fits.
The founder
You shipped an MVP with v0 or Lovable. It works, users are signing up, and now you're about to flip on payments or move to a real database. You need someone who isn't you to confirm there isn't a hole.
The technical lead
You inherited a Cursor- or Copilot-built codebase from a contractor, an acqui-hire, or the founder's first six months. You need a defensible read of what you actually own before you start touching it.
The agency
You're about to hand an AI-built project to a client. You want a third-party sign-off on the security posture so the handover doesn't become an incident report two months later.
Is my code safe to send you?
+
We work under NDA, on read-only access. We don't keep copies after the engagement closes, we don't train models on your code, and we don't subcontract.
Do you sign NDAs?
+
Yes. We can sign yours, or send ours. Either way, before you share anything.
Can you fix what you find, or only point it out?
+
Both. The default engagement is audit-only to keep the review independent. If you'd rather we fix specific findings, we can scope a follow-on engagement.
How is this different from a generic security audit?
+
Generic audits look for OWASP top-10 in handwritten code. We look for the specific patterns AI coding tools produce, leaked Supabase keys, missing RLS, hallucinated deps, prompt-injection surfaces, that a generic audit will miss because it doesn't know the tool's failure modes.
Do you need to know which AI tool we used?
+
It helps but isn't required. We can usually tell from the code itself within the first hour. Knowing upfront just lets us focus the audit faster.
What if our app isn't AI-built?
+
We'll still audit it, we have a regular code-review service. The AI angle is a wedge because it's where the volume of risk is right now, not the only thing we read.
What stacks do you cover?
+
Next.js, Remix, SvelteKit, React Native, Express, Fastify, Hono, Python (FastAPI, Flask, Django), Supabase, Firebase, Postgres, Vercel, Cloudflare, Hetzner. If your stack isn't on this list, ask.
Other services
AI automation
Repetitive back-office workflows running unattended, with audit logs and human review.
Read more →AI agents
Conversational, multi-step assistants for support, sales and internal knowledge.
Read more →Custom AI
Bespoke classifiers, extractors and scoring tailored to your data and domain.
Read more →CRM/ERP integration
Connecting AI to Salesforce, HubSpot, SAP, Holded, Odoo and the rest of your stack.
Read more →Trust
Safe, traceable AI,
enterprise-ready.
We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
- 01We never train models on your data without explicit authorization.
- 02Human review built-in for processes where risk demands it.
- 03Traceability: prompts, sources, permissions, errors and metrics, all documented.
- 04Privacy, security and control integrated from day one.
- 05Solutions engineered to be maintained, audited and improved over time.
GDPREU AI ActAEPDISO 27001 readyEU data residency
Personal diagnosis
We work with
few clients.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day, not a canned demo.
How we work
- 01Tell us which process eats your time
- 02Personal reply within one business day
- 0320-minute call, no demo, no pitch