Skip to main content

Data & privacy

This page brings together, in one place, the journey of your data through Imaginne: what is sent to the model, what is redacted before it leaves, what is retained and where, what is audited, and why you do not handle API keys. It complements Local execution with a focus on retention, auditing, and responsibility.

What is sent to the model​

On the app surfaces (Desktop, TUI, VS Code), only the prompt content leaves the machine, through the product's single egress point:

  • Your message.
  • Excerpts of files the agent placed into the context for the task.
  • Request parameters (the chosen model, generation options).

The files are not transmitted through these surfaces — the agent reads the content locally and sends only what is needed. In web chat, the agent runs on the server, so the session content is processed there (see "What is retained").

Redaction before sending​

A content checker inspects the text before sending it to the model and replaces known sensitive patterns with placeholders:

CategoryExamples
Personal identifiersEmails, phone numbers, CPF/CNPJ
FinancialCard numbers
TokensSession tokens
KeysCloud keys, PEM private keys

The text matching these patterns is not logged. Like any pattern-based detection, it is a layer of defense against accidental leakage — not a guarantee that any secret will be caught. Avoid pasting highly sensitive data that does not follow a recognizable format.

What is retained — and where​

Retention depends on the surface.

App surfaces (local)​

State stays on your machine, in readable (unencrypted) files:

  • Sessions / history — local project files.
  • Project memory — <project>/.imaginne/memory/*.md.
  • Artifacts — the project output folder (outputs/, plus generated-images/ and generated-canvas/ on Desktop).
  • Configuration and token — ~/.imaginne/config.yaml (permissions 0600).

You control this data the way you control any file: deleting the folder deletes the state. In the TUI, IMAGINNE_TUI_LOCAL_STORE=off disables local persistence.

Browser chat (server)​

In web chat, the session is persisted on the server, tied to your organization and your user, so you can reopen the conversation. Hosted sessions expire after periods of inactivity. This is the core privacy difference between web chat and the local surfaces.

Choose the surface by your data requirement

If your policy requires that work content not leave the machine, use Desktop or TUI. Web chat prioritizes immediate, install-free access, at the cost of processing the session on the server.

Metering and auditing​

  • Usage metering. The single egress point accounts for the organization's model usage. There is no admin-facing usage dashboard for the organization in this release, beyond the Dashboard cards.
  • Governance auditing. The admin console keeps an audit log of administrative actions — creating and changing users, profiles, skill groups, publishing/rollback/archiving of skills, among others — with the time, action, actor, target, and details. It is the record of who changed what in the organization's configuration.

You do not handle API keys​

Access is exclusively by organization login, which establishes an authenticated session. As a result:

  • Creating a user generates neither a password nor an API key — the invitee sets the password by email.
  • The user never receives or pastes a vendor key.
  • The same authenticated session works across the product, and revoking it cuts off access quickly.

This eliminates the entire class of leaked or forgotten user-key problems. Details in Credentials & secrets and Identity.

Credentials under the organization's control​

The credentials that matter to third parties — model-vendor keys and secrets used by skills — belong to the organization, live on the server, and never reach the client:

See also​