Privacy and data boundaries
Cairn can operate as a local, single-user application, but “local” does not mean that every feature keeps every byte on one machine. Model calls are network calls unless you use a model host under your control. Team sync, GitHub, external tools, remote executors, and billing each add a separate recipient.
This page describes current product behavior. Storage protection and service implementation can change, so it does not promise a particular encryption protocol or permanent key-custody design beyond the boundaries stated here.
Boundary summary
| Recipient or storage location | What it receives | When |
|---|---|---|
| Local repository and Cairn storage | Repository objects and checkouts; private project records; issues, run state, transcripts, settings, logs, indexes, and cached team replicas | Normal desktop and runner operation |
| Anthropic, OpenAI, or OpenRouter | Agent prompts, supplied file and issue context, conversation/tool-loop content, and tool results included in a request | When an agent uses that provider; OpenRouter may route onward to its selected model provider |
| Configured Ollama host | The same model request content sent to its configured API address | When an agent uses that host; it is local only if the host and network path are under your control |
| Cairn account and team services | Account/device identity and memberships; team sync authorization and replica traffic; team project, issue, execution, transcript, shared configuration, presence, and object data | After account connection and when a project is team-connected; team data sync requires team sync to be enabled |
| GitHub and Cairn's webhook relay | GitHub App installation and repository metadata, pull-request operations, and webhook payloads | After connecting the GitHub App and using GitHub features |
| External MCP server or local MCP process | Tool arguments and MCP protocol request/context, plus configured authentication headers or environment | When you configure the server and an agent or operator calls it |
| Enrolled remote executor | Repository/check-out and run inputs, transferred artifacts, environment needed for execution, and any provider credential required by the agent process | When you place work on that executor |
| Stripe | Billing customer and organization metadata, subscription and seat quantity, payment details, and subscription status | When an organization owner or admin starts or manages a paid team subscription |
| AWS Bedrock (Cohere embeddings) | Text submitted for semantic embedding | When a feature requests an embedding through Cairn's anonymous embedding gateway |
| AWS SES | Invitee email address, inviter and team information, and invitation link/content | When an owner or admin sends a team invitation |
| Member-configured web-push services | Project key, issue number and title, attention kind, and notification text | When team attention triggers notifications for members who enabled web push |
What remains on the runner
A personal project uses Cairn's private database. Its issues, comments, executions, transcripts, and application state are stored on the runner alongside local indexes and logs. Repository content remains in the repository and Cairn's local Git/Jujutsu stores and temporary execution checkouts.
This local copy is still subject to the security of the operating-system account, filesystem, backups, and any process with access to the Cairn home. Cairn's Analytics settings page computes its views from stored local run, transcript, and tool data; it is not a third-party analytics dashboard.
A team-connected project is different. The runner keeps a local replica for offline reads and writes, while shared rows synchronize through the hosted team service. Large packed objects may be stored in team-scoped hosted object storage and transferred through time-limited URLs. Local writes can succeed before other members receive them.
What a model provider receives
The provider receives the prompt and whatever context the agent supplies for the request. That can include issue text, instructions, file contents, diffs, command output, tool results, and earlier conversation content. The exact set varies by agent, backend, and task; a repository is not uploaded wholesale merely because it was added to Cairn, but an agent may read and send relevant parts while it works.
Provider authentication methods include installed command-line sessions, subscription sign-in, OAuth credentials, and API keys. At rest, credentials are kept by the configured runner using the storage mechanism implemented for that provider, including operating-system credential storage where supported. They are not uploaded to Cairn's account control plane as a credential vault.
For local execution, the runner uses the credential to contact the provider. If you explicitly select a remote executor, Cairn may inject the required credential into the agent process environment on that executor. An internal lease deadline can bound re-issuance and auditing, but it cannot revoke a credential a running process has already received. The executor can therefore use that credential and see the run's input and output; enroll only a host whose operator you trust. Review each model provider's retention and training terms separately.
GitHub App and relay
The GitHub App gives Cairn the repository permissions selected during installation. Cairn uses it for supported branch, pull-request, status, review, and webhook operations. GitHub receives the repository data and operations that normal Git and GitHub App use requires.
GitHub sends webhook payloads to Cairn's relay. While the desktop is connected, the relay forwards payloads to it; payloads waiting for an offline desktop may be stored by the relay. The current GitHub page documents the relay's current storage protection and local App key handling in more detail. Those controls do not make GitHub activity local. See GitHub.
Hosted accounts and team sync
Signing in connects the installation as a device and sends account/device and organization-membership requests to Cairn's account service. Open team replicas also publish machine presence, including a device identifier, host/platform label, last-seen time, and locally available team project keys, so remote actions can be routed to an owning runner.
When team sync is enabled and a project belongs to that team, its shared Cairn records cross the hosted sync boundary. This includes project and issue data, comments, execution ownership and state, transcripts and current run events, and team/project configuration stored in the replica. Repository source is not the same data path: Git content moves through Git remotes, execution material transfer, or hosted packed-object transfer when those features require it.
Account sign-out stops authorization and pauses sync on that installation. It does not promise deletion from the hosted service, other members' replicas, backups, Git hosts, or machines that previously received the data.
External tools and web services
An external Model Context Protocol (MCP) server is its own trust boundary. A network server receives requests at its configured URL, including configured headers; a local stdio server is a child process that receives configured arguments and environment. In either case, the tool receives the call content an agent sends and can return content that becomes part of the transcript or a later model request. Check the server operator's policy before adding credentials or sensitive arguments.
Other configured channels, web services, and automation targets receive the payload of the action sent to them. A user-submitted bug report sends the report content and attachments to Cairn's service. Account-less installations may also contact Cairn's anonymous embedding gateway for features that generate semantic embeddings; the gateway receives the text submitted for embedding and an anonymous device token, then sends the text to AWS Bedrock's Cohere embedding model. Sending a team invitation uses AWS SES with the invitee address, inviter and team information, and invitation content. Team attention notifications use each subscribed member's configured web-push service with project and issue identifiers, the issue title, attention kind, and notification text. Disable or avoid a network-backed feature if its current settings do not meet your boundary requirements.
Remote and headless execution
An enrolled machine is an execution boundary, not just a display target. Cairn transfers the material required to run the selected work and receives results or artifacts back. The host's operating-system user and administrators can potentially inspect that material, process memory, credentials used there, and network traffic leaving it.
The current hosted web/mobile surface dispatches or steers supported actions; it does not execute the agent itself. The owning runner performs the action and sends resulting shared state through team sync. See Teams and remote work for current surface limitations.
Billing
Team billing is a hosted account feature. When an owner or admin subscribes, Stripe processes payment details and receives the billing customer and organization metadata, subscription and seat quantity, and status needed to manage the subscription. Cairn stores the account's subscription state needed to authorize paid team features. Personal, local-only operation does not require a team subscription.