Request an assessment
plen
Sign inAgents, skills and MCP serversFor vendors: evidence profileRule packsMethodologyPricingAPI and MCPKnowledgeyesforai

For software, no-code and automation agencies

Hand the project over without guessing whether something is exposed

The last question before release is always the same: is this secure. arLET’S turns it into a repeatable procedure with evidence you can show your client.

Submit your first projectHow we work

01

What usually turns up

These are not exotic vulnerabilities. They are the things that keep repeating in projects built fast, by teams without in-house security.

  • 01

    Client A sees client B's data

    Most often because the access policy covers reads but not writes, or is missing on one table out of twenty.

  • 02

    A service key in the browser

    It gets there through a single admin view or a variable without the public prefix. It gives full access to the database.

  • 03

    Attachments without a policy

    File URLs are predictable and the bucket does not check who is asking. Swapping the ID in the URL is enough.

  • 04

    Endpoints nobody remembers

    Test routes, a debug panel, an old API version. They stay after deployment and nobody turns them off.

02

What the client gets

Not a list of vulnerabilities to interpret on their own. A decision they can act on.

The report ends with one card: accept, conditional, reject or unknown. The card says why, what we don't know, what must be fixed before release, who owns it and until when the result is valid.

It also lists the areas we did not check. That part protects you, not us: the client cannot later say they thought you had checked everything.

The report can go out under your brand.

Example · synthetic data

Releasing an app for an agency's client

Client portal, Supabase deployment

Conditional
Why
  1. 1The invoices table is readable by a signed-in user from another account. Reproduced on two test identities.
  2. 2The service key reaches the browser in one of the admin views.
  3. 3The attachments bucket has no read policy, and file URLs are predictable.
What we don't know (2)
  • No confirmation of who has administrative access to the production environment.
  • Backup configuration and a restore test were not shared.
Conditions before rollout

  • Close the read policy on the invoices table and add a regression test.

    agency team · due before release

Not checked
  • production environment
  • payment integrations
  • performance under load
  • mobile app

Decision scope: repository, configuration, access policies, public surface

Assessed on: 14 August 2026

Evidence level: L2, read-only access to the repo and schema

Decision expires: 14 November 2026

Human review: yes, before the decision was issued

03

How it works in practice

The first project takes longer because we agree the scope. The next ones run from a template.

  1. You submit a project: a URL, a repository or a configuration bundle.
  2. We agree the scope and what we get access to. Read-only by default.
  3. We check the public surface, code, configuration and data boundaries.
  4. You get a prioritised list of blockers, separated from things that can wait.
  5. You fix them. We run a retest and add it to the report.
  6. The report goes to the client under your brand, with scope and date.

04

What we don't do

  • 01

    We don't talk to your client behind your back

    You own the client relationship. We can join the call if you want.

  • 02

    We don't test anything without authorization

    Tests that touch a live system need a written authorization with a scope and a time window.

  • 03

    We don't publish results

    The report belongs to you and your client. We don't turn it into a ranking or a wall of shame.

Start with one project

Pick the one that worries you most and see what the report looks like. Decide on an ongoing engagement after that.

Request an assessmentSee pricing