Security and privacy

This page is a summary for a privacy officer, a company’s IT person or a technical reviewer. The operator can hand over a fuller annex of technical and organisational measures (TOM) for a data processing agreement. Nothing here is legal advice.

Where data lives

• On the company’s own server. Chats, approval cards, the audit trail, schedules and decisions live in a Postgres 17 database in Docker on the same server, bound to the loopback interface only. Each install has its own two databases with their own logins.
• The search index is local. Weaviate runs in Docker on the server; embeddings are computed by a local model through Ollama. No cloud service builds or answers the index.
• Traces and errors are self-hosted. Langfuse and Bugsink run on the server. Private chats never reach the traces. Error reports pass the privacy gate and never carry request bodies, cookies, headers or query strings.
• Secrets are encrypted. Keys and passwords are stored in a secrets file encrypted with AES-256-GCM. Its key is kept outside the backup.
• Disk encryption is the server’s own disk encryption (FileVault on macOS).

What leaves the server

Text that a turn sends to a hosted AI model leaves the server and is processed by that model’s provider: the question, and the passages and memory lines added to it. A local model keeps even that on the server. The operator can route a folder or a skill to an EU-hosted model or a local one. Calls to connected apps and web searches also leave, after the privacy gate.

What can reach Zyx from outside

• The workspace listens on the server itself. Phones and laptops reach it over a private Tailscale network, not the open internet. Every page and API needs a person’s login or an API key.
• The operator may publish narrow public doors through Tailscale Funnel: signed webhooks, and optionally the MCP endpoint with its OAuth sign-in for remote AI tools. Every other path that arrives that way gets a 404.
• A webhook door caps the body at 1 MB, is rate-limited, and can check an HMAC signature.

Guards on every action

• The privacy gate, both ways. Every outgoing payload is checked: credentials are blocked, personal data bound for the open web asks first. Every result coming back is checked: credentials blocked everywhere, personal data redacted in results from the web and from outside apps, outside content marked as untrusted. A file Zyx opens itself has only its credentials blocked. See The kernel and approvals.
• Private paths. Zyx’s own state, the secrets file, .ssh and .env files are always refused.
• A sandbox for every command. Every shell command a model or a skill writes runs in a Docker sandbox, one per session, with nothing of the server and no credential in it.
• Human approval for sending mail and every risky change, with an undo answer for every action (a sent mail stays sent).
• Each person’s own rights on every search and answer. See Readers and rights.

Backups, proven by restore

After you set a backup folder, a nightly backup routine writes the state folder, the company folder and every Zyx table to a backup drive. Each run loads the database export into a scratch database and restores the files into a scratch folder before it marks the backup as done. Settings and the health check show the last checked backup. How to set it up: Backups.

Not in the backup, on purpose: the secrets key (kept apart, so a stolen backup does not open the stored passwords), the runtime’s run history and the search cache (both rebuilt).

GDPR in short

• Local processing on a machine the company controls, with the hosted-model exception above.
• Separation between people inside one company, tested on every API route.
• Erasure of a person is one command with a dry run first. It covers that person’s Zyx data, not arbitrary company files or copies already sent to a model provider.
• Fast deletion from search when an item is deleted in a connected app.
• Records: approvals and audit events record who decided what, and when.
• Works councils: connecting a company app such as Slack or Microsoft 365 widens what Zyx can read. Each item still reaches only its readers, and Slack direct messages are never read. Whether that counts as monitoring is for the owner, and a works council where one exists, to decide before it is switched on.

Honest limits

• One company per install. Zyx is not a multi-tenant system. Two companies means two installs.
• Not encrypted from the server’s administrator. “Private” means no Zyx screen, export or model turn shows it. Anyone with shell access to the server can read and change its files.
• No SOC 2 or ISO certification, no SLA, no managed failover. One server runs it; the service restarts itself after a crash.
• No single sign-on or SCIM.
• The privacy gate is not proof that nothing sensitive ever leaves. It blocks credential-shaped values and detects common personal data, but a bare name with no label is rarely caught outside web calls (web search, web fetch, the URLs the browser opens, and the Brave, Exa, Tavily, Perplexity and Firecrawl search tools), and the assembled prompt to the model is not passed through it as a whole.
• The sandbox’s network seal is a shell seal, not a kernel one.