Security testing

Find the holes before someone else does.

Point a security agent at your application and it signs in, maps what you really expose, hunts weaknesses one class at a time, then tries to exploit each one it finds. You get the holes that reproduce, with the request that proves each one and the fix that closes it.

How it works

From a scope to confirmed, closed findings.

A real test is methodical. The agent works through five phases in order, proves what it finds, and then proves your fix worked.

01Scope it

Name what it may touch.

You list the targets and choose how far the agent can go. Reading and mapping is always safe. Anything that changes state runs only where you allow it, and never against production unless your scope says so in writing.

02It runs five phases

Sign in, map, hunt, prove, report.

Each phase is a separate piece of work with its own output, run in order, the way a human tester works through an application. The five are named below.

03It proves what it finds

Only what reproduces gets reported.

A candidate weakness is not a finding. The agent tries to exploit each one, and files it as confirmed only when it reproduces. Anything it cannot prove stays open instead of being reported as fact.

04You fix, it retests

Including the obvious variation.

After your fix the agent re-runs the request that proved the finding, then at least one variation of it, because a fix that blocks the exact request but misses the variant next to it is not a fix.

The five phases

What the agent actually does, in order.

Each phase is its own piece of work with its own result, and the next one starts from what the last one found.

Phase 0Auth

It signs in first.

Give the scan a test account and it authenticates before it starts. Most real weaknesses sit behind the login, so a test that never signs in never sees them.

Phase 1Recon

It maps what you actually expose.

Ports and services, subdomains, the technology behind the site, and the routes that really answer. With source access it reads your dependency versions and route files too, so the map is your real attack surface, not just what the homepage links to.

Phase 2Vuln analysis

It hunts class by class.

SQL injection, cross-site scripting, broken access control, server-side request forgery, path traversal, cross-origin misconfiguration, exposed credentials, missing security headers. Specific weaknesses, looked for on purpose, one class at a time.

Phase 3Exploit

It tries to prove each one.

Every candidate gets an exploitation attempt. The ones that reproduce become confirmed findings carrying the exact request that proves them. With source access, a confirmed finding also cites the line of code behind it.

Phase 4Report

It writes it up, and coverage is checked.

Every finding gets a severity, the evidence, and a remediation. The scan is not marked complete until it has covered the twelve vulnerability classes the platform requires, so a quiet scan has to earn the silence.

What you get

A pentest, not a printout.

Two ways to run it

Black-box or with your source

Black-box sees only your live URL, the way an outside attacker does. Hybrid also reads your source, so runtime behaviour and code are checked against each other and a confirmed finding cites the file and line next to the request that proved it.

Severity floors

Ratings the agent cannot talk down

Left to its own judgement an agent rates things too low. A confirmed SQL injection is never filed below critical, an authentication bypass never below critical, access to another customer's data never below high. The floors are applied by the platform, not chosen by the agent.

Findings that reproduce

The request that proves it

Each finding carries the request that triggers it, so your developer can run it and see the same result rather than take the report on trust. What cannot be reproduced is not written up as fact.

Retest, don't trust

The original request, plus a variation

Fixes get verified by re-running the proof and at least one variation of it. The finding comes back either fixed or still open, and nothing is closed just because someone marked it done.

Scoped and bounded

Only the targets you list

It tests what you named and nothing else, no third-party services, no wandering onto a neighbouring host. No password brute-forcing and no mass scanning, so a security test never turns into an incident of its own.

EU-resident

Tests run on EU rails

Runs on Stockholm-hosted, EU-resident infrastructure, with every action logged.

How it fits

The agents that build it can test it.

Security isn't a separate team here. The same fleet that ships your hosted project with coding agents can pentest it, navigates the code through codebase maps, and runs on one platform where every test is scoped and logged.

FAQ

Straight answers.

Is this a vulnerability scanner?

No. A scanner fires a fixed checklist at your URL and hands back a log to sort out yourself. This signs in, maps what you actually expose, hunts one weakness class at a time, then tries to exploit each candidate and reports only what reproduces.

Can it break my application?

Reading and mapping is always safe and always allowed. Anything that changes state, log-in attempts, injection, requests that write, runs only where you allow it, and never against production unless your scope explicitly says so. It also never brute-forces passwords and never mass-scans.

What does a finding actually look like?

A title, a severity, the weakness class, the affected URL, a plain description, the request that reproduces it, and a remediation. A reflected cross-site scripting hole in a search box, for example, comes back as high severity, class xss, with the exact request that reflects the payload and a fix naming output encoding and a content security policy.

Does it test behind the login?

Yes, that is the first phase. Give the scan a test account and it authenticates before anything else, because the weaknesses that matter are usually the ones only a signed-in user can reach.

How do I know a fix actually worked?

The agent retests the finding: the original request that proved it, then at least one variation, because fixes that block the literal request and miss the obvious variant are common. The finding ends up marked either fixed or still open.

Run a pentest on your application.

Invite-only while we onboard a small number of businesses. Request an invite and we'll be in touch.