AI era service

AI app launch review

Shipped in a weekend? Make sure it survives Monday.

A fixed-scope review for apps built with AI app builders and coding assistants, before you launch, raise or sign your first big customer.

  • Hosted databases
  • Secrets
  • Access control
  • Fix plan

Scope and deliverables

What we look at

  • Row security, database rules and storage buckets
  • Keys, tokens and secrets in the front end
  • Ownership checks on every generated route
  • Sign-up, login, reset and session handling

What you get

A prioritized fix list your team or your AI assistant can apply, plus a retest.

Typical length

About 1 week

Methods aligned with

OWASP ASVS, OWASP API Top 10, CVSS 3.1

Why it matters

AI app builders and coding assistants get a product live in days. They also repeat the same security mistakes from one app to the next, and attackers know exactly where to look.

This review is built for that moment: before you launch, raise or sign your first big customer. We test the deployed app, its database rules and its API, and we can review the generated code if you share it.

The six mistakes we check first

  • 01

    A database anyone can read

    The browser talks straight to a hosted database. With row security off or rules left open, anyone with the public key can read or change every row.

  • 02

    Secrets in the front end

    Service keys, API tokens and webhook secrets end up in the JavaScript bundle that every visitor downloads.

  • 03

    No ownership checks

    Generated endpoints fetch records by ID and never ask whether the record belongs to the person asking.

  • 04

    Security that lives only in the UI

    Admin buttons are hidden from normal users, but the API behind them answers anyone who calls it.

  • 05

    AI features that take orders from strangers

    Chatbots and agents follow instructions hidden in tickets, documents or web pages, then leak data through their tools.

  • 06

    Packages that should not exist

    Assistants suggest dependencies that are misspelled, abandoned, or registered by attackers after a model invented the name.

How we test it

Hackbots for breadth. Hackers for depth. Every lead is proven or discarded by a researcher before it reaches your report.

Our hackbots

  • Map every route, table and storage bucket the app exposes
  • Check every bundle, source map and env file for keys
  • Replay every route as every role to find missing ownership checks

Our researchers

  • Prove each key live or dead, and each lead real or noise
  • Test sign-up, login, reset and sessions the way an attacker would
  • Write a prioritized fix list your team or your AI assistant can apply

How an engagement runs

Five steps from the first call to the retest. You work directly with the researchers testing your systems at every one of them.

  1. Scope

    1 to 3 days

    We agree on assets, test accounts and rules of engagement, then send a fixed price.

  2. Recon

    First days of testing

    Hackbots map every host, route and role. A researcher builds the threat model.

  3. Exploit

    Most of the window

    Hackbots run the matrix at scale while researchers test by hand and take each lead to the end.

  4. Report and fix

    Within 5 working days

    Verified issues only, each with a CVSS 3.1 vector, replayable proof and a patch.

  5. Retest

    Free, within 90 days

    We confirm each fix and issue an updated report and attestation letter.

Tell us what you run. We’ll send a fixed quote.

No obligation and no sales sequence. A senior researcher reads every request and replies within one working day.