Compliance

1. The short version

• Convira OÜ is an EU company. Estonian registry code 17268095, subject to the GDPR as home law, with database and API infrastructure hosted in the EU. Where data lives, per runtime, is described in section 3 and on the Security page.
• Our servers do not store the content of your runs. There is no plaintext transcript to subpoena, breach, or sell; the one message table that exists, Team Hub chat, holds only end-to-end encrypted ciphertext we cannot read. Section 4 explains the mechanism, not just the promise.
• Team collaboration content is encrypted end to end. The servers store ciphertext and hold no key that opens it. Section 5 walks through the cryptography and its honest limits.
• No certification yet, and we say so. Section 2 lists what we hold, what we do not, and what exists instead.
• The procurement pack is self-serve. Data Processing Agreement, subprocessor list, disclosure policy, and questionnaire answers on request - section 8.

2. Certifications, audits, and what exists instead

Convira does not yet hold SOC 2 or ISO 27001 certification, and no third-party audit of our cryptography has taken place. Customer accounts do not have SSO today; the second factor on accounts is an email code. We would rather state that than let a reviewer discover it, and the rest of this page exists precisely because a certificate is not yet available to stand in for it.

What exists instead, today:

• The operating-system confinement layer is published under Apache 2.0: the macOS, Linux and Windows sandbox code, the probes that decide whether a control is reported as enforced at all, and the test suite covering them. Publishing source does not establish what a signed installer contains - we do not produce reproducible builds - but it does mean the mechanism can be read and run rather than taken on trust.
• A published security model specific enough to be falsified, covering encryption, sandboxing, and the data-location model per runtime.
• A public vulnerability disclosure policy with response-time commitments and safe harbor for good-faith research, machine-discoverable via RFC 9116 security.txt.
• A self-serve Data Processing Agreement and a maintained subprocessor list with 30-day change notice.

As the company grows, certification follows customer demand: SOC 2 is the first planned engagement once deal flow justifies its cost, and this section will name the auditor and the window when that starts. We will not describe a plan as a credential in the meantime.

3. Where your data lives

Convira is a desktop-first product with three ways to run a task, and the honest data story differs per runtime, so we state it per runtime:

• Cloud runtime. The task's content is sent to our API and forwarded to the AI model provider to generate the response. It passes through our infrastructure in transit; section 4 covers what is and is not retained.
• Local runtime. Inference stays on this device. A connected billed tool sends only that tool's request to Convira for server-side execution. The tool's input is written by the model, so it can carry material from your conversation that the tool needs; the surrounding prompt, the model's response, and the rest of the run's content are not sent to us.
• Private Box. The same boundary as the local runtime, with inference on a server you host instead of the desktop machine.

Local and private therefore mean inference-local and inference-private, not “nothing ever leaves this machine” - the difference is exactly the billed tools you choose to invoke, and the product's own UI uses the same careful sentence this page does. The desktop app holds no vendor API keys for billed services; those live server-side, which is also why a stolen laptop does not leak them.

4. What our servers store, and what they never store

The strongest privacy claim we make about cloud runs is structural: our database schema has no table for run content. There is no prompt model and no transcript model; the only message table is Team Hub's, and every row in it is end-to-end encrypted ciphertext sealed on your devices. What the server keeps about a run is operational metadata - status, timestamps, runtime, model, durations, token and credit usage.

The mechanism is a single persistence boundary every run event passes through before it is written, which strips content fields against a denylist that covers prompts, responses, reasoning, search queries, URLs, file paths, commands, code, tool inputs and outputs, and email fields. The run's actual record lives on your device, in an encrypted local database. Where durable delivery of run events is needed, the envelopes are encrypted to the originating device's key before they touch our infrastructure, so what transits is unreadable to us.

The categories we do store, with retention periods, are listed in the Privacy Policy; the providers that touch each category are on the subprocessor list.

5. The collaboration cryptography, in depth

Team Hub, the collaboration layer in the desktop app, is end-to-end encrypted: our servers store ciphertext and hold no key that opens it. That claim is enforced in two directions in our own codebase. Structurally, the hub's server modules may not import a sealing primitive at all - a source-level check fails the build if one appears. Behaviorally, a red-team suite drives the real routes with real client-side sealing and asserts that no planted canary string reaches a column, an object in storage, or a live frame. That sweep observes the writes those routes make, and its scope is now the whole schema rather than the part somebody wired up: it accounts for all thirty-four hub tables, thirty-three of which a route it drives actually writes - channels, messages, reactions, attachments, board updates, board snapshots, shelf objects, read cursors, per-device status envelopes, the four key tables, the eight MLS tables, the compliance identity and its audit log, channel membership, bulletin acknowledgements, the per-scope envelope floor a downgrade would have to cross, the record of deleted and edited messages that lets a device catch up after time away, the workspace root with its sequence counter, each person's own signed statement that a device is theirs, the sealed handover that gives a replacement laptop the key it needs to make that statement, and the two that record a recovery group - how many of its members must act together, and who holds a share - neither of which can hold a share, because the shares never leave the device that made them. The thirty-fourth is a workspace-settings row that no code in our API creates or updates at all, so there is no write to observe, and the suite fails if that stops being true. It is our own evidence, not a third party's, and section 2 says so.

Every workspace runs the Messaging Layer Security protocol, RFC 9420, using the mls-rs implementation with cipher suite 1 (X25519 key agreement, AES-128-GCM, Ed25519 signatures). A scope's group is created at envelope version 2 and is never on anything older, so there is no rollout and no period during which a workspace is waiting for one. The earlier mechanism - content keys minted on a member's device and wrapped for each recipient device - is still compiled as an escape hatch and is not registered in a shipping build: no code path can select it, and a device that cannot establish which version a scope requires refuses to send rather than falling back to the older one. Our wrapper over mls-rs deliberately contains no protocol logic of its own, and its correctness case includes an interoperability suite that drives the same operations through an independent implementation of RFC 9420 sharing no code with mls-rs, asserting the two agree.

More of the specific claims, each with its mechanism:

• Channel names and topics are encrypted, not columns. No hub route accepts a plaintext name or topic, which is why creating a channel takes almost no parameters: there is nothing else the server is allowed to know.
• Search runs on your device. The index is a local full-text table over messages your device decrypted. The API has no search route, and could not answer one.
• Link previews are resolved by the sender before sealing. Reading a preview card is pure layout: no request is made, and the linked site observes nothing about the reader.
• Attachments are sealed on your device in slices, each slice its own signed envelope bound to its attachment, and our servers relay bytes they cannot read.

Three limits travel with those claims, because leaving them out would be the lie:

• Deletion's honest boundary. Deleting a message replaces the copy on our servers, so the cloud copy is genuinely removed, AND it tells your teammates' devices to drop theirs - the app removes the text, the reactions and any file it had downloaded when the deletion reaches it. What no deletion can reach is a copy that already left the app - an export, a screenshot, a file saved somewhere else - or a device that never comes back online. Both halves, always.
• Delivery metadata exists. The server sees workspace, channel, sequence numbers, sizes, and timestamps - that is how delivery works at all - and a direct message records which two accounts are in it, stored in the clear so we can deliver it, and nothing about what was said. We encrypt content; we do not claim the absence of metadata.
• The v1 trust anchor has a documented limit. A device accepts a forward key rotation on the server's word; a compromised server willing to claim one could substitute a key. The client refuses to do this quietly - the substitution surfaces a trust alert and discards prior out-of-band checks - and replacing the mechanism is what v2 is for, on the day a workspace is on it. We describe the alert rather than claim impossibility.

End-to-end encryption is a property of Team Hub, not of the product as a whole: a cloud run is executed by our API, which legitimately handles that run's content in transit, as section 3 describes.

6. Untrusted code and tool execution

An agent that executes code and browses the web needs containment, and the containment must fail closed. On Linux, untrusted execution runs inside bubblewrap namespaces: the process is given a fresh filesystem root that contains only the directories that run was granted plus the read-only system paths it needs to start, its own process-id namespace, and - where the run has no network access - its own network namespace whose only device is loopback, so there is no route off the machine to open a socket on. On macOS, generated Seatbelt profiles deny by default. On Windows, each launch gets its own AppContainer created with no capability SIDs, which is the only Windows primitive that denies outbound network and filesystem access by default rather than merely restricting writes; a Job Object on the same process supplies the memory, process and CPU ceilings. Cloud-side execution requires its sandbox to be available and refuses to run rather than falling back to a weaker boundary, and every execution result carries a provenance marker naming the isolation level it actually ran under, which the app shows.

A capability is only ever claimed while it is enforcing, and the checking happens the first time a tool needs a sandboxed process rather than when the app starts - an install that never runs a tool never probes anything. The resource controls are exercised for real: a shell reports back the limits it inherited, a process group is killed and the background child it forked has to die with it, and on Linux an allocation larger than the cap has to fail. Filesystem and network confinement are exercised that way on Windows only, by launching a real confined process against them; on macOS and Linux those two are taken from the presence of the operating system's own sandbox rather than attempted. Where a check does not pass, the capability report says so and the affected tool is withheld instead of running under a weaker boundary. Model-authored code has no degraded mode to fall into - it is refused outright. The exception is a short list of helpers Convira invokes itself and the model cannot author - git, archive extraction, OCR - which keep a narrower compatibility path if the deny-by-default sandbox will not load.

Outbound traffic from the API is brokered through an egress firewall in enforce mode, tool-facing fetches pass an SSRF validator that resolves DNS and rejects private address space, and skill content is signature-checked before it loads. The full model is on the Security page.

7. Reporting a vulnerability

The disclosure policy states scope, response times (2 business days to acknowledge, 5 to triage), fix windows, and safe harbor for good-faith research. It is named in our security.txt and reachable even while the rest of this site is behind the pre-launch gate, because a researcher with a finding should never be met by a marketing page.

8. The procurement pack

For a security review, everything is self-serve or one email away:

• Data Processing Agreement - applies automatically, printable, countersigned copy on request.
• Subprocessors - who processes what, kept in step with the Privacy Policy.
• Security page - the technical and organizational measures, which the DPA annexes rather than restates.
• Vulnerability disclosure policy - scope, response times, safe harbor.
• Security questionnaires. A completed CAIQ-Lite answer pack is available on request at security@convira.ai; custom questionnaires are answered within a few business days.

Anything this page does not answer: security@convira.ai.