The questions people actually ask.

Thirty days on one application for $199, with the whole product switched on. Before day one we write down what a successful pilot looks like for you and both sides sign it. On day thirty there is a readout meeting where you either have the evidence against your own application or you do not, and if you convert to an annual licence the $199 comes off the price.

Three things. A repository URL and the branch you want read, over HTTPS, with a scoped token if it is private. A running address for the application, usually staging rather than production for a first run. And one working login for each role the application has, so we can test each role against every door instead of poking at the outside as an anonymous visitor.

Because the findings we care most about are the ones where one role reaches another role's data or actions, and you cannot see those with a single account. A scanner has one login, so it can never test what a support user can do to a customer's record. Give us viewer, support, manager and admin and the authorization matrix has something to fill in.

Registering the application itself is a short form: its address, its repository, the branch, the environment and the owning team. The parts that take real time are on your side, namely getting a staging environment we can reach and creating a test account for each role. Teams that already have both are usually running a first scan the same day.

No. There is no self-serve signup or billing, and we are not pretending otherwise while it does not exist. You email us or send the form, we provision the account by hand, and we invoice you.

An engineer, not a sales sequence. We set up every account by hand, and the person who walks you through the first scan works on the product. If we do not think we are the right fit for you yet, that is what the first reply will say.

Staging, for a first run with exploitation enabled. Exploitation is off unless you turn it on, and you set it per application along with a list of anything destructive we should leave alone. Most teams settle on exploitation against staging and look-only against production.

One deployed thing, identified by its primary hostname. Its front end, the APIs behind it and the repository it is built from are all one application, not three. A staging copy of the same application is not charged separately.

$199 for thirty days on one application. If you convert to an annual licence, the $199 is credited against it. If you do not, you have paid $199 to find out, which is the point.

$699 per application per year, locked for two years from signing, available until 28 February 2027. From 1 March 2027 the list price for new customers is $1,199 per application per year. Running the scan agent inside your own network is $944 per application per year, which is the founding price plus 35 per cent. The full price list →

No. All prices exclude 18% GST, which applies to customers invoiced in India. International customers are invoiced without GST. It is stated on every quote and order form so there is no surprise on the invoice.

No, and there will not be one. Running a scan costs us real compute and costs you real inference, so a permanently free tier would be dishonest about what it could offer. The $199 pilot is the cheapest honest way to find out whether this works on your application.

No. Licences are per application per year and scans are unlimited, so nobody on your team has to weigh up whether a run is worth it. There is no per-scan charge anywhere on our price list.

The AI inference, billed to you directly by your own provider, because you bring your own AI key at every tier. We add nothing to it, you keep your own contract and terms, and we have no incentive to make a scan longer than it needs to be. Spend is recorded against each scan today, and hard caps with the cost shown before and after every run land 13 November.

Manually, today. We raise an invoice and send you a payment link, annually in advance. Self-serve billing, card on file and a subscription you can change yourself are not built, and until they are we would rather send you an invoice than pretend there is a portal.

Access is suspended, not deleted. Your findings history, evidence and reports stay intact and come back when the subscription resumes. Ask us to delete it instead and we will.

Web applications and the APIs behind them. We read the code while driving the running application, signed in as each role you gave us, and we try to break it. We do not scan networks or infrastructure, and we are not trying to out-count anyone on the number of checks.

Ten classes: injection, cross-site scripting, authentication, authorization, server-side request forgery, weak cryptography, configuration, business logic, dependencies and secrets. Authorization is the one we built the company around, because it is the class a tool with one login can never reach. Business-logic abuse as a full module is dated 4 January. All ten, explained →

Six severity tiers: critical, high, medium, low, informational and best practice. How certain we are is tracked separately from how bad it is, so you can sort by damage or by confidence rather than having the two mixed into one number.

The request we sent and which role was signed in when we sent it, the response that came back and what should have come back instead, a screenshot of the result in a real browser, and the file and line of code that allowed it. Anything less than that is a suspicion rather than a finding, and it is the difference between an engineer fixing it and an engineer first trying to reproduce it. See a real one →

We try to exploit it, and if we could not, we do not put it on the list you act on. Exploitation is off until you switch it on, per application, with a list of anything destructive to leave alone. The things we suspected but could not break are filed separately as suspicions for whoever wants to go looking.

One switch that makes the list hold only what we actually broke, with nothing to triage first. It ships 19 October, together with an exploit-proof export you can hand to someone outside the team.

By re-running the exact attack that worked and checking that it now fails. Rescanning is a new guess; re-exploiting is proof, and "fixed" stays a hypothesis until the same request comes back refused. Automatic proof on close ships 16 November. Today you can already re-run against only the confirmed findings rather than paying for a whole scan to check one line. Closing the loop →

We have not measured it in a way we are willing to publish, so we are not going to give you a number here. Wall-clock duration on real applications is one of the figures in the benchmark that publishes 3 November. What we can tell you now is that findings land in the console every fifteen seconds as they are confirmed rather than arriving in one lump at the end, and that a re-run after a fix is much shorter because it only replays the attacks that previously worked.

We have not published one and we are not going to invent one. The benchmark runs against OWASP Juice Shop, WebGoat, DVWA and real open-source applications with known CVEs, and on 3 November it publishes the detection rate, the false-positive rate, the duration and the dollars per scan, including the misses. If the numbers are ugly, you will see them anyway. What we have not proved →

Neither. Keep your scanner; this is for the bugs it cannot see, because it has one login and cannot read your code while it attacks. Keep the annual pentest; this covers the other eleven months. Compared, honestly →

With the agent running inside your own network, it never arrives: the repository is cloned on your hardware, read there, and we receive findings rather than code. On a hosted scan it is cloned read-only into a temporary directory for the length of one scan, and that directory is wiped the moment the scan reaches a terminal state, whether it completed, failed or was cancelled. Nothing is cached between runs.

Where the work happens. Hosted, we clone and drive your application from our infrastructure for the length of a scan. Self-hosted, you run one container inside your perimeter and the code is never transmitted to us at all. The console, the findings and the reports are the same either way. Private scanning →

Every organisation gets its own database schema, and a request is pinned to exactly one schema for its entire life. There is no organisation ID being compared in a query, because another customer's tables are not reachable from that connection at all. A cross-tenant test runs on every pull request and fails the build if it ever succeeds. How it is built →

Whoever you allow. Forty-three separate permissions are grouped into roles and enforced on the way into every route, with 105 routes verified against the policy when the platform starts, so access is not merely hidden in the menu. Teams and groups let you scope visibility so a squad sees only its own applications, and a per-organisation audit log records who ran what and who changed what.

Platform administrators manage the tenant registry and provision schemas. They have no application route into your scan data. If we ever need to look at something inside your organisation to help with a support case, we ask you first.

Encrypted with AES-256-GCM using a key held outside the database, or not stored here at all: point an application at your own Azure Key Vault and the credentials are resolved at the moment a scan starts and never persisted with us. They are write-only in the console, masked in the interface, stripped from logs, and redacted out of reports before the page is rendered.

Relevant parts of it go to the model you chose, on your own AI provider key, under your own contract and data-processing terms with that provider. That applies at every tier, including self-hosted, which is the honest limit of "your code never leaves the building" today. Running the whole thing against a model you host yourself is a request we get often and have not built.

One machine inside your perimeter that can reach the application under test and the repository, plus outbound HTTPS to us. You create the agent in the console, copy a single-use enrolment token, and start it. It trades the token for a lasting key on first contact and then asks for work.

A Linux binary, a macOS binary or a Docker image. All three enrol the same way and take the same environment variables. The install page →

Four outbound calls and nothing else: enrol once on first start, a heartbeat so the console can show it as online, a request asking whether a scan has been queued, and the results going back. Findings and evidence go out; your source does not.

No. The agent listens on nothing, so there is no inbound rule to write, no VPN to terminate and no route from our side into your network. Every connection starts from the agent. We port-scan the agent container in our own build pipeline on every release, so if a listening socket ever appears the release does not ship.

Revoke the key in the console and the agent stops being given work immediately. There is no rotation exercise and nothing to wait out. The agent also reports which build it is running, and it stops receiving work if it drifts from the version we expect.

$944 per application per year, which is the founding annual plus 35 per cent, for everything in the founding plan executed by an agent inside your own network. All prices exclude 18% GST, which applies to customers invoiced in India.

Not today. An air-gapped install and bring-your-own-model are the two requests we get most often from security teams, and neither is built. We will keep saying that until it is true. The full gap list →

Email hello@cyberlop.com. It reaches the same small group of people for pilots, pricing and support, and a person reads every message. We are in New Delhi and work with customers over email and video. Contact →

Within one working day, and usually sooner. We do not publish a contractual response or uptime commitment yet, because we are five people and a number we cannot hold to is worth nothing to you.

Not yet. A public status page, along with off-box backups and a timed restore drill, is dated 18 December. Until it exists there is no published uptime history, which is a fair thing to hold against us.

We email affected customers directly, tell you what happened and what it touched, and say what we are changing. A scan that fails mid-flight is recorded as failed rather than quietly discarded, and its temporary workspace is wiped in the same way a completed one is.

Yes. If a review board has to see the design before you can trial anything, we will walk them through the architecture and answer the questionnaire ourselves, including marking the questions we cannot answer as such. A written pack of the answers publishes 27 October.

Please tell us. Our disclosure policy sets out scope, safe harbour and what to expect, and reports go to hello@cyberlop.com with "Security" in the subject line. We will not send lawyers. The policy →