Security & trust
Kaso GTM holds your customer list, your mailbox history and your pipeline. This page states the GTM controls that exist today and names the ones that do not, so a security review can be done from it rather than around it.
Tenant isolation
Every workspace's data is separated in the database itself, not only in application code. The role the application connects as cannot bypass row-level security, so a query that forgets its workspace filter returns nothing rather than returning someone else's rows.
- Postgres row-level security is enabled on every table that carries a workspace id.
- The application's database role is not granted BYPASSRLS. Outside a workspace context a write fails and a read returns zero rows.
- A migration that runs last on every deploy fails the deploy if any table with a workspace id has no policy. It names the tables it found.
- Four tables are exempt by design and by name — sessions, auth tokens, subscriptions and inbound webhook events — because each is written before a workspace is known.
Encryption
Traffic is encrypted in transit. Credentials you connect — mailbox tokens, provider API keys — are additionally sealed before they reach the database, so a copy of the database is not a copy of your integrations.
- TLS on every connection, with HSTS set to two years including subdomains and submitted for preload.
- Connected credentials are sealed with AES-256-GCM using a unique initialisation vector per record and an authentication tag verified on every read.
- Sealed material carries the version of the key that sealed it, so keys can be rotated without a migration and without downtime.
- A secret is never rendered back to you. Settings screens show a four-character hint and nothing else.
- Secrets are excluded from logs, from audit rows and from error responses by a deny-list applied when the record is written, not when it is read.
Access, authentication and sessions
Who can do what is decided per workspace, and unusual sessions are detected rather than assumed away.
- Role-based permissions per workspace, with the workspace taken from the server session — never from a URL, a form field or anything else the browser can set.
- Session policies are per workspace: idle and absolute lifetimes, and whether concurrent sessions are allowed.
- Every audited action records the client IP address and the user agent, so a session that changes either one leaves a record an admin can read.
- SAML single sign-on and SCIM provisioning are plan entitlements — see the pricing page for which plans include them.
Audit trail
The record of who changed what is append-only. Nothing in the product updates or deletes an audit row after it is written.
- Every audited action records the actor, the entity, the field-level before-and-after, the client IP address and the user agent.
- Credential fields and message bodies are stripped on the way in. A redaction applied at read time is one query away from being bypassed; this one is not.
- Workspace administrators can read their own trail in the product. Audit log export is a plan entitlement.
Data retention and deletion
Retention is set per class of data rather than as one global switch, because an email body and a scoring trace do not deserve the same lifetime.
- Each retention class has its own window and its own mode — destroy the record, or strip it back to the fields that must survive.
- Deletion runs in batches with an explicit ceiling per pass, so a retention run cannot lock a table it is halfway through.
- Some fields are deliberately retained after a deletion for audit integrity; which ones, and why, is enumerated in the product.
- Provider payloads are kept alongside the normalised columns so an upstream schema change cannot destroy data already collected.
Application and browser hardening
The public site and the product are served with the same enforced policy.
- Content-Security-Policy is enforced, not report-only, with a per-request nonce and strict-dynamic. Inline script that is not the one nonced script does not execute.
- frame-ancestors 'none' with X-Frame-Options DENY as the legacy twin. Kaso GTM cannot be framed.
- X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, a deny-by-default Permissions-Policy, and Cross-Origin-Opener-Policy.
- Unauthenticated endpoints — this site's demo and disclosure forms included — carry their own IP rate limits and hard field-length caps.
What we do not claim
A trust page is only useful if the absences are on it too. As of the date below, all of the following are true:
- Kaso GTM does not currently hold a SOC 2 Type I or Type II attestation.
- Kaso GTM does not currently hold ISO 27001 certification.
- Kaso GTM is not currently offered under a HIPAA business associate agreement.
- There is no published third-party penetration test report at this time.
- There is no contractual uptime SLA on the published plans. Enterprise terms are negotiated.
If a security questionnaire needs something not answered here, use our security inquiry and disclosure form and we will answer it directly rather than pointing at a badge.
Reporting a vulnerability
Researchers acting in good faith under this policy have safe harbour: we will not pursue legal action, and if a third party does, we will make that authorisation known.
- In scope
- Kaso website, Kaso GTM app, Kaso GTM API
- Acknowledgement
- Within 5 business days
- Disclosure window
- 90 days from report, coordinated for critical issues
- Rewards
- No monetary bounty; public credit with your consent
- Out of scope
- Third-party services, social engineering, physical attacks, denial of service, scanner output without demonstrated impact