Security at Convira

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. What we can say is that the architecture is built so that the 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.

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: in automatic mode Convira uses it when the host supports it and logs a warning if it must fall back; operators can configure native isolation as required instead. The available primitives are:

• Linux: a Bubblewrap namespace jail (mount, PID, optionally network), with Landlock filesystem rules so the tool can only read and write the directories it was granted, and a seccomp-bpf syscall filter - the code-execution profile blocks the network syscalls outright, so a tool can't open its own sockets.
• macOS: a Seatbelt (sandbox-exec) profile with a deny-by-default posture.
• Windows: a Job Object that constrains the process tree and its resources. Filesystem and network decisions on Windows come from Convira's permission policy and network controls, not the Job Object.

Cloud code execution has a different boundary: it runs as a subprocess inside the API worker container. The container separates the service from its host, but cloud subprocesses share that container and do not receive a separate per-process filesystem jail or network namespace. Tool results expose isolation provenance so the agent and interface can distinguish container, native-process, and fallback execution.

Network egress. 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. On the local runtime web access is off until you turn it on, and the proxy can run in audit mode (log everything) or enforce mode (block and, optionally, ask you). 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 produces an approval 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, and workspace knowledge-base content - 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. 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 does not store third-party API keys or OAuth tokens on disk.

Private Box. A self-hosted Private Box is licensed with short-lived Ed25519-signed tokens. When you pair team members to a box, the box's bearer credential is sealed to each member's device key (X25519 key agreement + XChaCha20-Poly1305) - the plaintext credential never passes through Convira's servers.

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), database and backend hosting (Supabase), bot protection (Cloudflare), website hosting and cookieless analytics (Vercel), error monitoring (Sentry), and the AI model providers (Anthropic, OpenAI, Google, xAI). The current list, what each one does, and roughly where it operates is in the Privacy Policy.

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 you see something - 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 it.
• We'll credit you if you'd like once the issue is fixed. We don't run a paid bug-bounty program today.
• We won't pursue legal action against good-faith research that follows these guidelines.

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.