Skip to main content

Security & privacy

Imaginne is designed to keep your organization in control: files stay on your machine, all model traffic flows through a single point, skills are governed by policy, and identity is single and revocable. This page describes the trust model and what each architectural decision guarantees — and what it does not.

The four pillars​

PillarWhat it meansWhy it matters
Local-firstOn Desktop, in the terminal (TUI), and in VS Code, the agent runs on your machine. Files never leave; only the prompt content travels.Your documents and your code are not sent anywhere just because they sit in the project.
Single egressEvery model call goes through a single egress point — the only path to the model vendor.A single point where the organization enforces credentials, policy, and metering.
Governed skillsThe agent's capabilities (skills) are assigned by profile, run under a workspace-scoped firewall, and can require verified integrity.What the agent knows how to do and where it can act is decided by the organization, not by the end user.
Revocable identityAccess is by organization login only, which establishes an authenticated session. The same session works across the product; the user never handles API keys.Revoking someone's access is immediate and does not depend on collecting scattered keys.

What you can trust​

  • File sovereignty on the app surfaces. On Desktop, TUI, and VS Code, your project files are not transmitted. The agent reads the content locally and sends the model only the excerpt the task requires.
  • A single path to the model. There is no alternative route to the model vendor. This single egress point concentrates authentication of your session, model-policy enforcement, and usage accounting.
  • Credentials out of the client's reach. Vendor keys (BYOK) and skill secrets (env-secrets) live on the server, are write-only, and are never returned to a client app.
  • Reduced accidental leakage. Before sending, a content checker redacts known sensitive patterns (emails, national IDs, tokens, keys) and does not log the text.
  • Layered governance. The effective policy combines platform, organization, user-type, skill-group, and profile rules, with deny-wins: an upper layer can only restrict, never broaden.

What you should not trust blindly​

  • Local state is not encrypted. Sessions and memory sit in readable files on your disk. Protect the machine the way you already protect your code and your documents.
  • Redaction is a layer of defense, not a guarantee. The checker covers recognized patterns; it does not replace caution when pasting highly sensitive data into a prompt.
  • Protected skills guarantee integrity, not absolute secrecy. The local_protected mode prevents tampering and shadowing, but whoever controls the machine can still observe execution. It is not DRM.
  • Browser chat runs on the server. Unlike the app surfaces, in web chat the agent executes on Imaginne's servers; the session is processed there. If the requirement is "nothing leaves the machine," use Desktop or TUI.

Who decides what​

The separation of responsibilities is deliberate:

  • The organization (via the admin console) defines who gets in, which skills each profile receives, which models appear, and holds the credentials (BYOK and env-secrets).
  • The end user controls their local session, the autonomy level, and when the agent may act, within the bounds the policy imposes.
  • The platform establishes a security floor that the organization can only restrict.

Go deeper​