Security and data handling

Separation between customers

Every customer gets their own database.

Not a shared table with a customer column. A separate Postgres database per customer, on the same managed instance, with the same schema. Which database a request opens is decided by the customer identifier inside the signed token, and nothing else.

The shared-table controls are still on underneath.

Every table also carries a tenant identifier and a row-level security policy that checks it, enforced by the database rather than by application code. Separate databases make that redundant, which is the point: it is a second wall behind the first, so a routing mistake reaches nothing rather than reaching everything.

The isolation is proven by a test suite, not asserted.

An automated suite walks the database catalogue, opens a session carrying one customer's credentials, and checks that every table returns nothing from another customer's data. It walks the catalogue rather than a list, so a new table that forgets its policy fails the build rather than shipping quietly.

What Kelpie reads

Email and calendar, from the mailboxes you connect.

Nothing else. No chat, no CRM, no support desk, no browsing. Where your customers also talk to you somewhere Kelpie cannot see, you tell it so at onboarding and it says so rather than reading silence as disengagement.

Only the calendars the account owner owns.

A connected mailbox can usually read every calendar shared with it. Kelpie ingests only the ones that person owns, so a colleague's meetings are not attributed to your book.

Addresses you choose to exclude are never read.

A domain or an individual address can be excluded, and it applies to the whole pipeline rather than to what gets displayed. Legal and HR addresses are the usual first entries.

What Kelpie keeps, and what it does not

Email content is never stored.

Message bodies are fetched at the moment they are read, turned into short factual observations, and dropped. There is no body column and no body field: the storage layer has nowhere to put one, and the ingestion path raises an error rather than accepting one. Re-reading a message later means fetching it again from your provider.

What is stored instead is one sentence per observation.

"Roy will send the export by Friday." Each carries where it came from, when it was fetched, and which model read it. Commercial figures and verbatim quotes are kept out of them by a mechanical check, not by a guideline.

One of those observations is a request: what a customer asked for that we do not do.

"Asked for a CSV export of the whole catalogue; we said it is not on the roadmap." One sentence, in the customer's own terms, and it never says how much the ask matters: whether it is a threat to the renewal or somebody being keen is the account owner's read and not Kelpie's. It is shown to the CSM before a meeting and in the account summary, and it is never put into an email to a customer. A pricing ask is not one of these: a request for a discount is recorded as a risk, without the figure, by the same mechanical check as every other observation.

A follow-up email is drafted from those observations and sent by you.

After a recorded call a CSM can ask for the follow-up. It is assembled from that meeting's decisions, commitments and risks and from nothing else: not from an earlier meeting, not from your mail, and not from anything Kelpie noticed about a person. Every line carries the id of the observation behind it, so the CSM can check any sentence before they send it. They send it themselves, from their own mailbox. Kelpie has never sent an email to a customer and has no mailbox to send one from.

A reply to a customer's email is drafted the same way, and sent by you.

A CSM can ask for a reply to somebody at one of their accounts. Kelpie names which message it is answering, fetches that one message from your mail provider at the moment they ask, and drafts from it and from the account's recorded decisions, commitments and risks. The message is not stored: it is read, used, and dropped, the same as every other body. Nothing Kelpie noticed about a person goes into it. The CSM sends it themselves, from their own mailbox, and the sentence above still holds without exception.

Kelpie learns how you write, from mail you have already sent.

Each night Kelpie reads the last fifty messages you sent to a customer and writes a short description of your style: how you open, how you sign off, how long your sentences run. Those messages are read and dropped like any other. What is kept is the description, it quotes no customer, and you can read it yourself. It shapes the wording of a draft and never what a draft claims. There is nothing to fill in: if it is wrong, write differently for a while and the next night learns it again.

What a search engine says about a person is shown and never kept.

A CSM can ask what LinkedIn says about somebody on an invite they have never heard from. The question is asked at the moment they ask it, the answer is shown only when the company it names matches your own mail domain, it is labelled unverified, and nothing about it is written down anywhere. Ask again tomorrow and it is asked again. No profile is stored, no photo, no history, and nothing is fetched on a schedule or about anybody nobody asked about.

What the news says about a customer's business is shown and never kept.

A CSM can ask what has been published about one customer's own business in the last three months. The question is asked at the moment they ask it and never on a schedule. What we send is the account's name, its registered customer domain, and a known-as name if the CSM typed one for that call. What comes back is shown only when an item names that domain, because a company name is not unique, and it is labelled unverified. When nothing names them we say how many we dropped rather than showing an empty page. What we keep is the links we showed, how many we dropped, and how long the search took. Never the story, never the headline, and never the known-as name. Nothing about it becomes a fact about the account.

No customer text is ever sent to a search.

What leaves is derived, and at most it is a person's name and a company name. The LinkedIn lookup sends a first name and a last name, and nothing about the account. Never a message, never a thread, never a quote, never an observation. This is the rule for every search we ever run, not a description of the one we run today. The next one is built inside it.

An observation is never edited, with one exception.

Re-reading a message writes a new set of observations and retires the old batch. What the system believed last month is still readable, which is what makes "why did it say that" answerable at all. The exception is the one below: an observation about a person who has asked to be removed is deleted rather than retired, because retiring it would keep it.

Personal data about a person on your customer's side can be removed on request, by your admin, and stays removed.

Their contact record on every account, anything personal noted about them, and the notes your team wrote about them. It is one action and it cannot be undone. The address is then kept out, so the nightly run does not rebuild them and a meeting they were invited to stops naming them. What stays is the record that a message or a meeting happened, which holds no content and is what every number in the product is checkable against, and your account's own history: what a customer decided is not personal data about whoever was in the room. Every removal is recorded with the name of the admin who made it.

Who can see what

Visibility is decided by the database, per request.

A CSM sees their own book. A manager sees their team's. Whether either is widened is a setting each customer controls, and it is applied inside the database on every query rather than by each page remembering to filter.

Reading and writing are different rules.

Being able to see an account never means being able to change it. Writing follows ownership and line management, so opening a book up for reading does not hand everyone the ability to overwrite a colleague's judgement.

Every change to a human-recorded field is logged, by the database.

Who changed it, from what, to what, and when. The log is written by a database trigger rather than by the code doing the writing, so an administrator with direct database access is audited on the same terms as a CSM using the product. The log cannot be edited or deleted, including by us.

Sign-in and access

Sign-in is OAuth 2.1, through WorkOS AuthKit.

Kelpie stores no passwords. Your team can sign in through your own identity provider via SAML or OIDC single sign-on, in which case account creation and removal stay with your IT team.

An agent gets a token scoped to the person using it.

The connecting agent authenticates as the CSM, sees exactly what that CSM may see, and can write only where that CSM may write. There is no service account with a wider view, and the customer identity comes only from the verified token.

Where the data lives

Australia, in Google Cloud.

The database and every service run in Google Cloud's Melbourne region (australia-southeast1). The database has no public network address: connections come through Google's own internal paths.

The services we rely on.

WorkOS for sign-in, Nylas for mail and calendar access, Anthropic for reading messages, and Resend for the weekly digest email. Each one is named here because a sub-processor a customer discovers later is a sub-processor they were not told about.

Backups, and how far back we can go

The database is backed up nightly, seven kept, and point-in-time recovery is on with seven days of transaction logs. The recovery point is seconds: a bad write at 2pm is recoverable to 1:59pm, not to last night.

The restore is rehearsed rather than assumed. A script restores the newest backup to a throwaway instance, opens every tenant database, checks that the isolation rules came back with the rows, and compares the counts against production. It is run monthly and after any change to how the database enforces separation, because a restore procedure nobody has run is a guess. It was first run on 3 September 2026 and the whole book came back intact.

Leaving

Taking your data out. Ask, and you get every table Kelpie holds about you as a CSV, with a README naming each one. The accounts, the contacts, the distilled facts, the notes, the answers your team gave, and the audit trails behind all of them. The archive is yours to fetch for seven days, then it is deleted.

It contains no email bodies and no meeting transcripts, because Kelpie has never stored any. What it stores is the distilled facts, each carrying the id of the message or recording it came from, so the source stays with your mail provider and your notetaker.

Deletion. Ask, and your mailbox connections are revoked at Nylas, your sign-ins are removed, your usage files are deleted, and your database is dropped. Every tenant has a database of its own, so that last step is the whole of your data going at once rather than rows being picked out of a shared table.

Two things survive it, and pretending otherwise would be the kind of claim this page exists not to make. The nightly backups still hold you for seven days, and point-in-time recovery covers the same window; those backups cover every tenant together and cannot be edited to remove one. And Nylas, WorkOS and Resend keep their own logs under their own retention, which their terms govern rather than ours.

We will not delete you without producing the export first. The script refuses to run without one, because the last moment anybody can give you your data is the moment before it goes.

What is not built yet

Kelpie is early, and a posture page that pretends otherwise is worse than useless to somebody doing a review. There is no formal incident response document, no written access policy, and no SOC 2 or ISO certification. Per-message exclusion beyond the address and domain list does not exist either.

If any of those is a condition of working together, say so and it becomes the next thing built, with your requirements shaping it rather than our guesses.