Validation Services

You can't tell whether an AI-built app is secure by using it. You need someone to check how it's built and how it's set up. A launch check by Messy Works looks at the places where AI-built apps most often fail:

• secrets (passwords and API keys) left in the code
• database access rules
• sign-in and permissions
• outdated software packages
• backups that have never been restored
• monitoring that nobody responds to

Most of these problems sit around the code, not in the features. That is why an app can work perfectly and still leak data. Messy Works runs these checks, fixes what it finds, and gives you a written report showing what passed and what changed. Run the check before real customers or real data arrive, and run it again after every major release.

See also the homepage FAQ: I built an app with AI. How do I know if it's secure?

In September 2025, Wiz Research reviewed apps built on vibe-coding platforms (tools where you build an app by describing it in plain language). It found four recurring problems:

• Sign-in checked in the browser. Anyone can read the code and get past it.
• Secrets written into the code. API keys and service account credentials are visible to anyone who looks.
• Database rules that are too open, or switched off. In tools such as Supabase these are called row-level security (rules about which records each user can see).
• Internal tools on the public internet with no login. Admin dashboards and test sites are left open.

Messy Works checks for each of these as part of validation. Fixing them is usually a configuration change, not a rebuild.

Source: Wiz, Common security risks in vibe-coded apps.

AI-generated code often has security flaws, and it looks just as finished as safe code. In July 2025, Veracode tested more than 100 AI models on 80 coding tasks. It reported that the AI "introduces security vulnerabilities in 45 percent of cases". The models failed to defend against cross-site scripting (an attack that plants malicious scripts in web pages) in 86% of relevant cases. They failed to defend against log injection (planting false entries in system logs) in 88%. These are a security vendor's own findings, so treat them as one strong signal, not a final figure.

The practical lesson is that AI makes code faster to write, not safer. Code written with AI needs the same independent check as any other code before it handles customer data. Messy Works provides that check.

Source: Veracode press release, 30 July 2025.

A production readiness review checks a product against a list of minimum requirements. "Production ready" is a checklist, not an opinion. At a minimum, a production-ready product has:

• no secrets in its code or repositories
• access rules that have been checked independently
• backups that have actually been restored
• monitoring with a person who responds to it
• rate limiting (a cap on how many requests a user can make)
• a rollback path that has been used at least once
• documentation a new person can follow

Messy Works puts each product through five gates before issuing its production-ready stamp. You get a written record of what passed, what didn't and what was fixed.

See also the homepage FAQ: What does "production ready" actually mean?

A penetration test (an authorised, simulated attack) shows whether someone can break into your product at one point in time. A production readiness review checks whether the whole product is fit to run. That covers security, and also backups, monitoring, recovery, performance and cost. Many AI-built products fail on the basics a penetration test doesn't focus on, such as untested backups or alerts nobody receives. Messy Works starts with the readiness review because it finds the most risk for the effort. A penetration test is most useful once those basics are fixed, or when a customer or insurer specifically asks for one.

Check an app after every significant release and on a regular schedule, not just once at launch. Every release, new dependency or configuration change can open a new gap. New vulnerabilities are also published in software you already use. Messy Works runs continuous validation: the checks repeat automatically after releases and on a schedule, and urgent findings are raised as incidents straight away instead of waiting for a report. Everything else is summarised in a monthly report. That way the product stays in the state you signed off, rather than drifting after launch.

Yes. Messy Works regularly validates products built by founders and business teams using AI tools, with no developers involved. You give read access to the code and the hosting account, and Messy Works does the review. The report is written in plain English, ranks each issue by risk, and says what was fixed and what still needs a decision from you. Nobody on your side needs to read code.

AI features bring risks that ordinary web apps don't have. The OWASP Top 10 for LLM Applications 2025 lists prompt injection first. That's where a user tricks the model into ignoring its instructions. Second is sensitive information disclosure, where the model reveals data it shouldn't. Other common risks are unbounded consumption (usage that runs up large bills) and improper output handling (trusting what the model returns without checking it). Messy Works tracks failure rates, refusals and malformed responses from AI features, alerts on token spend against a budget, and keeps a trail of prompts and responses for audit.

Source: OWASP Top 10 for LLM Applications 2025, as summarised by HackerOne.

Show evidence, not promises. Enterprise buyers and investors usually ask for written proof: how access is controlled, how data is protected, how backups are tested and who responds to incidents. Messy Works validation produces that evidence as a dated report you can share, and the results can be used to answer a security questionnaire. If the review finds gaps, fix them before you answer, so your answers are true when you send them. Because Messy Works is ISO 27001 certified, its access and change records also hold up when your auditors look at them.

See also the homepage FAQ: An enterprise customer sent us a security questionnaire and our app was built with AI. What now?

Most serious problems Messy Works finds in AI-built apps are fixed without a rebuild. They are usually configuration and deployment issues, such as open database rules, exposed keys or missing backups, not faults in the product's design. Messy Works ranks each finding by risk, fixes the urgent ones first, and agrees a plan for the rest with you or your build partner. A rebuild is only recommended when the underlying design can't support what the business needs. One example is a single shared database for a product that must keep each customer's data separate.

See also the homepage FAQ: Should I rebuild my AI-built app, or can it be fixed?