Qivreno Technical White Paper

Architecture, data governance, and security for reviewers

Version 1.1 · July 2026 · 272 Solutions LLC

This document is written for information governance officers, security teams, and IT administrators evaluating Qivreno for deployment. It describes what the product is, exactly where data lives, every network connection the software makes, the AI governance controls built into the workflow, and the threat model we designed against. Questions and audit requests: hello@qivreno.ai.

1. Executive summary

Qivreno is a desktop application (macOS today, Windows in development) that runs a team of up to 12 AI agents for small-business work: documents, spreadsheets, presentations, analysis, and coordination on a shared task board. The defining architectural choice is that Qivreno is local-first:

• The application, its agents, all task data, all documents, and all agent memory live on the customer’s own machine.
• The default AI backend is a bundled local language model that runs entirely on-device. In the default configuration, business content never leaves the computer.
• There is no Qivreno cloud account, no server-side copy of customer content, and no telemetry. Our servers see licensing metadata only.
• Cloud AI (Anthropic Claude, OpenAI Codex) is an explicit per-agent opt-in, configured by the customer using their own provider subscription.
• Every consequential AI action passes through human review gates built into the workflow.

2. Architecture overview

Qivreno is a Tauri application: a Rust core with a lightweight web-technology interface, compiled to a native app. There is no browser dependency and no hosted backend for product functionality.

Agents are role-configured workers (for example Sales Manager, Quality Engineer, Project Manager) that execute tasks one at a time from a shared kanban board with five columns: To Do, In Progress, Requires Input, Review, Done. Agents communicate with each other through a loopback-only HTTP bus bound to 127.0.0.1; nothing on the bus is reachable from the network. Conversation chains between agents are hop-limited to prevent runaway loops.

Two built-in assistants ship with the product: Qivvy, a project manager that decomposes large requests into delegated subtasks and integrates the results (it performs coordination only, never domain work), and the Concierge, a setup assistant that disables itself once onboarding is complete.

AI backends

If a cloud backend is unavailable, tasks automatically fall back to the best available local backend. The model files for the built-in engine are downloaded once from Hugging Face at setup; that download contains no customer data.

3. Data inventory and residency

All product data is stored in the user’s home directory on the local disk, under standard macOS per-user permissions:

Credential handling. The optional email integration stores the IMAP app password locally in settings.json, never transmitted to 272 Solutions. We recommend using a provider-issued app password (not the account password), enabling the sender allowlist, and full-disk encryption (FileVault), which we consider baseline for any business laptop. The optional Telegram integration stores the customer-created bot token the same way.

What 272 Solutions stores server-side (Cloudflare D1, licensing only): customer email address, Stripe customer/subscription identifiers, plan and seat count, activation code hashes, device identifiers with device names, and salted hashes of refresh tokens. No task content, no documents, no agent data, no email content, no calendar data. Ever.

4. Complete network egress map

An evaluator can verify this list with an outbound firewall (for example Little Snitch). In the default configuration, Qivreno makes exactly two kinds of outbound connections:

1. License refresh to qivreno.ai (HTTPS): sends the device’s refresh token and hardware identifier; receives a renewed signed license. Runs at most daily. Fails safe: a network failure leaves the cached license in place.
2. One-time model download from huggingface.co when the built-in AI is first enabled.

All other egress is opt-in and customer-configured:

There is no telemetry, no analytics SDK, no crash reporting, and no auto-update phone-home in the current release. Calendar integration runs through the local macOS Calendar application and generates no network traffic of its own.

5. AI governance controls

Qivreno is built on the assumption that AI output must be supervised. The controls are structural, not advisory:

• Review gate. Completed agent work lands in the Review column with a structured completion report (what was done, deliverables, key decisions, open items). A human moves it to Done.
• Requires Input gate. Agents that hit a decision they cannot make park the task and ask; nothing proceeds until a person answers.
• Email proposal gate. Emails never trigger work directly. An extraction pass proposes a task; a human approves or ignores every proposal.
• Permission tiers per agent. Agents default to a sandbox: file access is confined to their own working folder and the shared team folder, with path canonicalization to block traversal. Shell access exists only for agents the customer explicitly marks as full-access.
• AI content labeling. Agent chat replies and task results carry an “AI-generated, for reference only” notice, and the Terms of Service (accepted in-app before first use) make the review obligation explicit.
• Hop limits stop agent-to-agent conversations from continuing indefinitely without human involvement.

6. Prompt injection threat model

Any system that lets language models read outside content must assume that content is hostile. Qivreno’s mitigations, by channel:

Inbound email (highest exposure). The extraction model that reads email has no tools whatsoever; its only possible output is a JSON verdict, so instructions embedded in an email have nothing to act on. It is additionally instructed to treat the message as untrusted data. Whatever it proposes goes to the Requires Input column, where a human reads the proposal next to the sender and subject before anything runs. The executing agent, after approval, receives the email body explicitly framed as reference data. An optional sender allowlist narrows the attack surface further. Worst case under this design: a malicious email wastes a few seconds of the reviewer’s attention.

Web content. Agents can fetch pages for research. Fetched text can attempt injection; containment comes from the sandbox (no shell, no file access outside designated folders for default agents), the review gates on all output, and hop limits on delegation.

Remote channel. Telegram messages are accepted from exactly one chat id, paired through a code displayed only inside the app on the Mac. Messages from any other chat are rejected without processing.

Inter-agent traffic. Agents are identified on the local bus by unguessable tokens and cannot impersonate the operator.

7. Licensing and cryptography

Licenses are Ed25519-signed tokens verified offline against a public key embedded in the application; the product does not depend on our servers to run day to day. Purchases produce a single-use activation code (delivered on the checkout page and by email) which the app exchanges for a license bound to that machine’s hardware identifier plus a per-device refresh token. Renewal happens silently in the background; a lapsed subscription degrades gracefully through a grace period. Cancellations take effect at the end of the paid period, and issued licenses are clamped so they cannot outlive it. Server-side, refresh tokens are stored only as hashes; activation codes are single-use and atomically claimed.

8. Retention and deletion

• Local data belongs to the customer. Deleting the app data directory and ~/Qivreno removes all product data. Uninstalling the app does not silently retain anything elsewhere.
• Server-side licensing records are retained while a subscription is active and for a reasonable accounting period afterward. Customers may request deletion of licensing records at hello@qivreno.ai; we verify the request against the subscription email.
• We never train models on customer data. We have no access to it.

9. Subprocessors and third parties

10. Deployment recommendations

For managed environments we recommend: FileVault enforced; agents left at the default sandboxed permission unless a specific workflow needs shell access; email watching configured with an app password and a sender allowlist; cloud backends enabled only where the organization already has a data processing agreement with the provider; and outbound firewall rules scoped to the egress table in section 4.

11. Contact

Security reports, audit questions, and data requests: hello@qivreno.ai. We respond to security reports with priority.

This document describes Qivreno 1.1. We update it alongside material changes to the architecture.