Isolation per company, secrets in the OS keychain, human consent on sensitive actions — autonomy without opacity.
Isolation
- Per-company isolation: one company cannot browse or retrieve another company's workspace, members, threads, or configuration, with agent-level partitioning inside a company.
- Cross-workspace missions: a mission places the companion you already work with—not a blank agent. By default, it can use the knowledge and rules it accumulated in the home workspace. Before an assignment, tell the companion which rules must remain internal to your organisation; rules recorded that way stay in the home workspace. This control applies to rules, not accumulated memories. The client cannot browse or retrieve the home workspace, and client work is excluded from home-workspace memory and overnight learning. Either workspace can end access. See Cross-workspace missions.
- Local-first workspaces: each thread runs in its own isolated working directory on the human's machine; workspace configuration never leaks into global user config. Repositories are cloned per thread rather than shared through git worktrees, so parallel threads never collide on git state (see Architecture).
- Model locality: Ollama and OpenAI-compatible providers connect to a URL you configure — point either at a machine you control (local or self-hosted) and inference never leaves your infrastructure. Point them at a cloud endpoint instead and inference runs there, same as Claude or Codex.
Secrets
- API keys and OAuth tokens are stored via the operating system's secure storage — Keychain on macOS, DPAPI on Windows, libsecret on Linux — never in plaintext files.
- Credentials are injected into agent processes through the environment at spawn time, not written to disk.
Permission gating
Sensitive tool executions go through a permission system:
- Deny rules always rank first — no allow shortcut can precede them.
- Human consent on sensitive actions: shell commands, file writes, and outbound side-effects (sending an email or a Slack message to the outside) prompt the human, with consent scopes (once, this thread, all threads).
- Fail-closed posture: if the permission service is unreachable, non-read tools are denied rather than silently executed.
- Blocked commands: known-dangerous command patterns are denied before execution, with the safe alternative shown.
- Scoped read grants: a companion can be given read access to specific folders (and everything under them) outside its per-thread working directory (Settings → Extra directories, per agent). Reads there are auto-approved so it can analyze documents that live elsewhere on the machine; writes still prompt like anywhere else. Grants are read-only and stay local to the device.
- Audit trail: every permission decision is recorded — which tool, which verdict, which rule decided.
- Opt-in bypass (off by default): a human can choose to let a trusted companion act without these prompts — as a global default or for a single conversation. Turning the global default on takes an explicit confirmation, and any conversation running without prompts shows a persistent banner. Autonomous and scheduled runs never inherit it, and a companion cannot grant itself this setting.
Behavioral safeguards
Companions are instructed to protect their internal instructions, resist impersonation and presupposition attacks, and accept identity or memory changes only from their own human. These safeguards follow the companion across runtimes. They reduce risk and complement—but do not replace—the platform-enforced isolation, permissions, and access controls above.
Operational safety
- Runaway protection: process limits, cooldowns, execution timeouts, and clean process termination.
- Read-only surfaces where they belong: managed configuration is visible but not editable from the app.