It will not test what you have not proven you own
Until a target is verified, only the checks that send nothing an ordinary visitor would not send will run.
Product · Provelex
Give Provelex a URL, prove the application is yours, add a login if it needs one, and tick what you want checked. It opens a real browser, works out what your software does, tries to break it, and writes up what it found in language you can forward to somebody who does not write code.
What it is not
There are no scripts to write, no selectors to maintain and no YAML to keep in step with the interface. Provelex never stores a selector at all. It remembers a target the way a person would describe it — the Sign in button — and resolves that afresh on every page, first by role and name, then by visible text, placeholder, label and test id, and finally by fuzzy match over the accessibility tree.
So when the markup changes you get a heal line on the run timeline rather than a failed test and an afternoon of maintenance. That single property is the difference between a suite that is still running a year from now and one everybody quietly stopped trusting.
Two ways to run it
| Mode | Who drives | Use it when |
|---|---|---|
| Autonomous | Provelex drives the browser | You want coverage overnight, or a gate in the build pipeline. |
| Guided | You drive, Provelex coaches | You are exploring a new feature, training somebody, or want to see a defect happen with your own hands. |
In guided mode a blue ring sits on the control to use next and follows it through scrolling and re-rendering; a red ring marks what is wrong, with a plain sentence saying why it matters. Type your own value instead of the suggested one and it works out what should happen given what you actually did. A guided session produces the same findings, score, evidence and PDF as an autonomous scan.
Coverage
Turning a suite off makes the run cheaper and faster. Turning them all on is what most people do overnight.
| Suite | What it checks | Needs sign-in? |
|---|---|---|
| Functionality | An agent writes test cases from your actual application and drives them in a real browser — forms, journeys, checkout, search, everything it can reach. | Usually |
| Security | Headers, cookie flags, TLS configuration, exposed files, and bounded, non-destructive probes mapped to the OWASP Top 10 (2021). | For anything behind a login |
| Performance | Core Web Vitals measured from the page itself through the browser's own instrumentation, with drift against your previous run. | No |
| Accessibility | axe-core, with every finding translated out of developer language into a plain sentence. | No |
| Mobile view | The same journeys replayed at phone size: horizontal overflow, tap targets that are too small, text below legible size. | No |
Until a target is verified, only the checks that send nothing an ordinary visitor would not send will run.
Provelex looks for weaknesses. It does not exploit them, delete data, or attempt denial of service.
It finds the large, common, expensive class of problem quickly and repeatedly. A specialist adversary studying your business logic is a different exercise.
Permission first
Provelex signs in with real credentials and actively probes for weaknesses. Doing that to somebody else's server without permission is not a grey area, so ownership is settled before any of it runs. Verification is free, permanent, and takes a few minutes by any of three routes:
The signed grant is then stored with the application and reproduced in every report. When a customer's security team asks who authorised this testing and when, the answer is already printed on the document — which is the reason a Provelex report gets accepted at all.
Credentials
Press Test and Provelex signs in for real, then shows you a screenshot of where it landed. It takes seconds, and it saves discovering a typo forty minutes into a run.
The report
One number out of 100, recalculated on every run and tracked over time. It is deliberately simple, because a number an auditor cannot check is a number they will not accept — and the weights are printed in every report so nobody has to take it on trust.
Each severity band is capped, so one noisy accessibility sweep cannot swamp an otherwise sound application.
| Score | Reads as | What it usually means |
|---|---|---|
| 90–100 | Strong | Nothing serious outstanding. Keep scanning on a schedule. |
| 75–89 | Good | Minor issues. Fold them into normal work. |
| 50–74 | Fair | Real problems. Plan the fixes. |
| 25–49 | Weak | Something is likely to bite you. Deal with it this sprint. |
| 0–24 | Critical | Stop and fix before your next release. |
The second run of an application is more useful than the first. From then on every report carries drift against the previous one — what was fixed, what is new, whether performance moved. A single score is a snapshot; the trend is the thing you manage.
Pricing
Credits buy model time and nothing else. The browser automation, every page opened, every click and screenshot, all the deterministic checks, and every report you read or export are free. Each new account starts with fifty credits.
| Operation | Credits | What it covers |
|---|---|---|
| Passive scan | 2 | Performance, accessibility and mobile view. No sign-in to the target. |
| Guided session | 10 | Provelex coaches you through your application, step by step. |
| Full scan | 15 | Everything, including functionality and active security probes. |
One credit is ₹0.50, or about $0.01, so a full scan costs roughly the price of a cup of tea. The joining credits are worth 25 passive scans, 5 guided sessions, or 3 full scans.
A run that produces nothing is refunded in full. Not a proportion — every credit. Refunds are automatic and immediate; there is nobody to ask. A run that produced a report keeps its charge even if you did not like what it said, because partial output is still output.
If a balance will not cover a run, Provelex says so before starting rather than half-way through. Nothing is reserved and nothing is lost.
You choose which model does the thinking, and the range of what those models charge is enormous — the most capable are around a hundred times the price of the default. So the price follows the choice, and the exact figure is always shown before you start. The default model handles the overwhelming majority of testing perfectly well, and it is the cheapest option.
Where it runs
The hosted dashboard cannot see an application on localhost, a staging server inside a corporate network, or an internal tool behind a VPN. The desktop build can, because the browser is running on your machine.
The browser and the pages it opens, your screenshots and video, the local database, and every deterministic check — headers, TLS, accessibility, performance. Provelex drives a private copy of Chromium, so your own browser, profile and open tabs are never disturbed.
The model keys, the credit balance, and the model calls themselves. The app never holds a provider key, so there is none to extract — it buys a spending-capped grant before a run starts, which is why editing anything locally cannot manufacture free work.
Provelex accepts any OpenAI-compatible endpoint, which covers Ollama, vLLM and LM Studio. Point it at your own server and no page content leaves your network at all — and local models spend no credits, because they cost us nothing.
Reports export as PDF for a client or a security team, HTML with the evidence inline, and JSON for a dashboard or a ticket tracker. Exports are free and unlimited — you paid when the work was done, not when you read it.
Logo, company name, accent colour and footer text are all yours to set, per client if you are testing on somebody's behalf. The document then looks like your own work, because it is.
Everything the dashboard does is available from a terminal, and the service exposes a documented HTTP interface, so your own tooling can do it too.
python run_all.py run https://staging.example.com --json
With --json, Provelex exits non-zero when a critical or high finding is present. That one line is enough to make any build system refuse a release that introduces a serious defect.
A scanner finds the exposed configuration file. A QA team finds the checkout that accepts an impossible quantity. Provelex finds both, and writes them up so the person approving the fix understands what it costs to leave it alone.