Security

This page describes how qlane handles your source code: what we access, where it runs, what reaches AI models, and what we keep. It complements our Data Residency page and Privacy Policy, and is the canonical reference for security teams evaluating qlane.

1. How your code flows through qlane

1. You install the qlane GitHub App on the repositories you choose — and only those.
2. A test run starts (a pull-request event or a manual session). We mint a short-lived access token scoped to that repository and clone it into a fresh, isolated sandbox created for this run only.
3. Your app is built and started inside the sandbox using the build commands and environment variables you configured. Browser testing runs in an isolated cloud browser session — never on our application servers.
4. AI analysis sends the relevant code context — diffs, file excerpts, test output — to model providers through an AI gateway that requires no training on every request, and zero data retention for organizations that have it (see section 4).
5. The run ends. The sandbox — including the repository clone — is destroyed. What persists is the product output you see in your dashboard — test cases, results, transcripts, and screenshots — plus what each tool returned during the run, kept for audit rather than display, and your environment’s build layers, which can contain source code and dependencies, cached in your data region for up to 15 days after the environment’s last build unless you turn build caching off (see section 5).

2. GitHub access: scoped, short-lived, revocable

Access is via a GitHub App installation — not a personal OAuth token, not deploy keys. You choose which repositories the App can see. The App’s complete permission set (everything else is “no access”):

• Contents — read-only. Clone the repository under test. qlane holds no write access to your code.
• Metadata — read-only (mandatory for every GitHub App). List repositories and basic repository info.
• Pull requests — read & write. Read diffs; post test reports as PR comments.
• Checks — read & write. Publish test status to your CI checks.
• Issues — read & write. File bug reports as issues, only when you use that feature.

At run time we exchange the App credential for an installation token that expires after about one hour and is scoped to the repository under test. Apart from the short-lived build-cache token described in section 3, the sandbox receives only this token — no other credentials and no platform secrets. Revocation is instant and unilateral: uninstall the App and qlane loses all repository access.

3. Ephemeral, isolated test sandboxes

• Every run gets a dedicated, isolated sandbox microVM, created on demand and destroyed when the run completes. Sandboxes are never shared across runs, projects, or customers. What a later run of the same environment does reuse is that environment’s own build cache: layers from its earlier builds, reached with a token scoped to that one environment (see section 5).
• The sandbox has no access to our internal network, and no platform credentials except a short-lived build-cache token that reaches only this environment’s build cache and is used while your services are being built. It contains exactly: your repository clone, the short-lived repository-scoped token used to fetch it, the environment variables you configured for your test environment, and, for builds that use the build cache, that build-cache token.
• Browser interactions with your running app happen in isolated per-session cloud browser instances, separate from both the sandbox and our application servers.

4. AI and LLM processing: no training, zero data retention on Enterprise

This is usually the biggest concern for security teams, so we are precise about the mechanism:

• All model inference runs through Vercel AI Gateway. Every request made in work started after 12 October 2026 is restricted to the model providers listed on our Data Residency page: Anthropic, Amazon Web Services (Amazon Bedrock), Microsoft (Azure), OpenAI, and TypeSafe AI for our evaluation model. A request none of them can serve is rejected, not sent elsewhere.
• Zero data retention, available on Enterprise. For an organization whose Enterprise agreement includes it, qlane turns zero data retention on, and every AI request made for that organization in work started afterwards is served only by a provider that keeps no prompt or output after the request (apart from the short-lived prompt caching below), under our AI gateway provider’s agreements with each provider. Enforcement is fail-closed: a request no such provider can serve is rejected with an error rather than served without it.
• Without zero data retention, model providers may keep requests for a limited period under their standard API terms (for example, for abuse monitoring). They never use them for training, under their terms or our AI gateway provider’s agreements with them. Zero data retention, available on Enterprise, removes that retention.
• No training, at any layer. qlane does not train models on your code; the gateway does not use traffic for training; and the model providers receiving our requests never use them for training, under their terms or our AI gateway provider’s agreements with them.
• The gateway itself keeps no content. Prompts and responses are deleted once each request completes; gateway request logs contain usage metadata only (token counts, cost, latency) — not prompt or completion bodies.
• Honest exception — short-lived prompt caching. For performance, prompt prefixes may be cached at the model provider for up to 5 minutes before deletion, including for organizations with zero data retention. This cache stays with the same providers and is never used for training, under their terms or our AI gateway provider’s agreements with them.

5. What we store after a run — and what we don’t

Destroyed with the sandbox: your repository clone and the running application.

Cached per environment: the layers your environment’s builds produce, which can contain source code and dependencies, are cached in your data region for up to 15 days after the environment’s last build, so later builds of the same environment can reuse them. Build caching can be turned off for any environment, which deletes its cached layers.

Retained — the product output you see in your dashboard, which may contain code excerpts (selectors, snippets, diff fragments) where the AI discussed them:

• Test cases and verdicts.
• Session transcripts (agent reasoning and chat).
• Screenshots of your running app.
• Test-case embeddings used for retrieval and search.

We also keep, for audit rather than display, what each tool returned during a run — page snapshots, command output, API responses. These are not shown in the dashboard; they let us check an AI-written finding against what was actually observed. They are kept on their own, shorter horizon, stated in Section 6 of our Privacy Policy.

All retained data is encrypted in transit and at rest and scoped to your organization. When you delete your organization, data enters a 48-hour recovery window; after it elapses we delete your database rows — which removes every session, verdict, transcript and captured tool output with them — along with your organization’s logo images and your records at our identity and billing providers, consistent with GDPR right-to-erasure timelines. Files written to object storage during a run, such as screenshots and offloaded tool outputs, are unlinked by that deletion rather than removed object by object: nothing in the product can reach them once the rows are gone. That is specific to organization deletion. On the routine retention timeline published in Section 6 of our Privacy Policy, an agent tool output reaching the end of its window has its stored object deleted first and our pointer to it cleared only once that has succeeded; deleting the rows removes the pointer ahead of the sweep, which is what leaves the object behind. Your environments’ cached build layers do not wait for the recovery window: deleting your organization starts their deletion, so a restored organization may start without them.

6. Data residency and encryption

qlane runs in two isolated regions — EU and US. Your organization’s data (database, retained artifacts, screenshots) lives in the region you sign up in and is served from it. Customer content is never replicated cross-border. Everything is encrypted in transit (TLS) and at rest. Full details, including the regional architecture and its deliberate limitations, are on the Data Residency page.

7. Sub-processors

The canonical, maintained list of sub-processors — including our sandbox, browser-runtime, and LLM vendors, with the GDPR transfer safeguards each operates under — is published on the Data Residency page. We update that page when sub-processors are added, removed, or materially change their role.

8. Working with your security team

• Mutual NDA — we sign NDAs with customers evaluating qlane; we’ll also review yours. Email [email protected].
• Data Processing Agreement — a GDPR Art. 28 DPA is available on request (see the Data Residency page).
• Security questionnaires — we answer them. For anything this page doesn’t cover, ask [email protected].

9. Roadmap

A SOC 2 Type II audit is on our roadmap; the report will be published through a trust center with request-based access. Until then, this page and the Data Residency page are kept current as the authoritative description of our security posture.

10. Contact and responsible disclosure

Security questions and vulnerability reports: [email protected]. We respond to every report.