Security at Avocet CRM
Avocet CRM enforces tenant isolation in PostgreSQL with row-level security, not only in application code; encrypts OAuth tokens and API credentials at rest with versioned keys; sends a model provider the minimum span of text needed for one task under zero-retention terms; and is not yet SOC 2 certified — which we would rather tell you here than in call three.
How is one customer’s data kept separate from another’s?
By PostgreSQL row-level security, enforced by the database on every query, with server-side authorisation in the application as a second and independent layer. A query that forgets to filter by organisation returns nothing rather than returning someone else’s rows.
Policies resolve membership through a single security-definer function, so there is one definition of "which organisations may this user see" rather than one per table.
The isolation is a test, not a claim: continuous integration asserts at the SQL level that a member of one organisation receives zero rows for another, that a client-supplied organisation id for a non-member organisation is rejected, and that a read-only role’s attempted write changes nothing. A build that breaks any of those does not merge.
How quickly does revoking someone’s access take effect?
On their next request. Organisation membership is deliberately not stored in the access token, so there is no window during which a suspended member keeps working until their token expires.
The active organisation is resolved from the URL and re-verified against the membership table on every request. That costs one indexed lookup and removes an entire class of "we removed them an hour ago" incident.
How are OAuth tokens and API credentials stored?
Encrypted before they are written, using a key held only in the server environment, with a key version stored alongside each value so that rotating the key never requires rewriting historical data. They are never logged and never returned by any API.
Secrets are also never sent to a client bundle. The environment is validated by schema at build time, and the module that reads server secrets throws if it is ever imported into browser code.
What exactly gets sent to a model provider?
The minimum span of text needed for one specific task, and nothing else. A deal-health verdict receives that deal’s fields and the recent messages on that thread — not your mailbox, not your database, not other customers’ data.
Model providers are contracted for zero retention and no training on your content, are named individually in our subprocessor list, and per-organisation opt-out is documented. We will not send a new category of customer data to a provider without those three things being true first.
Every AI output is stored with its confidence, its reason, its evidence, the source reference, the model used, and the token cost — so you can audit what was asked and what came back.
What Gmail permissions does Avocet CRM request?
Read-only. Avocet CRM never sends, modifies or deletes mail. Reading message bodies is a restricted Google OAuth scope, which means Google requires app verification and an independent third-party security assessment before general availability — we are in that process rather than around it.
Sending email on your behalf is a high-risk action in our own model and always requires an explicit human approval, regardless of what a scope would permit.
Is there an audit log, and what is in it?
Yes, and it is append-only at the database grant level, not merely by convention — a compromised session cannot forge or erase an entry. Every privileged write records its actor in the same transaction as the change, so a mutation without its audit row is not a state the database can reach.
Entries record who, what, which resource, when, and the request’s IP and user agent. They record identifiers and enumerated values only — never a message body, a document, a token, or free-text customer content.
Are you SOC 2 certified?
Not yet. We are targeting a Type II report at around ten customers, and we would rather say that plainly here than let you discover it on call three. What exists today is this page, a DPA, a named subprocessor list, and honest answers to your questionnaire.
If a SOC 2 report is a hard procurement gate for you today, we are the wrong vendor this quarter and we will say so rather than waste your evaluation cycle.
Are development and production separated?
They are separate database projects with separate credentials, not one project with three sets of keys. A production secret never exists in a development environment.
How do I report a vulnerability?
Email security@tryavocet.com. We acknowledge within one business day, and we will not threaten a researcher who acted in good faith.
What this page deliberately does not claim
No SOC 2 report today. No enterprise SSO with SAML or SCIM today. No on-premises or single-tenant deployment, and none planned. Penetration testing is scheduled rather than complete. We list these because a security page that only contains good news tells a reviewer nothing except that it was written by marketing.