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.
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.
A real test is methodical. The agent works through five phases in order, proves what it finds, and then proves your fix worked.
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.
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.
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.
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.
Each phase is its own piece of work with its own result, and the next one starts from what the last one found.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Runs on Stockholm-hosted, EU-resident infrastructure, with every action logged.
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.
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.
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.
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.
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.
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.
Invite-only while we onboard a small number of businesses. Request an invite and we'll be in touch.