The safest place for your work is the computer it is already on.

1. Our approach

Two principles shape everything below. First, local-first by default: on the local runtime the agent's inference, memory, and files run on your own machine, against models you host. The exception is a billed tool you choose to run - web and X research, image and video generation, connector actions - which needs managed provider keys we hold, so that single tool call is executed by Convira and returned to your device (and only while you are online). Second, the cloud is opt-in and minimal: when you use the cloud runtime, your run is executed and forwarded to the AI model provider, but the contents of the run are not stored on our servers - the record lives on your device. The one exception is a chat you choose to share when you rate an answer, which we keep for up to 90 days, or until you remove the rating. Less data on our side is less to protect, and less that can ever be exposed.

The result is an architecture built so that your most sensitive work never has to leave hardware you control.

2. Where your data lives

Convira has three runtimes, and they differ in exactly this way:

On the cloud path, run content - the text you typed, files involved, tool inputs and outputs, and the model's responses - is not written to our databases. Our code strips it before anything is persisted, and automated tests assert that invariant on every build. The detail is in the Privacy Policy.

Team Hub

Team Hub is not a fourth runtime - it runs no agent and produces no run record - but it is where a team's shared content lives on our servers, so it belongs beside the table rather than inside it. A team's messages, bulletins, shared files and conversation names are kept by us. One other kind of content can live there: if you turn on the optional cloud sync for skills and project knowledge, that text is stored on our side as ordinary database rows, as the encryption section below describes.

They are kept as ciphertext we cannot open. The keys come from each scope's own MLS group (RFC 9420, the OpenMLS implementation, with a quantum-safe cipher suite): every member device holds a leaf in that group and derives the epoch secret from it, and no Convira server holds a leaf or a key that opens a message, a bulletin, a conversation name or an attachment. Where a workspace has enrolled a recovery phrase, the reader that phrase derives is also a member of the shared group. Search runs on your device, because ours could not do it for you.

What our servers do see is what delivery needs: which workspace and conversation, a sequence number, an epoch, a content type, a size, a hash, which account uploaded it, and when. Four more are stored in the clear because the features that use them cannot work otherwise: which accounts are in a direct message or group, which of them run that group, that a named member reacted to a named message - never which emoji - and who has confirmed reading a bulletin that asked for confirmation, and when.

Deleting a message removes our copy and the copies on your teammates' devices, everywhere the app holds it. A new computer joins a workspace only once it has been approved: one of that person's own computers signs for it, or, if every computer they own is lost, somebody holding the workspace's 24 recovery words or a workspace owner or admin approves it, and everyone in the workspace is told.

3. How agent execution is isolated

Every desktop tool call is checked by Convira's permission policy. Native process isolation adds a second, independent layer of defense underneath it. The primitives it uses are:

• Linux: a bubblewrap namespace jail. The tool is given a fresh filesystem root holding only the directories it was granted, plus the read-only system paths it needs to start - anything else is not merely unreadable, it is absent. It gets its own process-id namespace, and a tool running without network access gets its own network namespace whose only device is loopback, so there is no route off the machine for it to open a socket on.
• macOS: a Seatbelt (sandbox-exec) profile with a deny-by-default posture.
• Windows: a fresh AppContainer per launch, created with no capability SIDs - which denies outbound network by default, and denies the filesystem by default, since a directory the tool was not granted carries no entry for that container's identity. A Job Object on the same process caps memory, processes and CPU.

Checked on your own computer. The first time a tool needs a sandbox, Convira confirms on your computer that the operating system's sandbox is available and puts its resource limits through a real run. Code the AI writes only ever runs inside that sandbox: if the sandbox cannot start, the code is refused rather than run without it. Every action records the isolation it actually ran under, and the app shows it to you.

Open source. The confinement layer described above is published under Apache 2.0 as convira-sandbox - the macOS Seatbelt profiles, the Linux bubblewrap namespace and mount arguments, the Windows AppContainer and Job Object code, and the checks that decide whether a control is reported as enforced. You can read exactly what those checks do, run the test suite yourself, and watch your own machine behave the way this page describes.

Cloud code execution has a different boundary: it runs inside a bubblewrap namespace sandbox within the API worker container - its own filesystem root, process-id namespace and network namespace. If that sandbox is unavailable on the host, the tool refuses to run rather than falling back to an unconfined process. Tool results expose isolation provenance so the agent and interface can see the isolation each call actually ran under.

Network egress. Most outbound network access from a run is mediated by an HTTP CONNECT proxy that enforces a layered domain allowlist (an explicit denylist, then anything you approved during the session, then your plan's and workspace's permitted domains, then a small built-in baseline of model and package endpoints). It also blocks direct-to-IP connections, private and link-local ranges, and cloud metadata endpoints. Web access on the local runtime defaults to the restricted tier, Offline Mode cuts the network entirely, and the proxy can run in audit mode (log everything) or enforce mode (block and, optionally, ask you).

Git over the network (cloning, fetching, pulling, pushing and opening pull requests) and installing your project's dependencies use their own tools, which connect directly rather than through the proxy. They follow Offline Mode rather than the Web Access switch, because pushing to your own repository is not browsing, and pushing or opening a pull request always asks you first.

When you do enable and invoke a billed web, media, or connector tool, that single call is routed to Convira to run with managed keys; everything else stays on your machine, and offline the billed tools are simply unavailable.

Approvals. A policy engine classifies what each tool action is about to do. Sensitive actions don't just happen - the run pauses and raises a request that you have to approve or reject before it proceeds. For some actions you can choose “allow for this session” or “always allow”; others always prompt. Your permission rules are authored on your device and applied to the run; on the cloud path they're sent with the run, not stored on our side.

4. Encryption

In transit. All traffic between the apps and our API runs over TLS, and our API connects to its database over TLS.

At rest. Our database is encrypted at rest. On top of that, certain sensitive stored values - for example the credentials and configuration for integrations you connect - are encrypted at the application level with AES-256-GCM, using per-purpose keys derived from a master key with HKDF-SHA256, with support for rotating that key. The extracted text of skills and project knowledge you choose to sync for cloud search is stored as ordinary database rows so retrieval can read it - covered by the database's at-rest encryption, not by that extra layer. There are no account passwords, so there is no password hash to hold. Session tokens, the one-time codes we email you, and similar secrets are stored only as hashes, are single-use where applicable, and expire. A passkey leaves only its public key with us, and a public key cannot sign anything. Third-party model-provider API keys are held in our server environment, not in the database.

On your device. The desktop app keeps the authoritative copy of your runs and sessions in a local SQLite database that is encrypted with SQLCipher. The encryption key is itself protected by your operating system's secure storage (Keychain on macOS, DPAPI on Windows, libsecret on Linux); a packaged build refuses to start if that protection isn't available rather than fall back to plaintext. The desktop app stores no model-provider API keys. The third-party credentials it does keep - your GitHub sign-in token, and the sign-in tokens and settings for MCP servers you connect - are stored encrypted under the same OS protection.

Private Box. A self-hosted Private Box is licensed with short-lived Ed25519-signed tokens. The box's transport credential never reaches Convira in a form Convira can read: the installer prints a transfer code on the box's own console, and a workspace settings manager types it into Convira on a machine that has already pinned that box. When you add team members, a desktop holding Manage settings seals a separate per-member key to each member's device key (X25519 key agreement + XChaCha20-Poly1305) and Convira relays and stores only that ciphertext; a second settings manager's envelope carries the transport credential itself, sealed the same way, because only a manager can reseal for the others. Convira holds no key that opens any of them. What Convira does keep in the clear is the box's address and its TLS fingerprints, so a teammate's device can check it is connecting to the right machine.

If your threat model requires run content to stay on hardware you control, use the local runtime or a Private Box, do not invoke managed online tools, and do not arm a task to run while your computer is off - an armed task is the one case where Convira's own servers assemble the prompt and send it to your box.

5. Authentication and access

Sessions are server-backed: the token in your browser cookie is matched against a stored hash, the cookie is HttpOnly, Secure in production, and SameSite=Lax, and sessions expire. Failed logins are rate-limited. The desktop app authenticates with short-lived, asymmetrically-signed (Ed25519) offline tokens that include anti-rollback protections so a backdated clock can't extend them. Cross-site request forgery is blocked with a double-submit token plus an origin check, compared in constant time.

You can add a passkey to your account - your fingerprint, your face, or a hardware key, held by the device in front of you. It signs you in with no code to wait for, and it is the strongest proof the account accepts, so it also answers the extra confirmation we ask for before a sensitive change. Convira stores only the passkey's public key, which cannot sign anything by itself. Your fingerprint and your face never leave your device: they are never sent to us and we never hold them.

Access to customer data inside Convira is role-scoped. Staff have platform roles (separate from any customer account) that determine what they can see and do; within a workspace, members have roles (owner, admin, operator, viewer) that gate what they can do there. Every privileged staff action is written to an append-only audit log with the actor, target, reason, and source. Support impersonation, when it's needed, is restricted to the highest staff role, requires a typed confirmation and a written reason, is time-limited, and is audit-logged. Development-only authentication shortcuts are hard-disabled in production builds.

6. Application hardening

Web. The API and website send standard hardening headers - HSTS (with preload on the marketing site), a Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Referrer-Policy, and a Permissions-Policy that disables camera, microphone, and geolocation. The API only accepts cross-origin requests from an explicit allowlist of our own origins. Public forms are protected by Cloudflare Turnstile and honeypot fields, and are rate-limited.

Desktop. The Electron app runs the UI with context isolation on, Node integration off, and the renderer sandbox enabled. The renderer talks to the rest of the app only through a narrow preload bridge whose messages are schema-validated, and it runs under a strict Content-Security-Policy (default-src 'self', no plugins, no framing, Trusted Types for script). Permission requests from web content are denied except for a short allowlist.

7. Signed builds and updates

Installers for macOS and Windows are code-signed - Apple notarization on macOS, Authenticode on Windows - and the desktop app's auto-updater verifies the signature on an update before installing it, so a tampered update is rejected. Auto-update checks respect the network policy: if a runtime is configured to be offline, the app doesn't phone the update server.

8. Monitoring and incident response

We use error-monitoring tooling on the API and web dashboard, configured to exclude authentication headers, cookies, and values that look like passwords, tokens, or secrets. Inbound webhooks (for example from Stripe) are signature-verified and de-duplicated to reject replays. We investigate security signals, and if there's a personal-data breach we will notify affected users and the relevant authorities within the timeframes the law requires.

9. Service providers

Convira relies on a small set of vetted service providers - payments (Stripe), hosting for the API, database, file storage and job queues (Amazon Web Services, in Frankfurt), bot protection (Cloudflare), website hosting and cookieless analytics (Vercel), error monitoring (Sentry), and the AI model providers (Anthropic, OpenAI, Google, xAI, Meta). The full current list, including search, email and connector infrastructure, with what each one does and where it operates, is on our subprocessors page.

10. Your part

Security is shared. A few things that matter:

• Add a passkey, and keep a lock on the device that holds it.
• Keep the app updated - it auto-updates, but don't sit on a months-old build.
• Be deliberate about what you connect and what you grant the agent permission to do; read the approval prompts.
• For your most sensitive work, use the local runtime or a Private Box, keep managed online tools off, and start those runs yourself rather than arming them, so run content stays on hardware you control.
• If something looks wrong - a bug, a suspicious email claiming to be us, an account you don't recognize - tell us.

11. Reporting a vulnerability

If you believe you've found a security vulnerability in Convira, please report it to security@convira.ai. Include enough detail to reproduce it - affected component or URL, steps, and impact - and, if you can, a proof of concept.

What we ask of you:

• Give us a reasonable window to investigate and fix the issue before disclosing it publicly.
• Don't access, modify, or delete data that isn't yours; use only test accounts and data you control.
• Don't run attacks that degrade the service for others (denial of service, spam, brute-forcing real accounts) or use social engineering against our staff or users.
• Don't demand payment in exchange for not disclosing.

What you can expect from us:

• We'll acknowledge your report and keep you updated as we work on it.
• Once the issue is fixed, we'll credit you if you'd like.
• We won't pursue legal action against good-faith research that follows these guidelines.

Our full vulnerability disclosure policy sets out the scope, the response times we commit to, and the safe-harbor terms for good-faith research.

12. Questions

Security questions, or anything about this page: security@convira.ai. For everything else, our help page. We'll update this page as the product and our practices change, and bump the date at the top.