You’re handing Kika your conversations.

Last updated: September 17, 2026

Kika listens to private business conversations and remembers them. That is more sensitive than most software. A leak here isn’t a mailing list - it’s what someone said about a client, a salary, a deal, or a colleague. We built for that, and this page is written to be checked rather than to reassure.

Your call audio is never stored

This is the most important fact on the page, so it goes first. Audio from your meetings is transcribed as it streams and then discarded. It is never written to disk, never placed in storage, never backed up. There is no recording of your call to leak, subpoena, or mislay - because none exists.

What we keep is the transcript text, the notes written from it, and the memory built on top. Those we do hold, and the rest of this page is about how.

What we hold, and what protects it

We hold no card data - our payment provider is the merchant of record, and card details never touch our systems - and no passwords, because sign-in is Google only.

Your data is reachable only by you, and by people you name

This is the guarantee the whole product rests on. So it does not depend on application code remembering to filter by user - it is enforced underneath the application, in the data layer itself, and then tested by attacking it.

By default an account is alone with its data. The one way anything is shared is that you add someone to an engagement by email, and only the engagement’s owner can do it. There is no other path: no link that grants access, no organisation-wide visibility, nothing readable by being on the same domain as you.

Enforced below the application

Every record that belongs to you carries your identity, and the database enforces that binding on every read and every write. The credentials our application runs under cannot switch off or step around that rule, and the identity is scoped to a single request, so one user’s session can never bleed into the next.

The practical consequence: if we ever shipped a bug that forgot to filter a query by user, the database would still return nothing. Your memory across meetings is partitioned the same way, and anything outside your partition answers “not found” rather than “forbidden” - so an identifier cannot be probed to learn whether it exists in someone else’s account.

Verified adversarially, not asserted

A suite of 19 automated tests takes the attacker’s side. Handed another account’s identifiers, they attempt to read, list, overwrite, delete and forge - through the same code paths our live API uses. They also confirm the application’s own credentials cannot opt out of the rules.

Two details make that meaningful rather than decorative. The tests include a positive control proving the target data really is there - without it, a setup that silently wrote nothing would make every “attacker sees nothing” result vacuously true. And the whole suite was validated against a deliberately broken configuration, with the isolation rules switched off: the same queries then did return the other account’s data. The tests fail when the protection is removed, which is the only way to know they test anything at all.

What someone you add can see, and what they cannot

An engagement is a shared memory, so a person you add reads what it knows: the decisions and their reasons, what is blocked, what was promised, what was already tried. That is the point of adding them. Two consequences are worth stating plainly rather than leaving to be discovered.

They can also see the record of how those facts arrived - which sessions the capture hook read, what it kept and what it discarded, including short excerpts of those turns. It is there so that when memory looks wrong, anyone on the engagement can tell whether a colleague’s sessions are dropping the decisions you both rely on. If that is not what you want shared, do not add people to that engagement.

They cannot act as you. Every record carries the identity of whoever created it, and the database refuses a write attributed to anyone else - so a fact always names the person and the branch it came from, and nobody can put words in your mouth. Your own conversations with Kika stay yours: the memory is shared, the asking is not. Only the owner may add or remove people, transfer the engagement or delete it.

Everything outside an engagement you are on answers “not found”, not “forbidden”, so an identifier cannot be probed to learn whether it exists in somebody else’s account.

AI and your data

For a product like this, this section matters as much as the infrastructure.

• Your content is never used to train models. Not by us - we do not train models - and not by our providers, who operate under enterprise terms in which prompts are neither retained nor used for training.
• We treat every transcript as untrusted input. A transcript is half somebody else’s words, and a calendar invite was written by whoever sent it. So our defence against a malicious instruction hidden in that text is structural, not a politely worded prompt: nothing the model can do has any way to specify whose data to touch. The model chooses the question; your verified session chooses the person. An injected “now search Dana’s memories” has nowhere to put “Dana” - and we have tests asserting exactly that.
• Writing notes cannot rewrite your history. The note-writing and meeting-prep features can read your memory but have no ability to change it.
• Anything the model chooses to remember is marked as such, and trusted less than what you tell Kika yourself - so a planted “fact” cannot quietly promote itself into your future meetings.
• Quotes are extracted, not generated. When Kika quotes your meeting back to you, that text is lifted from the transcript mechanically rather than written by the model, so a quote cannot be fabricated.

Every company that touches your data

The complete list. If we add one, this table changes.

We do not sell your data and we do not share it for advertising. No human at Kika reads your transcripts. There is no “review conversations to improve quality” programme, opt-in or otherwise.

Access, network and encryption

• Sign-in is Google only. We never see or store a password, and the desktop app never carries a credential that could be extracted from it.
• Connecting your calendar re-checks who you are, so choosing the wrong Google account in the browser is a clean error rather than silently attaching a colleague’s calendar.
• Our internal systems are not reachable from the internet. They have no public address at all and talk to each other over a private network, with authentication required even there.
• Encryption. TLS on everything public, encryption at rest on stored data, and a second application-level layer of encryption on the most sensitive credentials - which fail closed: if the key is unavailable, the feature reports itself unavailable rather than storing anything in the clear.
• Rate limiting across the board, and tighter still on sign-in, checkout and the expensive AI paths.
• Secrets live only in our host’s encrypted configuration - never in the source repository, never inside the shipped app.

Deletion actually deletes

Delete a single meeting from inside the app, or your whole account from Settings. Deleting the account removes your meetings, transcripts, notes, question history and memory.

The order is deliberate. Your memory is purged first, because it is held apart from the rest and the handle to it is lost once your account is gone. We then revoke our access at Google, and only then delete the account itself. If the memory purge fails, the whole deletion stops and reports an error - so a partial delete can never be mistaken for a complete one.

One deliberate exception, which we would rather name than have you discover: so the free monthly allowance can’t be reset by deleting and re-creating an account, we keep a one-way cryptographic hash of your account identifier and a usage count. It holds no email, no name and no content, and cannot be reversed into an identity.

Compliance

What we’re working on

These are the active workstreams, and most of them are inside the SOC 2 effort. We would rather tell you what is coming than let you assume it is already done.

• An independent penetration test. We test our own isolation model hard; the next step is having someone outside do it.
• Continuous dependency scanning on every change, so a newly disclosed vulnerability reaches us automatically rather than at the next review.
• Durable, searchable audit logging of data access - a SOC 2 requirement, and useful long before the report arrives.
• Formal written policies covering access control, incident response and vendor management, plus a rehearsed restore from backup.

Found a vulnerability?

We would rather hear it from you than from anyone else. Email security@getkika.app. We will acknowledge within three business days and keep you posted until it is closed.

Please don’t open a public issue, and please don’t test against other people’s accounts - if you need a second account to demonstrate something, ask and we’ll set one up for you. We will not pursue anyone who reports in good faith and gives us reasonable time to fix the problem.