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 in depth.
• You can check the work yourself. Signed releases, a published sandbox layer and a security model specific enough to examine claim by claim are listed in section 2.
• The procurement pack is self-serve. Data Processing Agreement, subprocessor list, disclosure policy, and questionnaire answers on request - section 8.

2. Verifying Convira

Every claim on this page is tied to a mechanism you can examine. These are the materials a review can use directly:

• The operating-system confinement layer is published under Apache 2.0: the macOS, Linux and Windows sandbox code, the checks that decide whether a control is reported as enforced, and the test suite covering them. The mechanism can be read and run rather than taken on trust.
• Every desktop release is signed with Sigstore and ships with a CycloneDX bill of materials and a signed build-provenance statement, so you can confirm exactly what you installed. The commands are on the Security page.
• A published security model, specific enough to check claim by claim, 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.
• Team Hub encryption is built on OpenMLS, an open-source implementation of the IETF Messaging Layer Security standard (RFC 9420).

3. Where your data lives

Convira is a desktop-first product with three ways to run a task, and the data path differs 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. Inference runs on a server you host instead of the desktop machine, and a billed tool behaves exactly as it does on the local runtime. Two things differ from that runtime. The box tells us its address and its TLS fingerprints once, when you pair it, and we keep those in the clear so your teammates' devices can check they are connecting to the right machine; the box's own credential never reaches us in plaintext, because the installer prints a transfer code on the box's console and a workspace settings manager types it in, and each envelope we relay and store afterwards is sealed to one named device. And a task you arm to run while your computer is off is run by us on your behalf: our servers assemble that task's prompt and send it to your box, so that task's prompts and answers do pass through Convira. Tasks you start yourself never do.

The desktop app holds no vendor API keys for billed services. Those keys stay on our servers, so a lost or stolen laptop never exposes 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 the whole schema: it accounts for all thirty-eight hub tables, thirty-eight of which a route it drives actually writes - conversations, messages, reactions, attachments, shelf objects, read cursors, each person's own sealed list of pinned and archived conversations, per-device status envelopes, the per-scope key record, the eight MLS tables, the compliance identity and its audit log, conversation membership, the signed chain of who was added to or removed from a private group, 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, each person's own signed list of their computers, each computer's own signature agreeing that it is on that list, the published record of that list, the record of a person starting again with a new signing key, the signed record of somebody stopping that, 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, and the three that carry a history handover: the request a replacement computer makes for the conversations it cannot read, one row per conversation recording who was asked for it, and the sealed copy a teammate's computer hands back. That copy carries one readable first line, and it is addressing rather than content: which conversation it is for, which computer sealed it, which computer may open it, and how far back it reaches. We cannot open the copy, and we delete it after seven days whether anybody collects it or not. Its addressing line goes one day later.

Every workspace runs the Messaging Layer Security protocol, RFC 9420, using the OpenMLS implementation. The cipher suite combines a key agreement built to resist a future quantum computer (ML-KEM-768 together with X25519) with AES-256-GCM, SHA-384 and 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. A device that cannot establish which version a scope requires refuses to send rather than falling back to anything older. Our wrapper over the library deliberately contains no protocol logic of its own. Its correctness case includes a second, unrelated implementation of RFC 9420, which shares no code with ours and which reads every message our build puts on the wire, down to the last byte, and gets the same things out of it.

More of the specific claims, each with its mechanism:

• Conversation names and topics are encrypted, not columns. No hub route accepts a plaintext name or topic, which is why creating a conversation 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.
• Cloud voice is a choice, and so is a cloud catch-up. If you set voice typing or read aloud to cloud, what you dictate, or the text of the message you play, is sent to our voice provider to be processed. A catch-up - the short summary of what you missed in a conversation - runs on your own computer or your Private Box unless you pick a cloud model for it, and then the messages it reads go to our AI provider to be summarized. The app tells you before the first time any of the three runs, and you can switch the notice off; we store none of it on our servers, and the on-device engines in Settings send nothing anywhere. The finished catch-up is saved on the computer that asked for it and nowhere else, until you choose to send it into the conversation - and then it travels as an ordinary end-to-end encrypted message like anything else you write.

How messages are delivered, kept and removed:

• Deletion reaches every copy the app holds. Deleting a message replaces the copy on our servers and tells your teammates' devices to drop theirs: the app removes the text, the reactions and any file it had downloaded as soon as the deletion arrives. Backups hold only ciphertext. Our encrypted pre-deploy archives are deleted after thirty days, our database host keeps its own point-in-time recovery window, and because we hold no key for what either contains, a restore could only ever return a message to the devices in that workspace.
• What our servers keep to deliver messages. The workspace and conversation, sequence numbers, sizes and timestamps, plus which accounts are in each direct message or group and which of them run it. Message text, conversation names and file contents are sealed on your devices and are never readable by us.
• A new computer joins only with approval. Your app accepts a colleague's new computer only once one of that person's own computers has signed for it. If somebody has lost every computer they own, there are three ways back in, each announced to the whole workspace: a person who holds the workspace's 24 recovery words approves the new computer, a workspace owner or admin approves it, or the person starts again with a new signing key. That last route takes seven days, the workspace is told while it waits, and any computer of theirs that still works can stop it.

Convira cannot search, freeze or export a workspace's messages for anyone, ourselves included: our servers hold ciphertext and no key. A workspace's own people read, export and delete from their own devices.

Team Hub content is end-to-end encrypted. Cloud runs work differently by design: our API processes a cloud run's content in transit to the model provider and never stores it, as sections 3 and 4 describe.

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 sandbox rather than when the app opens. Convira confirms that the operating system's sandbox is available and puts the resource controls through a real run: a shell reports back the limits it inherited, a process group is stopped together with any background process it started, and on Linux an allocation above the cap is refused. On Windows, filesystem and network confinement are also exercised by launching a real confined process. Where a check does not pass, the capability report says so, and code the AI writes is refused rather than run without its sandbox.

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, so a researcher with a finding can always reach it directly.

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.