Each agent takes a single angle
A login flow, a tenant boundary, file access, an endpoint that answers without a session. An agent tests whether the application behaves as specified, rather than matching responses against a list of known patterns.
Agents work through seven phases against what a domain exposes from outside. Every candidate is reproduced before it becomes a finding. Four reports are available once you open the run.
Three properties define it. Each one is described in detail further down this page.
A login flow, a tenant boundary, file access, an endpoint that answers without a session. An agent tests whether the application behaves as specified, rather than matching responses against a list of known patterns.
Candidates found in the testing phases are handed to a separate phase and reproduced from scratch. What cannot be reproduced is dropped — not downgraded to informational, not moved to an appendix.
A summary without reproduction steps or raw evidence, and a technical report with both. Each finding carries a CVSS-aligned severity and the ISO 27001 and SOC 2 controls it touches.
Seven phases, in this order. Each reports two counters while it runs, both visible live in the dashboard. A run can be stopped at any point and ends within seconds.
The run builds an inventory of what the domain exposes: hosts, subdomains if the scope allows them, endpoints that answer, and the files the pages load. The inventory is built from outside. Nothing is taken from a supplied configuration.
Every bundle, source map and static file the application serves is read. This is where credentials appear in shipped code: Stripe secrets compiled into a build, AWS keys in a published environment file, private keys in a source map. Anything a browser can load is in scope for this phase.
Sign-up, sign-in, reset and session handling. The phase tests whether sessions end when they should, whether tokens are predictable, and whether a flow can be completed out of order — a reset link that still works after the password changed, a logout that ends one session and not another.
Tests whether one account can reach objects belonging to another. Identifiers are enumerated and permissions crossed; every response that returns data where it should return 404 is recorded. On a multi-tenant application this phase requires knowing what is supposed to be permitted, which is what separates it from pattern matching.
Inputs receive values they do not expect. The run sends only GET, HEAD, OPTIONS and POST, and does not write, delete or modify data. What is evaluated is the response: error messages that name internals, timing that differs by input, output that was not asked for.
Candidates from the preceding phases are not findings. Each is reproduced from scratch in this phase. What cannot be reproduced is dropped: not recorded as informational, not listed in an appendix. This is the phase that determines the length of the report.
Each finding receives a score, a severity band, the location in the code where one applies, the change required, and the controls it touches. Reports are written during the run and are available the moment it ends.
They answer different questions: what was found and what it reaches, and how to reproduce and close it. Exports are dated and unlimited.
Findings, impact and reach. It contains no reproduction steps and no raw evidence, which is what makes it suitable to hand to a customer, a buyer or an auditor.
The same findings with the request that proves each one, the location in the code where one applies, and the change required. One free re-test is included within 14 days — it covers every finding you marked as fixed.
The score is derived from reach, sensitivity, reliability and exposure. The bands follow the CVSS v3.1 and v4.0 qualitative ratings scaled to that range: critical from 90, high from 70, medium from 40.
Each finding names the controls it touches in ISO/IEC 27001:2022 Annex A and the SOC 2 Trust Services Criteria — for example A.5.17 for authentication information, A.8.28 for secure coding, CC6.1 for logical access.
Polaris1 is not a certification body and issues no certificates. The output is technical evidence for a certification, in the structure an audit expects. Each report states this on its first page.
Each limit below is enforced by the system rather than stated in a contract. All of them are shown on one screen before a run starts.
A TXT record must be visible to two independent resolvers before a domain can be tested. Wildcard targets require the record on the root domain. A domain that has not been verified is never contacted.
Target and subdomain setting, requests per second, the four HTTP methods, the excluded paths, and the fixed source addresses the traffic comes from, so monitoring on the receiving side can distinguish it from an unrelated attack.
Gentle: 2 requests per second, 2 concurrent. Normal: 10 and 8. Thorough: 40 and 24. Each profile also enforces a minimum delay between two requests to the same endpoint. The ceiling is set below what a normally dimensioned application handles.
Concurrent runs against the same organisation are prevented by a unique index in the database, not by convention. A running test is stopped with a single call and ends within seconds.
Envelope encryption with AWS KMS. The encryption context is bound to the organisation id, so the same ciphertext decrypted under a different account yields nothing. This is a property of the encryption, not of an access rule.
Unredacted evidence opens through a link valid for minutes, and every access is written to the audit log. Secrets are redacted before storage: what is kept is what proves the finding, not the records it was found in.
How access is granted, limited and withdrawn.
Owner, admin and viewer. A viewer can read findings but cannot start a run or unlock a report. Capabilities are checked server-side against the role; the interface only hides what the API already refuses.
A single finding can be shared with someone who has no account — either its detail, or its detail and evidence. Grants are revocable and every access is logged.
Polaris1 support cannot read findings unless access is granted, with a reason recorded against the grant. It can be revoked at any time.
Runs can be started from a pipeline and completion delivered by webhook. A key can do exactly two things — start a run and read the counts. It never reaches finding detail, evidence or payment, whatever the role of the person who created it.
An optional read-only grant. It is listed in the dashboard alongside the others and takes effect only while it exists.
Sign-in is by six-digit email code, Google or GitHub. There is no password column in the database. TOTP can be added as a second factor.
Add a domain, prove ownership with one DNS record, start the run. The first check is free and requires no payment method.