Data security and privacy in kcap

Written for the person reviewing kcap before a team adopts it. The short version for everyone else is How kcap handles your data

Data kcap collects

A stored session contains, where the agent exposes it:

Data	Detail
Prompts	The full text of every message to the agent
Responses	The full text of every reply
Tool calls and results	Commands, file reads and edits, with inputs, outputs, timing and the changes applied
Reasoning	Thinking text, when the agent writes it to its transcript
Token counts	Input, output, cache reads and writes, per turn
Subagents	Each spawned agent, with its own transcript and tally
Repository context	Repository, branch and pull request
Commits	SHA, repository, branch and redacted message of each commit the agent makes

Plus what people and agents add on purpose: declared plan documents (up to 256 KB each), memories, pages, work-item declarations, evaluation results

kcap never scans or uploads a repository. File contents appear only where the agent read or changed them inside a session. Recording is opt-in per agent and can be switched off; any repository or folder can be excluded, and nothing from an excluded one is ever sent. Credentials in known formats (keys, tokens, passwords) are replaced on your machine before upload, in transcripts and commit messages; this is a safety net, not a substitute for excluding sensitive projects. Records over 4 MiB are replaced by a marker. The only kcap code that runs on your machine, the kcap CLI, its daemon and the desktop app, is open source at github.com/kurrent-io/kcap-cli, so what it collects and sends can be read rather than taken on trust

Data location

A cloud workspace is a server dedicated to your organisation, hosted in the EU on infrastructure Kurrent operates. Sign-in runs through WorkOS in the US. The full list of services kcap relies on is in the privacy policy. Your data is never used to train models, and never sold or shared

The local edition keeps everything on your own machine under ~/.config/kcap/local and listens only on the loopback interface. Its server exports no telemetry, traces or error reports, whatever its environment says. The kcap CLI and the desktop app on that machine still send the usage reports described under Telemetry until you turn them off

Access by Kurrent

Kurrent and its employees do not have access to your workspace’s data. Nobody at Kurrent holds an account in your workspace unless one of your admins invites them, and support works from what you send us: a bug report, a screenshot, a session you chose to share. Kurrent operates the infrastructure a cloud workspace runs on, which means keeping its servers, storage and backups running, not reading what is in them; that operational access is held by a small on-call group, is logged, and is used only to keep the service up or to carry out a request you made in writing, such as deleting a workspace

Encryption, retention and deletion

Data is encrypted in transit. Provider keys and integration secrets saved in the console are encrypted at rest with keys that survive rebuilds. Sessions are retained until deleted: a member deletes any of their own sessions at any time (kcap disable <id>, or by asking their agent), and deletion removes the session and its subagents from the server; the agent’s own transcript file on the member’s machine is untouched. Imported history can be deleted the same way. Organisation-level deletion, including closing a workspace, is handled by Kurrent on request. On the local edition, kcap local uninstall --purge deletes the server’s data, logs and caches

Who can read what is governed by each session’s audience, enforced in every surface: the web app, the desktop app, Slack previews, and the tools agents use. Search and recall never reach past what the person could open themselves. Admins see that sessions exist; they read content only where the audience allows

Telemetry

The CLI sends anonymous, pseudonymous usage reports (which commands run, not their content). Turn it off with kcap config set telemetry off, KCAP_TELEMETRY=0 or DO_NOT_TRACK=1. The web app uses product analytics with the consent choice the cookie banner offers; a deployment can attach a member’s name and email to their analytics identity, and that setting is off by default. Error reports from the server do not include session content. On the local edition the server sends none of this, but the CLI and the desktop app do send their usage reports, on any edition, until you turn them off: kcap config set telemetry off covers the CLI, and the desktop app has the same switch under Settings → Privacy

Questions this page does not answer: ask the team