Your code is ephemeral. The architecture is what guarantees it.
Letting a reviewer read private code demands an explicit data-handling posture, not a paragraph buried in a terms PDF. Here is exactly what touches our servers, how long it stays, the GitHub scopes we ask for, and where our compliance work honestly stands — in progress, not yet certified.
Where we honestly stand.
We'd rather tell you exactly where we are than display a badge we haven't earned. These frameworks are actively in flight — work is underway, but none is complete. We update this page as each milestone lands.
SOC 2 Type 2
Audit underway against the Security, Availability, and Confidentiality criteria. Observation window is active; the Type 2 report is not yet issued.
ISO 27001
Building the ISMS — risk register, statement of applicability, and Annex A controls — toward a Stage 1/Stage 2 certification audit. Not yet certified.
GDPR
Aligning processing records, DPA terms, and subprocessor disclosures with GDPR. A signed Data Processing Addendum is available on request.
Status reflects in-flight programs only. None of the above is certified or attested today; we will not claim otherwise until a report is issued.
In, reviewed, gone.
Code is fetched, held in memory for the review, sent to a zero-retention model provider, and discarded. The only thing that persists is the review itself — in your GitHub, owned by you.
- →
GitHub PR
source of truth
- →
Sigilix API
TLS termination
- →
Review worker
memory only · ephemeral
- →
Model provider
zero-retention contract
Discarded
no code persisted
What protects your code at every layer.
The same evidence-first discipline that makes a review believable is the discipline that keeps your code safe. Each control below is true of how the hosted GitHub App actually runs today.
Ephemeral by design — and never training data.
Every review runs in an isolated, short-lived worker. Your code is fetched through a scoped GitHub token, held in memory only for the duration of the review, and discarded when it completes. We do not train models on your code, we do not vectorize your repositories into a shared store, and we do not retain logs containing file contents. The durable output — the verdict and findings — lives in your GitHub, owned by you.
Encrypted in transit and at rest.
All traffic to and between Sigilix services is TLS 1.2+. The limited operational state we do keep — aggregate telemetry, per-repo review memory, and evidence manifests — is encrypted at rest by the underlying platform. Code in flight is held only in worker memory and never written to durable storage.
One tenant never sees another.
Each installation is keyed to its own GitHub App credentials, and review state — index, code graph, trust ledger, and learned conventions — is partitioned per repository and per organization. Retrieval for one tenant's review can only draw on that tenant's own context.
Secrets are never logged or echoed back.
Sigilix scans diffs for leaked credentials as a first-class finding — so the product is built to recognize secrets. That same discipline applies inward: tokens and customer secrets are kept out of logs, never reflected in review output, and short-lived GitHub tokens are minted per installation rather than stored long-term.
Every claim carries a receipt.
Findings render a proof tier so you know what you're being asked to believe. Execution-backed checks produce receipts cryptographically bound to (repo, commit SHA, run id, attempt) with single-use enforcement — a receipt can't be replayed or forged. Security findings must cite deterministic evidence from a per-review manifest, not model assertion alone.
Least privilege, end to end.
Internal access to production follows least privilege with role-scoped credentials, and the GitHub App requests the narrowest set of scopes that lets it read a PR and post a review. Anything broader is opt-in and tied to a feature you explicitly enable.
The narrowest scopes that do the job.
Sigilix installs as a GitHub App and asks for the minimum permissions needed to read a pull request and post a review. The scopes we deliberately do not request matter as much as the ones we do.
Pull requests — read
Fetch the diff and PR metadata for the change under review.
Pull requests — write (reviews)
Post the verdict and inline findings as a single review.
Repository contents — read
Limited retrieval of the surrounding files a finding cites.
Checks / commit status
Read CI signals to triage a failing job against the diff.
Repository contents — write
We never write to your files. Not requested, not used.
Organization administration
Sigilix has no reason to read or modify org settings.
Where your code lives and runs.
Sigilix keeps a deliberately small footprint. Your code already lives in GitHub, and the review runs on our own infrastructure on Cloudflare — those are the only two providers in the path. Neither retains your file contents, we require zero-retention terms across our stack, and your code is never used to train a model. A current subprocessor list is available on request.
Where your code already lives. We read the pull request through a scoped, short-lived token and post the review back — we don't move your code anywhere new.
Our infrastructure — the API and the ephemeral workers that process the diff in memory and discard it. TLS in transit, encryption at rest, isolated per review.
Found an issue? Let us know.
Spotted a security issue or something that doesn't look right? Email us at support@sigilix.ai and we'll take a look. We read every report and get back to you quickly.
Security you can read, not take on faith.
The same posture that keeps your code ephemeral is the posture that makes a review believable. See the architecture behind it, or get hands-on.
Read how it works →