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. Less data on our side is less to protect, and less that can ever be exposed.

We don't claim to be unbreakable. We can say that the architecture is 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, boards, shared files and channel 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. Content keys are created on member devices and wrapped for each teammate's device; no Convira server holds a key that opens a message, a board update, a channel name or an attachment. 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 channel, a sequence number, an epoch, a content type, a size, a hash, which account uploaded it, and when. Three more are stored in the clear because the features that use them cannot work otherwise: which two accounts are in a direct message, 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.

Three limits, stated rather than implied. Deleting a message removes our copy and the copies on your teammates' devices; what it cannot reach is a copy that has already left the app, an export or a screenshot. A direct message records which two accounts are in it - we store that in the clear so we can deliver it, and nothing about what was said. And on the current key format a device accepts a forward key rotation on our word - if that ever happened, the app raises a trust alert and stops treating the identity as verified, rather than accepting the new key quietly.

3. How agent execution is isolated

Desktop tool calls are always checked by Convira's permission policy. Native process isolation is a separate defense-in-depth layer, applied whenever the host provides 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.

We check most of this on your machine, and name the part we do not. The first time a tool needs a sandboxed process, Convira runs the resource controls on your real machine - a shell reports back the limits it inherited, a real 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 while a smaller one under a generous cap succeeds - and a control whose check does not pass is reported as absent for the rest of that session. Filesystem and network confinement are checked the same way on Windows, 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 exercised. Where a tool needs isolation the host cannot give it, the tool is withheld rather than run without it: model-authored code is refused outright rather than run unconfined. 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 on your machine.

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 probes that decide whether a control is reported as enforced at all. Publishing source does not prove that the build you installed contains it; what it gives you is the ability to read what these checks do, run the test suite yourself, and watch your own machine to see whether it behaves this way.

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 and you can turn it off entirely, and the proxy can run in audit mode (log everything) or enforce mode (block and, optionally, ask you).

Two things do not go through it, and we would rather name them than let the paragraph above cover them. Git over the network - cloning, fetching, pulling, pushing, opening a pull request - and installing your project's dependencies run their own tools, which connect directly: no proxy, no domain allowlist. They are governed by Offline Mode rather than by the Web Access switch, because pushing to your own repository is not browsing. Convira signs in only to github.com, but git itself accepts any https address it is pointed at, so a repository you have not read can name a host we do not check. Pushing and opening a pull request ask you before they run.

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. Passwords are never stored or encrypted in a reversible form - they're hashed with Argon2id (a modern, memory-hard algorithm). Session tokens, email-verification codes, password-reset tokens, and similar secrets are stored only as hashes, are single-use where applicable, and expire. 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. During the one-time pairing the box sends its bearer credential to Convira over TLS; Convira seals it to your device key in memory (X25519 key agreement + XChaCha20-Poly1305) and stores only ciphertext. When you add team members, your own desktop reseals that credential to each member's device key, so those deliveries never expose the plaintext to Convira.

If your threat model requires run content to stay on hardware you control, use the local runtime or a Private Box and do not invoke managed online tools.

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.

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), API hosting (Railway), database (Supabase), bot protection (Cloudflare), website hosting and cookieless analytics (Vercel), error monitoring (Sentry), and the AI model providers (Anthropic, OpenAI, Google, xAI). The full current list - including search, email, queue and connector infrastructure - what each one does, and roughly where it operates is on our subprocessors page.

10. Your part

Security is shared. A few things that matter:

• Use a strong, unique password for your Convira account.
• 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 and keep managed online tools off 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 don't run a paid bug-bounty program today.
• 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.