Security
Architecture first. Certifications later.
We're early. There's no SOC 2 report to wave around yet. What we do have is an architecture that doesn't require trusting us, and six facts that are verifiable today.
Each pull request runs in its own microVM
Code analysis runs in Firecracker microVMs on Fly Machines. That's the same hardware-virtualization technology that backs AWS Lambda. Each pull request gets its own VM with its own kernel, memory and temporary storage, and the VM, with its working copy of your code, is destroyed when the analysis finishes. No shared state between reviews.
AI inference runs through Fireworks AI and OpenAI
Fireworks runs open-weight models for extraction and triage; it doesn't log or store prompts or outputs for them and is SOC 2 Type II certified. OpenAI runs GPT models for the in-depth review; it doesn't train on API data and may keep inputs and outputs for up to 30 days for abuse monitoring. Neither trains on your code.
Source stays scoped to the review
We store the diff hunks inside your review document so the IDE can render them back to you. That document is scoped to your organisation and lives in our database and its backups, kept for up to 30 days. No repository mirrors, no full files, no analytics copies.
EU-hosted control plane
Application data lives in France (OVH) and analysis runs in Frankfurt (Fly.io). AI inference runs in the United States (Fireworks, OpenAI) under data processing terms. We disclose every sub-processor we touch.
Hash-chained audit log
Comments, resolutions, review verdicts, membership and billing changes, and review pipeline events chain into a per-organisation SHA-256 log. Append-only, tamper-evident, exportable, and kept for as long as your plan's audit retention.
GDPR-aware by default
Per-organisation data isolation. Standard DPA available on request. Right to erasure is honoured: we can delete a review's data, or an entire organisation, on request.
Sub-processors
We publish a current list of every third party that processes customer data on our behalf, including their role, jurisdiction, and the legal mechanism that governs transfers outside the EEA. See /sub-processors. Customers are notified at least 30 days before we add or replace a sub-processor.
Vulnerability disclosure
If you believe you have found a security issue, mail security@acuvis.dev. Coordinates are also published at /.well-known/security.txt per RFC 9116. We acknowledge new reports within two business days and aim to triage with a target severity within five.
In scope: acuvis.dev, app.acuvis.dev, api.acuvis.dev and the Acuvis GitHub App. Test only against accounts, organisations and repositories you own; don't access, change or keep other people's data, and stop and report as soon as you reach data that isn't yours. Out of scope: denial of service, social engineering, physical attacks, and the infrastructure of our providers (report those to them). We will not pursue legal action against good-faith research that follows these rules, and we ask you to give us reasonable time to fix an issue before disclosing it.
Incident response
If a personal data breach affects customer data we process, we notify the affected customers without undue delay, and in any event within 48 hours of becoming aware of it, with what we know so far. Where we are the controller and the breach is likely to result in a risk to people's rights and freedoms, we notify the Polish supervisory authority (UODO) within 72 hours, in line with Art. 33 and 34 GDPR. For significant service incidents we email the owners of affected organisations and share a written summary once the incident is resolved.
Vendor assessments and DPA
Need a signed DPA, SCCs, or our vendor-assessment questionnaire? Visit /dpa or mail security@acuvis.dev and we will get back to you.