ProductIntegrationsLive demoPricingLog in

Security and permissions

Version 1. Effective October 25, 2026.

What is implemented, what each source is asked for, and what we do not have yet. This page describes how Sondola, operated by Sondola Inc., works on the date above. It is a description of current practice. The binding commitments are in our Terms of Service and our Data Processing Addendum.

About the "In short" summaries. Sections marked In short are plain-English summaries. They do not change what this page or our agreements say.

In short. Your data is not sold or used to train AI. Sondola reads from your tools and does not change them, apart from two features we name. Workspaces are separated in the database itself. We do not have SOC 2 or a penetration test yet, and we say so.

1. What we do not do with your data

  • We do not sell it, rent it or give it to advertisers.
  • We do not train AI on it. Our contracts with AI providers prohibit them from training on what we send.
  • We do not use it for anything other than providing the Service to you and as you direct.
  • We do not change or delete your data in the tools you connect. Sondola reads. Section 3 names the two things that are not reads.

If the law requires us to disclose something, we will tell you before we do, unless the law forbids it.

2. Isolation

When we counted the live database on October 25, 2026, every table in Sondola's own schemas carried row-level security: 69 of 69 in the tenant schema and 37 of 37 in the control plane, across 63 policies. The 47 tables in the private schemas, spending lines among them, carry it too, and they are configured so that no signed-in or anonymous role can read them directly. All 48 views are configured to read as you rather than as the database owner, so that a view does not bypass a policy.

This isolation is designed so that one workspace cannot read another workspace's data, and it is checked by automated tests.

Functions that run with elevated rights have execute permission revoked from anonymous and signed-in roles alike, and a test in our build is designed to fail if a new one is exposed.

3. Credentials and permissions

Source credentials are held server-side and are designed never to be sent to the browser. The key your browser receives is a publishable key, which on its own is designed not to give access to any workspace data.

Spend works from the books, bank and cards you already connect. The OpenAI, Google Cloud billing and AWS costs connections, in beta, ask for read access to costs and usage. Each setup guide says exactly what it asks for.

We ask for read-only access wherever a provider offers it. Some providers only issue keys that could also write, and we use those only to read. Two things are not reads:

  • Google Cloud billing. Google Cloud also needs permission to run one query a day in your project to read your costs. Google may bill you for that query under your agreement with Google.
  • Slack digest. The Slack digest posts the messages you set up to the channel you choose.

4. The demo is protected from writes

The demo workspaces are protected by the database, not only by the interface. Row-level policies are designed to refuse a write aimed at a demo workspace, whoever sends it.

5. Changes to a number are recorded

When the Service changes a stored value, it records the old value, the new value and the reason in a restatement ledger instead of overwriting it. When we change how a number is calculated, the change is published on the corrections page.

6. Open Books: you can leave with your data

Any member can download the metrics they can see, and the owner can download the whole workspace, as one zip of CSV, JSON and Markdown. Every reading carries its source, collection time and run. A README lists a SHA-256 checksum for every file. The export is designed to exclude keys and tokens, and each download is logged in the workspace. After a workspace is cancelled, the owner can still sign in and download it until the deletion date.

7. Where it runs

Managed Postgres on Supabase, in AWS region us-west-1, encrypted at rest and in transit. Collector run logs are visible to us and are not visible to any customer workspace. Errors in the product are recorded by Sondola in the same database, with no field values, and with tokens and email addresses removed. We do not send them to an outside error-monitoring service. The full list of vendors is on our Subprocessors page at https://sondola.com/legal/subprocessors.

8. What we do not have

Sondola does not hold SOC 2 or ISO 27001 certification and has not completed a third-party penetration test. If your organisation requires these, review those requirements before connecting a source. No system is perfectly secure, and we do not claim otherwise.

9. Reporting a security issue

Email security@sondola.com. If we determine that a security incident has affected your data, we will tell your workspace administrators as our Data Processing Addendum at https://sondola.com/legal/dpa describes.

What changed

  • The page is now dated and versioned, and says that the Terms and the Data Processing Addendum hold the binding commitments.
  • Statements about isolation, credentials, the demo, exports and error logs now say what each control is designed to do, and isolation is described as checked by automated tests.
  • The read-only statement now names its two exceptions: the daily Google Cloud billing query, which Google may bill you for, and the Slack digest.
  • "Use it for anything other than showing it to you" now reads "providing the Service to you and as you direct".
  • The AI training statement now says that our contracts with AI providers prohibit training on what we send.
  • Plan and pricing claims were removed from this page. Prices are on the pricing page.
  • A section on reporting security issues was added.