Your AI shipped the app.
It didn't check the locks.

Not by default, and the research is consistent about it. Independent testing published by Veracode in 2025 found that when models were given a task that could be solved securely or insecurely, they chose the insecure option in 45% of cases, and that larger, newer models were not better at it. AI coding tools write code that works, and they are genuinely good at that. What they do not do is adversarial thinking: nobody asked what happens when the id in the URL is changed to someone else's, so nobody wrote the check. The application looks and behaves perfectly, which is exactly why the gap survives to production.

You can, and you should, but it answers a different question. Your coding agent reads the code it can see and responds to the instruction you gave it: "make this secure" produces improvements to whatever files it happened to open. It does not observe the deployed application. It cannot tell you which endpoint responds without a session cookie, whether one account can read another's rows, what headers your host actually sends, or which versions your server announces to the internet. VibeGuard tests the running application from the outside, with no knowledge of what you intended, and then hands the results back to your agent as concrete instructions. Finding and fixing are two different jobs; we do the first so your agent can do the second properly.

Then you have removed the easy objection, and three harder ones remain. First, whatever built your application also holds the assumptions underneath it: if it took for granted that a record always belongs to whoever asked for it, that belief shapes both the code and the search for flaws in the code, and from inside there is nothing there to look at. Second, you can only ask about a risk you already suspect; a check is not a question but a protocol that runs the same way whether or not the idea occurred to you. Third, serious findings are chains rather than single open doors — create two accounts, carry an identifier from one into the other's session, and follow where that leads — which needs state, hundreds of steps and a budget set aside for them, where a conversation ends when it runs out of room. And a session you ran yourself cannot be dated, handed to a customer, or repeated to prove a fix worked.

Those tools read your dependency list and tell you which libraries have published advisories. That is useful and you should keep them switched on. It is also a small fraction of the risk: it says nothing about whether your own authorization logic works, whether your database is readable from the browser, or whether checkout can be completed without paying. Those are the failures that actually leak customer data in AI-built products, and they only show up when someone interacts with the live application. VibeGuard covers the dependency question too, based on what your app exposes, but it exists for the part a dependency scanner structurally cannot see.

The live application at the URL you authorise, across access control and data isolation, authentication, session handling, sensitive data exposure, direct data-layer access, injection and cross-site scripting, server-side request handling, file uploads, business-logic abuse, rate limiting, configuration and browser protections, exposed surfaces such as forgotten admin panels and staging deployments, known vulnerabilities in the components you expose, and — if your product has one — the attack surface your own AI feature introduces. The full list, including what is tried in each area, is on the what we check page.

We test everything reachable from the internet, including whatever a normal account gets you: the check signs up through your own public flow the way any visitor would, and works from there. We do not ask you for credentials, and you should be suspicious of any service that does for an automated product. That means privileged surfaces which only an existing admin or an invited team member can reach are out of scope for a self-serve check. If you need those covered, a custom assessment is the right route.

Depth, not features. All three run the same assessment, produce the same kind of report, include the same AI fix prompts and include one fix verification re-check. What changes is how far the assessment gets: how much of your surface is mapped, how many leads are followed before it has to write up, and whether multi-step abuse paths such as skipping a payment step are actively pursued or only noticed in passing. Standard follows roughly two and a half times as many leads as Quick, and Deep roughly five times. Quick suits a pre-launch app with no payments or personal data; Standard suits a live product with accounts and paying users; Deep is for payments, personal data, multiple tenants in one database, or a security questionnaire you have to answer.

No. The check runs entirely against the running application, the way an outsider sees it, which is also the honest way to test whether your defences hold. Read-only repository access will be offered later as an option for deeper analysis, and it will never be a requirement.

No, and we will not pretend otherwise. A penetration test is performed by a human specialist over days, includes manual exploitation and a formal report, and typically starts in the thousands. This is an automated assessment with prioritised findings, evidence for each one, and fix instructions. Where a contract, an auditor or a regulator requires a formal pen test, this does not replace it. For an early-stage product, the honest comparison is not against a pen test you were going to buy — it is against the security review that was not going to happen at all, and against the specific mistakes that actually put your users' data at risk.

A Quick check usually takes one to two hours, a Standard check a few hours, and a Deep check most of a working day. We would rather finish the work than stop early to look fast. You get an email the moment your report is ready, so there is nothing to sit and watch.

Each finding arrives with a plain-English explanation of what we found, why it matters, what could realistically happen, the affected endpoint, the evidence we collected, a severity rating, and a ready-to-use prompt for your AI coding tool. Findings are ordered so the thing that can actually hurt you is first, not the longest list. You fix them in your own time, with your own tools, and then use the included re-check to confirm.

You get the report anyway, and it is worth having. It lists everything that was tested, what held up, and the lower-severity items worth tidying. That document is what you send when a customer's procurement team, an investor or a partner asks what you have done about security — and "we had the live application independently checked, here is the report" is a far better answer than a promise. We do not pad reports to justify the invoice; a clean result is a result.

Yes, and with any other tool that has access to your codebase. Each prompt states the problem, the endpoint, the behaviour that is expected instead, and a test that proves the fix. Paste it in, review the change your agent proposes the way you would review any change, and deploy.

Yes. One fix verification re-check is included with every check, at every tier. After you deploy your fixes it re-tests the findings from your original assessment, against the same application, and tells you for each one whether it is resolved, still present, or inconclusive. It is deliberately not a second full assessment: new features, a new deployment target or a different app need a new check.

No. You pay once for the check you chose and that is the end of it. There is no plan, no seat, no renewal and no card kept on file for a future charge. Run another check when your app has changed enough to deserve one — after you add payments, open sign-ups, or let an agent refactor half the codebase.

No. The assessment is read-only by design: it does not create, modify or delete data in your application, and it does not run destructive or denial-of-service tests. It behaves like an unusually thorough visitor. You may see extra entries in your logs and, if you have alerting on unusual traffic, it may fire — which is itself a small piece of useful information about your monitoring. You do not need to take anything offline or schedule a maintenance window.

We ask you, explicitly, and we record it. Before payment you confirm that you own the application or have the owner's authorisation, and the exact wording you accepted is stored with the order. Testing an application you do not control is illegal in most jurisdictions, so this is not a formality: it is the boundary the whole service is built around. We only ever test the single address you authorised, never a neighbouring host, subdomain or third-party service it happens to call.

Yes. Reports are visible only to the account that ordered the check and are stored in private storage that is not publicly addressable. We do not publish, sell or share findings, and we do not use them to market to you or anyone else. Aggregated, anonymised statistics may be used for research, never anything that identifies your application.