Security

Threat model: BYOK vs managed keys

There are two distinct trust models, and they are not the same:

• BYOK (the default, recommended path)is zero-knowledge with respect to Zintus. Your keys live in your OS keychain (CLI / desktop / mobile) or encrypted in your browser, and the local gateway calls providers directly. Even when you use the optional cloud relay, it forwards opaque ciphertext encrypted to your home gateway's public key — the relay cannot read your keys or prompts.
• Managed keys are not currently available. The backend for a managed-keys tier has been removed and is, at most, a possible future option. If it is ever offered, it would not be zero-knowledge: operator-held keys are operator-decryptable, so anyone with worker-environment access could in principle read them. We will document that tradeoff plainly before any such tier ships. For now, use BYOK for all keys.

BYOK zero-knowledge architecture

• Local gateway binds to loopback (127.0.0.1) by default and refuses to start on a public interface unless a gateway token is set. With a token, every endpoint except /health requires a bearer token, compared in constant time.
• Keys at rest — OS keychain on CLI/desktop/mobile; on web, AES-256-GCM with a key derived from your passphrase via PBKDF2-HMAC-SHA256 at 600,000 iterations, stored as ciphertext in localStorage.
• Relay is ciphertext-only for BYOK — it never holds the plaintext key or the key that decrypts it.

Honest caveat: the web vault is convenience-grade. A successful XSS against the web app could exfiltrate the ciphertext, and a weak or captured passphrase could then expose keys. For high-value keys, prefer the desktop or CLI, which use the OS secure store.

What we have NOT done yet

• No SOC 2 (yet). We do not hold SOC 2, ISO 27001, or any third-party security certification. We will not claim certifications we do not have.
• Quota tracking is per-device; there is no shared global quota ledger.
• No multi-tenant authorization, audit logging, or per-key access control on the local gateway — it trusts its local keychain and is not a hardened multi-user server.

Reporting a vulnerability

Found something? Please report it privately rather than opening a public issue. Email security@zintus.ai (or open a private security advisory on the repository). Our machine-readable contact details follow RFC 9116 and are published at /.well-known/security.txt.

Response targets: we aim to acknowledge a report within [N — e.g. 3] business days and to give you an initial assessment and remediation timeline shortly after. Please give us a reasonable window to investigate and fix before public disclosure; we will keep you updated and credit you if you wish.

Safe harbor for good-faith research

We support good-faith security research. If you make a genuine, good-faith effort to comply with this policy during your research, we will:

• consider it authorized under the Computer Fraud and Abuse Act (and similar laws) and will not pursue or support legal action against you for it;
• consider it exempt from anti-circumvention claims under the DMCA, and waive any relevant restriction in our terms to the extent needed for your research;
• work with you to understand and resolve the issue promptly.

Good faith means: stay within scope, avoid privacy violations and service disruption, do not access or modify data that is not yours beyond what is needed to demonstrate the issue, and give us reasonable time to respond before disclosure. If in doubt, ask us at security@zintus.ai first. (Adapted from the disclose.io safe-harbor model.)

Full security model

The complete component-by-component threat model lives in SECURITY.md in the repository, including trust boundaries, gateway hardening options, and the full list of out-of-scope items.