What actually happens to your repository when you scan it with Quantera — architecture, handling, and the controls around both.
Six components, each scoped to do one job.
The web application you interact with — session-based, served over TLS, with no direct access to stored source code outside an authenticated, workspace-scoped session.
Every scan, finding, migration, and verification run is created and read through an authenticated API. The frontend has no privileged path around it.
Runs the AST-based Python parser and the JCA-pattern Java parser against a scanned repository to produce findings. It reads code; it does not execute it.
Writes source transformations only for recipes explicitly approved by the policy engine — see Product for how that boundary works.
Builds, tests, and rescans for verification run in an isolated, ephemeral environment — not your CI, not your workstation.
A GitHub App connection scoped to the repositories you explicitly authorize, used to read code and open draft pull requests.
Quantera scans code you already have — no agent, no runtime instrumentation installed in your systems. A repository is cloned fresh at scan time, either from a local path or through a GitHub App connection you authorize, pinned to a specific commit.
Static analysis (the Repository Scanner and Cryptographic Context Engine) runs against the cloned copy. Verification — builds, tests, rescans — runs separately, inside an isolated, ephemeral sandbox: containerized, non-root, read-only root filesystem.
Exact retention windows for cloned code and scan artifacts, and the specifics of any third-party model usage in the pipeline, are being finalized ahead of general availability. We'll publish the specifics here rather than leave this vague once they're locked.
Migration code is generated only for recipes explicitly approved by the policy engine — never freely by a model. Findings never include the raw content of embedded private keys, only their location and metadata.
AI assists in reading how a key is used — key establishment vs. signature vs. another role — from the surrounding application code. That classification feeds the recommendation; it doesn't decide it.
The mapping from a classified role to a specific algorithm — key establishment to ML-KEM, signatures to ML-DSA — comes from an explicit, approved recipe in the policy engine, not from a model's free-form judgment.
Structured outputs used downstream (findings, plans, migration metadata) are validated against a fixed schema before anything is acted on.
Generated code is verified with a real build, your existing tests, generated PQC tests, and a rescan — see the verification checklist. A confident-sounding explanation is not evidence.
Builds and tests never run against your live systems.
Each verification run gets its own container, discarded when the run completes.
Processes run without root privileges, against a read-only root filesystem.
Sandbox network access is limited to what a build actually requires, not open by default.
Sandbox environments don't inherit your organization's broader credentials or secrets.
Access is session-based and organization-scoped — one workspace cannot see another's repositories, findings, or migrations. Within a workspace, role-based permissions govern who can view findings, approve a migration, or manage connected repositories, so a viewer can't merge and a reviewer can't approve their own submission.
Read access to the repositories you explicitly authorize; write access is scoped to migration branches Quantera creates, never your default branch directly.
Quantera opens draft pull requests carrying the migration diff and its evidence package. It does not merge them.
Verification results are reported as check runs on the pull request, visible in the same place as your other CI checks.
Merge control stays with your engineers. Every migration Quantera proposes is a draft PR waiting on human review, not a change already applied.
Traffic to and from Quantera is encrypted with TLS. Stored credentials — including GitHub App tokens and any connection secrets — are encrypted at rest and are never displayed in full once saved.
Scans, findings, migration approvals, and verification runs are recorded against the user and workspace that triggered them. The same evidence your reviewers see attached to a draft pull request — build output, test results, rescan results, performance delta — is available to your admins after the fact, not just at review time.
We're standing up a dedicated security contact and a published security.txt. Until then, reach us at admin@quanteraai.io with "Security" in the subject line — we'll respond and route it directly to engineering.
Quantera is not yet SOC 2 certified. As we move design partners into production use, independent review is on our roadmap, and we'll update this page the moment that changes — not before. We'd rather you know exactly what's verified today than read a badge that isn't.
Talk to our team about your specific security requirements.