Enterprise-grade isolation. On day one.

Every workspace is a tenant. Every tenant is on its own.

Data isolation is enforced at the database layer via row-level security policies on every table — not just checked in application code. A per-workspace encryption key derived via HKDF from a master root key means secrets stored in one workspace cannot be decrypted using another workspace's context. There is no shared token store, no shared context leaking across tenants.

• ●Row-level security policies on every table — enforced by Postgres, not by app code
• ●Envelope encryption per workspace — DEK derived via HKDF from a master root key
• ●AES-256-GCM for stored secrets — auth tag verified on every read
• ●Session-scoped workspace context — every query carries the workspace ID
• ●Belt-and-suspenders — is_workspace_member() check on every policy backs the session setting

Choose where your AI data flows.

On the default tier, LLM calls go through Ziel Lab's infrastructure. On BYOK, you connect your own Anthropic, OpenAI, or OpenRouter account — LLM data flows directly through your provider account and never touches ours. This is the model your procurement and compliance teams will actually approve. Same €899/mo either way.

• ●BYOK: connect your own model provider — AI data never touches our infrastructure
• ●Default tier: Ziel provisions the model — one bill, one vendor to manage
• ●Toggle per workspace in Settings — switch anytime without losing data
• ●Provider tokens envelope-encrypted with your workspace key — even we can't read them

Every AI call, every system write, logged with reason.

Ziel writes an audit-log row for every LLM call (model, tokens, cost, feature), every secret read, every CRM property write, every skill invocation, and every accepted proposal. The audit log is queryable per workspace and never truncated. Nothing Ziel does to your CRM is unaccountable.

• ●Per-workspace audit_log with row-level security — you see yours, nobody else's
• ●Every LLM generation traced end-to-end — inputs, outputs, tokens, cost, latency
• ●Every accepted proposal recorded with the rationale you agreed to
• ●Every system write (CRM property change, email draft, workflow update) audit-logged with source

Ziel respects your existing CRM roles.

When Ziel reads from HubSpot or writes to a Gmail draft, it does so under the OAuth grant of the connecting user — inheriting exactly the permissions that user has in the source system. A rep who cannot see Enterprise deals in HubSpot cannot see them through Ziel either. No permission escalation, no service-account backdoor.

• ●OAuth per user, per vendor — Ziel operates under your existing scopes
• ●No shared service account bypassing your CRM's RBAC
• ●Every write attributed to the initiating user in your CRM's own audit log
• ●Deauthorize a Ziel connection = immediate revocation of that user's Ziel access to that vendor

The specifics your security team asks for.

• ✕Sell, share, or train on your data. Full stop.
• ✕Store your customer data in a shared cross-tenant database. Every workspace has its own encryption boundary.
• ✕Escalate permissions beyond the user who authorized the connection.
• ✕Hide what the operator did. Every action is audit-logged with rationale.
• ✕Lock you in. Full state export in one click.