Verdicts you can trust, access you can check.
How Qlane keeps a result honest, what the agent can reach, and where it stops.
The test never grades its own homework.
Qlane keeps the steps that judge a result apart from the steps that produce it. A pass has to hold up against more than the tester’s word.
A test whose expected results are written from the diff agrees with the diff by construction, so a wrong change can pass its own test. In new projects, Qlane splits the work so that a change that does the wrong thing can still fail.
01 / 05 · Expected results from outside the diff
In new projects, one step plans the test actions from the change. A separate step that never sees the diff writes what should happen. It works from the code before the change, the pull request’s description and general rules, for example that data you saved survives a page reload. Where nothing independent says what to expect, the tester records what it sees and reports a defect only when the step looks wrong on its own merits.
02 / 05 · No proof, no pass
In a pull-request run, each browser pass carries a screenshot Qlane captured itself. A pass the tester claims without one is refused, and recorded as blocked if it still has none.
03 / 05 · A second look at passing screens
When a case passes on a pull-request run, a vision check studies Qlane’s own screenshot. It looks for what a person would spot at a glance, such as a dialog drawn under its backdrop, clipped or overlapping text, unreadable contrast or a broken image. If it sees one, the pass is held once and the tester has to look again. It checks once per case, and if it can’t run, the pass stands.
04 / 05 · A second reader for bug reports
When planning has compared the pull request’s description with its diff, a separate check reads a bug’s evidence before Qlane keeps the report. It confirms the evidence shows what the bug claims, and that the expected behaviour is fair to ask of your app. Thin evidence sends the tester back for more. That check never reads the diff.
05 / 05 · Doubt a result? Run it again.
On a finished pull-request run, re-run any case once, three or five times on the same commit. Qlane lists the attempts together and says whether they agree. Re-runs never post to your pull request.
What the agent can reach, and where it stops.
What the agent can reach, what our GitHub App can do, where your secrets and data go, and who trains on them. Where an answer has a limit, we say so.
The full detail is on the Security page, the Data residency page and the sub-processor list.
It works in an isolated sandbox
When Qlane builds your app, it does it in its own sandbox. A Compose stack’s sandbox is destroyed when the run ends. A single-repository sandbox is stopped between runs on the same pull request and removed when the pull request closes. On GitHub, Qlane’s App can read your code and has no permission to change it.
Compose build layers, which can contain source, stay cached in your region for up to 15 days after the test target’s last build, unless you turn caching off for that test target.
It gets steered back to your app
If the agent’s browser is told to open an address outside your app, the first attempt is refused and it is pointed back to your app. A deliberate repeat later in the run is allowed, for flows that really do leave your app.
Links the page follows, and scripts the agent runs on it, are not checked.
House rules for other people’s accounts
The agent is told never to sign in to another service, such as a bank or a tax portal, with credentials the run didn’t give it. It is also told never to email or message an address it wasn’t given.
These are rules in its instructions, and no technical block enforces them.
What the GitHub App writes
The run’s GitHub token expires after an hour. The App writes only to checks, pull requests and issues. On a pull request it posts a check, a review and comments, plus a status summary in the description that you can switch off. It opens an issue only when you file a bug to GitHub Issues. On GitLab, Qlane posts a commit status and merge-request notes through the connection’s own token.
Secrets are encrypted and masked
Variables are encrypted at rest. Known secret values are masked in the dashboard, in build logs and in the text of bug evidence and reports.
Your app still needs them, so a Compose stack’s .env file is written into its sandbox, and the tester uses a test account’s password when it signs in.
Short values, and encoded or transformed copies, are not masked.
Your agent sets it up. You type the secrets.
When a coding agent sets up a test target through Qlane’s MCP server, it hands you a link. You type variable values and test-account passwords on Qlane’s own page. No Qlane MCP tool accepts or returns them, so they don’t need to pass through your editor’s chat.
Stored in the region you pick
Projects, test runs, pull-request diffs, screenshots, chats and build caches are stored in the EU or US region you choose at sign-up.
There is no tool to move an organization to the other region later. Processing isn’t regional. Qlane’s test sandboxes run in the US today, and AI model calls can run in the US or other regions.
No training on your code
We don’t train models on your code, and the model providers we use don’t train on our requests, under their terms or our AI gateway provider’s agreements with them.
Without zero data retention, an Enterprise option, providers may keep requests for a limited period under their API terms.
Only verified editors, by default
By default, only editors Qlane has verified can use Qlane’s tools beyond finding your projects and listing their test targets. Today that means Claude’s clients and Qlane’s registered Cursor client. An organization owner can open it to all editors.