Data flow and privacy boundaries

Kairo Code keeps Task authority on the selected Host, but a Task is not necessarily an offline-only workflow. Model calls, Browser actions, MCP tools, telemetry exporters, and a custom Memory provider can send data beyond that Host. Review these boundaries before using a private repository or regulated data.

Task permissions control which tools may act. They are not a blanket consent dialog for every model request, nor a guarantee that content sent to an external service has been anonymized.

Boundary summary

Boundary	What is handled or sent	When, default, and approval	Persistence and deletion
Local Host	Prompts, attachments, selected repository content, tool inputs/results, approvals, Task metadata, and recovery state. A Remote Project uses its selected remote Host instead of the local machine.	Required to create and run a Task. Choosing a Project and sending a prompt admits data to that Host; there is no separate approval for ordinary Task persistence. Tool actions still follow the Task permission profile.	Durable Task state lives in the Host data store; workspace changes live in the selected checkout or managed worktree. Permanently delete removes the Task aggregate and Task-owned local resources, but not ordinary Project files or separately saved Memories. Cleanup failures can leave administrator-removable residual files.
Selected model provider	System and user instructions, conversation context, relevant file or attachment content, recalled Memory text, tool schemas, and tool or Browser results selected for the next model call. The provider credential is used for authentication.	Sent when you test a connection or a Task makes a model call. Optional model-based Memory extraction can make another call when Memory contribution is enabled. Selecting a connection and sending the Task starts this path; filesystem or command approval is not a per-call provider consent prompt.	Retention, training, logging, residency, and deletion are controlled by the selected provider, gateway, and organization account. Deleting a Kairo Task or connection does not delete provider-side records. Use the provider's controls or contact its administrator.
Browser and website	Navigation URLs, requests, cookies or signed-in session state, clicks, typed values, uploads, downloads, and page content or screenshots returned as evidence. Paired Chrome uses the explicitly paired Chrome profile.	Manual browsing sends requests immediately. The Agent needs approval for a new read origin and a one-time decision for clicks, typing, downloads, tab changes, and other page actions. A page may receive data before Kairo can confirm the result.	Browser profiles can retain cookies, history, and site data. Kairo's clear-data controls affect the local browser profile, not server-side website records. Task screenshots and evidence remain until the Task is permanently deleted. Delete site-side data through the website or its administrator.
MCP and external tools	The exact tool arguments plus repository, prompt, or result content required by the configured tool. The external service may return content that later enters Task history or model context.	Only when an MCP server or external integration is configured, available to the Task, and invoked. Admission follows the Task permission profile, tool side-effect classification, explicit rules, and administrator policy; not every read requires a prompt, and approval cannot exceed those ceilings.	Kairo retains the Task's request/result evidence. The MCP server or downstream service may keep its own logs or objects. Disabling or removing a connection stops future use but does not prove external deletion. Use that service's deletion controls.
Telemetry	Local metrics contain bounded operational measurements without Task IDs, paths, prompts, tool arguments/results, or model-provided values. Default exported traces contain bounded operational metadata such as model name, token use, timing, outcome, and tool name.	Prometheus metrics are local by default. OTLP export is off until an administrator configures an endpoint. Langfuse content and stable-identifier export are two additional options, both off by default and requiring explicit organizational approval.	An enabled collector controls retention and deletion of exported data. Removing the exporter and restarting the Host stops future export; it does not delete data already stored by the collector.
Memory	With recall enabled, up to 4,096 characters of the current direct user intent query the owner-scoped primary; bounded matching entries can enter model context. With contribution enabled, eligible completed Task context may be extracted and stored. Browser, MCP, web-search, and other external-tool context needs the separate Learn from tool-assisted tasks opt-in.	Recall, contribution, and external-context learning are independent and all off by default for new identities. A Task freezes these choices at creation. A custom or JDBC primary can place Memory outside the local data directory.	Memories persist independently of the source Task. Manage and delete them under Settings → Advanced → Memory & learning and check the deletion receipt. External unverified means Kairo cannot prove every custom-provider copy was removed.

Redaction is not DLP

Kairo's PII policy recognizes a fixed set of known patterns. Pattern matching can miss a secret, personal identifier, proprietary value, or an unfamiliar credential format, and it can also redact innocent text. It is not a semantic data-loss-prevention system and does not guarantee secret or PII discovery.

The default Task redaction boundary checks complete model output and tool results before protected history, checkpoints, client presentation, or evolution telemetry. It does not redact the system prompt, conversation history, Agent tool inputs, or other context sent to the selected model provider. Memory has its own bounded persistence-admission and credential-redaction checks, but those checks do not sanitize the Task's model request and do not turn model-provider egress into an anonymized channel.

Treat every value you deliberately place in a prompt, attachment, repository, Browser form, or external-tool argument as potentially visible to the corresponding boundary. See Sensitive data for the exact pattern coverage and diagnostic override.

Before using sensitive data

1. Confirm the exact model connection, endpoint, organization account, retention policy, and data residency requirements.
2. Remove secrets and unnecessary personal data from prompts, attachments, and authorized repository roots; do not rely on pattern redaction to find them.
3. Keep Memory recall, contribution, and external-context learning off unless each use is intended.
4. Review the website origin and the precise Browser action before approving it, especially when a signed-in session, upload, message, form submission, or payment is involved.
5. Review MCP server ownership and its downstream service policy before enabling the tool.
6. Leave telemetry content and identifier export off unless your organization has approved the collector and its retention policy.

Deletion is boundary-specific

Deleting a Task removes Kairo's authoritative Task record; it does not recall data already sent to a model provider, website, MCP service, or telemetry collector. It also does not delete Memory entries previously contributed from that Task. Delete each external copy through the system that owns it, and use Kairo's separate Memory manager and Browser clear-data controls for those local stores.

For exact Task deletion semantics, see Projects and Tasks.