Security

A summary of the boundaries Halo's code is written to hold. It has not yet been independently audited.

What Halo protects

Your vault (logins, cards without security codes, notes, aliases, one-time code seeds, SSH hosts and private keys), bookmarks, history, open tabs and settings; your account key and recovery key; session tokens and the local MCP token; and the browser's cookies and site data.

Accounts and keys

• There is no password. You sign in with a 6-digit code sent to your email, or with Google. Codes expire after 10 minutes, are stored only as hashes and are rate limited. One email address is one account, whichever way it signs in.
• The server stores your email, your name, your X25519 public key and the matching private key encrypted with the account key, the recovery key verifier and the account key encrypted with the recovery key, device names and public keys, pending device approvals, hashed session tokens and, if you use Google, your Google account ID.
• A random 32-byte account key encrypts every synced record with XChaCha20-Poly1305 on your device. The server rejects plaintext.
• The account key never reaches Synquic. Each signed-in device keeps it in the system keychain (macOS Keychain or Windows DPAPI), so Halo opens without typing anything.
• A new device gets the account key in one of two ways. A device that is already signed in approves it: both screens show the same 6-digit code to compare, and the key is sealed to the new device's X25519 public key, so the server only relays a box it cannot open. Or you enter the recovery key, which opens the encrypted copy of the account key kept on the server.
• Accounts made before passwordless sign-in with a master password can still open a new device with that password. For unknown emails, the server returns a deterministic fake salt, so it does not reveal whether an account exists.
• The recovery key is 32 random bytes shown once at sign-up. The server keeps only a verifier derived from it and the account key encrypted under a key derived from it. If you lose every device and the recovery key, the encrypted data cannot be recovered. Synquic cannot reset it.
• Protect your email account. Someone who gets into it can sign in with a code, but a new device still needs approval from a signed-in device or the recovery key, so they cannot read your data on their own. They could delete the account or replace the recovery key.

Sessions

• Access tokens are valid for 15 minutes. Refresh tokens are random, stored hashed and rotated on every use; reusing an old refresh token revokes the whole session family.
• Sign-in and recovery are rate limited per email and per IP address.
• On your device, tokens live only in Halo's main process, and the refresh token is encrypted with the system keychain (macOS Keychain or Windows DPAPI). The interface never sees a token.
• Lock and auto-lock use Touch ID on Macs that have it.

Autofill

• Pages never see the vault. The Halo menu in sign-in fields runs in an isolated world, and Halo's main process brokers every request.
• A password is filled only into the top frame of a page whose host equals the saved site's host, only after you pick the login, and never on a tab an AI agent controls.

AI agents and Halo AI

• The MCP server listens on 127.0.0.1 only and requires a 32-byte bearer token stored in your profile. Halo's own window, which holds the decrypted vault, is not reachable through MCP; tools act only on web tabs.
• Sign-ins requested by an agent need your approval, and the password is never returned to the agent.
• Halo AI runs on your computer. Its download is checked against a pinned SHA-256 hash, and page text is passed to it as untrusted data.
• Halo AI asks you before clicks that pay, order, send, post or delete, refuses to type into password, card and one-time-code fields, and cannot run its own script in pages.
• Halo Cloud requests go through Synquic's server with your session; the model key stays on the server, requests are size- and rate-limited, and their content is not logged.

SSH

• Hosts and keys are vault items, encrypted and synced like passwords. Credentials are handed to the SSH client for one connection and not written to disk by it.
• Host keys are trusted on first use and pinned per host; a changed key blocks the connection until you explicitly trust it.

Private and Tor windows

• Each private window uses in-memory sessions only; storage is cleared when it closes and permissions are never remembered.
• Tor windows route all page traffic, including DNS, through a local Tor process, and disable non-proxied UDP so WebRTC cannot leak addresses. Halo verifies the Tor download's PGP signature against the pinned Tor Browser signing key, then its SHA-256.

App hardening

• Web pages run in sandboxed, context-isolated renderers with no system access. Only Halo's own interface has the preload bridge, and its handler accepts calls only from Halo windows.
• Packaged builds refuse debugging and code-injection flags, load app code only from Halo's own app archive, and encrypt cookies with the system keychain.
• Remote debugging is available only in development builds.

Servers

In production the sync service runs behind a TLS-terminating proxy. It sends HSTS and nosniff on every response and no-store on API responses.

Known limits

• No independent security audit or penetration test has been done yet.
• The installers are not yet code-signed with Apple and Windows certificates.
• Shields and Global Privacy Control do not yet apply in private and Tor windows.

Report a vulnerability

Email support@synquic.com. Please include steps to reproduce and give us time to fix the issue before you disclose it.