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 with zero-data-retention routing enforced (see section 4).
5. The run ends. The sandbox — including the repository clone and everything built inside it — is destroyed. What persists is the product output you see in your dashboard: test cases, results, transcripts, and screenshots (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. 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.
• The sandbox has no access to our internal network or platform credentials. It contains exactly: your repository clone, the short-lived repository-scoped token used to fetch it, and the environment variables you configured for your test environment.
• 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-retention routing

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

• All model inference runs through Vercel AI Gateway. We use exactly two model providers: Anthropic (primary) and OpenAI (fallback).
• Zero data retention is enforced at two independent layers: as a team-wide gateway setting, and per-request on every single AI call our platform makes. Requests are routed exclusively to model providers with which the gateway vendor holds contractual zero-data-retention and no-training agreements. Enforcement is fail-closed: a model outside that coverage is rejected with an error rather than silently served.
• 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 are contractually barred from retaining or training on them under the gateway’s agreements.
• 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. This cache is covered by the same gateway routing guarantees and is never used for training.

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

Destroyed with the sandbox: your repository clone, the built application, and all build artifacts. qlane keeps no copy of your codebase.

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.

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 and is then physically purged — storage objects, database rows, and identity records — consistent with GDPR right-to-erasure timelines.

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.