Trust Center

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 message or transcript table to subpoena, breach, or sell. 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:

• 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 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 message model, no prompt model, no transcript model. 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 ever appears in any hub table, storage object, or live frame. That suite is our own evidence, not a third party's, and section 2 says so.

Content keys are minted on a member's device and wrapped for each recipient device (the v1 mechanism live today). The group-key machinery is moving to the Messaging Layer Security protocol, RFC 9420, using the mls-rs implementation with cipher suite 1 (X25519 key agreement, AES-128-GCM, Ed25519 signatures); the MLS path ships in the product and is being rolled out as v2 of the hub's cryptography. 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 a teammate who already read it keeps their local copy, which this system cannot reach. 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 row discloses that a pair converse. 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 the MLS-based v2 replaces the mechanism. 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 hardened with kernel-level Landlock rules and a seccomp filter that blocks mount, ptrace, module-loading, and similar escape surfaces. On macOS, generated Seatbelt profiles deny by default. On Windows, untrusted code execution is currently disabled rather than shipped without an equivalent boundary - the honest option between the two. 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.

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, including the injection-screening layers in front of the agent, 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.