Security and privacy

CruzClaw’s security model has one organizing idea: your employees act for you, but they cannot commit you without you. This page describes what the product actually enforces today, what your AI employees can and cannot send without your approval, and, just as plainly, the areas we are still hardening.

What the product guarantees

Approvals before risky sends

Any outward action that touches someone outside your account can be held for your approval. When something needs your sign-off, it lands in the dashboard as an approval request showing the exact payload (the precise message or action, and the exact recipient). Approving dispatches exactly what you approved, nothing more. Rejecting stops it.

Approval isn’t a loose “yes, go ahead.” Each approval is bound to the specific payload and recipient it was granted for, and dispatch of an approved item is authorized by a per-approval credential tied to that binding. The platform’s signing material alone cannot authorize any send: a leaked key is not a bypass.

Every external send is screened

Before anything leaves your account to an external recipient, it passes a deterministic disclosure screen. The screen checks, among other things, for:

• Owner-briefing leaks: content that reveals your private briefings, instructions, or internal context.
• Commercial and financial signals: sensitive business or financial information.
• Health data: health-related information about anyone.
• Third-party contact mentions: references to people who have not authorized disclosure.

Denials are not all-or-nothing. Some categories route to you as an approval request instead of being blocked outright (see recipient trust checks). Two categories are hard denials on every channel, with no approval override: owner-briefing leaks and health data. Neither you nor any compromised component can push those through an approval.

Inbound mail fails closed

Messages arriving from outside your account are treated as unverified by default. If the inbound checks can’t confirm who a message is from (because the sender is unknown, the check errors, or it times out) the sender receives only a neutral receipt, and nothing from the message is acted on or exposed to your employee. A sender proves identity through the provider’s own authentication (for example, a verified email channel), not by claiming a name.

Recipient trust checks

Disclosing protected data to an external recipient requires both provider-authenticated identity and explicit authorization for that recipient. Each of your contacts carries grant settings that decide what your employees may share with them: whether they’re verified, what classes of information are allowed, which projects they’re authorized for, what data types are permitted, and whether their data still needs your case-by-case approval. A recipient without the right grant simply doesn’t receive protected content, even if your employee is otherwise authorized to send it.

How denials behave depends on the channel:

• Email: an unverified or unauthorized email correspondent can’t be pre-registered for every situation, so the send is queued as a durable approval request. You review the exact payload and recipient; approving sends exactly that.
• WhatsApp: the channel works from an explicit allowlist. A sender with no contact record is denied outright: there is no override path.

Per-employee isolation

Each employee runs in its own isolated deployment with its own storage, and the platform enforces one active employee per deployment at the data layer. An employee’s channel connections and credentials are scoped to that employee alone, and an employee cannot act through another employee’s channels. Your employees’ data and access do not blur into each other, and removing an employee removes its deployment with it.

Deterministic commands, not vibes

Owner commands on chat surfaces are matched against an explicit command table by a deterministic parser: an employee can’t be talked into “interpreting” a message as a command it isn’t. The command surfaces are also deliberately limited: Slack and dashboard chat can change things; WhatsApp is read-only; email is not a command surface at all.

What your AI employees cannot send without you

Putting it together, without your explicit approval your employees cannot:

• Send protected data to a recipient whose grants don’t allow it.
• Reveal your private briefings, instructions, or internal context to anyone: this is never approval-grantable.
• Share anyone’s health data: also never approval-grantable.
• Treat an unverified inbound sender as trustworthy and act on their message.

And even with your approval, an employee can only send the exact payload to the exact recipient you approved: the approval doesn’t generalize.

What we don’t claim yet

We’d rather tell you plainly than overstate:

• Container hardening and vulnerability patching: the per-employee isolation above is real, but we do not yet publish hardening baselines or patching SLAs. Work is in progress.
• Backups and disaster recovery: we do not yet claim backup coverage or recovery objectives for employee data. Work is in progress.
• Desktop and mobile app update integrity: update-delivery guarantees for the desktop and mobile apps are not yet shipped, so this page makes no claims that depend on them.

Each of these is an active workstream. This page will be updated as the guarantees land.

Last verified: 2026-10-24 against the shipped codebase.