Security

Last updated: 1 January 2026

You are about to give CazoTask access to your inbox, your calendar and your client conversations. That deserves a straight description of how we protect it, not a page of badges. Here is what we actually do, and where the honest limits are.

Encryption

Everything in transit uses TLS 1.2 or higher, with HSTS enforced on our domains and modern cipher suites only. Everything at rest — the application database, object storage and backups — is encrypted with AES-256 using managed keys.

Credentials for your connected tools get a second layer. Each OAuth token is encrypted individually with AES-256-GCM before it is written, under a key held in our deployment secret store that the database has no access to. Because the cipher is authenticated, a token that has been altered in storage fails to decrypt rather than being used. Tokens are decrypted in memory only for the length of a run, are never written to logs, and a dump of the database on its own would not yield usable credentials. This is a single-key scheme rather than a key hierarchy with per-record data keys; we will say so here if that changes.

Connections and scope minimisation

Every integration uses OAuth. We never ask for and never store your password to a third-party service. We request the narrowest scope set the automation you selected genuinely needs — an inbox triage automation that only reads and drafts does not get send-on-your-behalf permission — and the consent screen lists each scope in plain English before you approve it.

You can revoke a connection from Settings → Connections at any time. Revocation destroys the stored tokens immediately, calls the provider's revoke endpoint where one exists, and pauses every automation that depended on it.

AI provider handling

Automation steps that classify, summarise or draft send content to a third-party AI provider over an encrypted connection. We use those providers under API terms that prohibit training on submitted data. Your content is not used to train our models or any public model. We send the smallest slice of content the step needs rather than the whole account, and we do not use one customer's data to produce another customer's results. Providers retain a short abuse-monitoring window as their terms require, after which the data is deleted on their side.

Approval controls

The strongest safety control on the platform is one you set. Every automation has an approval line: actions below it run silently, actions above it queue for your explicit confirmation. Client-facing email, payments and anything that makes a commitment default to requiring approval. You can move the line in either direction per automation, and every approval and rejection is recorded in the audit log.

Tenant isolation and access control

Customer data is logically isolated. Row-level security in the database ties every record to an owning account, and API routes authorise on the session rather than trusting a client-side identifier. Automation runs execute in isolated workers with only the credentials for the account that owns the run.

Internally we operate on least privilege. Production access is limited to a small number of engineers, requires SSO with mandatory multi-factor authentication and a hardware key, and is logged. Nobody reads customer content routinely; access to production data happens only when you ask us to debug something, or during a live incident, and it is recorded either way. Development and staging environments never contain real customer content.

Infrastructure

We run on managed cloud platforms whose data centres hold SOC 2 Type II and ISO 27001 certifications. Our application and database currently run in a single United States region. Backups are encrypted and taken by our database provider on their standard schedule; they roll off within 35 days, which is why deleted data can take up to 35 days to disappear from every copy rather than vanishing instantly.

Secure development

• Secrets live in a managed secret store, never in the repository.
• Changes are reviewed before release, and the production build is verified on every deploy.
• We track advisories against our dependencies and patch high and critical severity issues promptly.
• We have not yet commissioned an independent penetration test. When we do, we will say so here and date it.

Monitoring and incident response

We monitor application and infrastructure telemetry with alerting on anomalies — unusual authentication patterns, spikes in failed runs, unexpected data egress. We maintain a written incident response plan with defined roles and severity levels. If a security incident affects your data, we will notify you without undue delay and in any case within 72 hours of becoming aware, tell you what happened, what data was involved and what we are doing about it, and follow up with a post-incident review.

Compliance posture

We process personal data in line with applicable US state privacy laws including the CCPA/CPRA, and with the UK and EU GDPR where they apply to you. We will sign a data processing agreement on request. On certification status, plainly: we hold no SOC 2 or ISO 27001 attestation of our own. Our infrastructure providers hold theirs, which is not the same thing, and we will not imply otherwise. If you need documentation for a vendor review, email us and we will send exactly what we have.

Your part

• Use a strong, unique password or the magic-link sign-in.
• Review the scopes on the consent screen before approving a connection.
• Keep approvals on for anything that leaves your organisation.
• Remove seats promptly when someone leaves your team.
• Disconnect tools you no longer use.

Reporting a vulnerability

If you have found a security issue, email security@cazotaskai.com with enough detail to reproduce it. We acknowledge within one business day, keep you updated, and will not pursue legal action against good-faith research that avoids privacy violations, data destruction and service disruption. We are happy to credit you publicly once a fix has shipped.