Security and privacy

ORG-2 runs agents on your machine, with your credentials, against your repositories. No server holds your source, but a local process can read files and run commands on your behalf. This page describes what the app actually enforces, and is deliberately explicit about what it does not provide.

The local-first threat model

ORG-2 assumes your machine and user account are trusted — anything running as your user can read its data, and physical device access is out of scope. The network is untrusted, so all traffic is HTTPS. Your model provider sees what you send it.

It does not assume the agent is safe. Policy controls make destructive actions harder and visible, but a model prompt-injected by content in your repository is a real risk — review what an agent did, which is what Replay is for. ORG-2 does not defend against another process running as you, a compromised model provider, or a malicious MCP server you chose to install.

Where credentials live on disk

ORG-2 keeps its data under ~/.orgii/ on every platform (overridable with ORGII_HOME).

Warning: ORG-2 does not use the OS keychain, Windows Credential Manager, or the Linux Secret Service for its own secrets, and does not encrypt them at rest. credentials.json is plaintext JSON whose only protection is the file mode, and the databases are plain SQLite with no passphrase. Any process running as your user can read all of it. Treat the machine itself as the security boundary, and use provider keys scoped to what the agent actually needs.

Hardened files get their permissions applied before an atomic rename, so they are never briefly world-readable; integration configuration and some CLI-agent OAuth profiles do not get that treatment. Cloud session tokens live in the embedded WebView's local storage rather than ~/.orgii/.

Secrets pasted into the in-session secrets prompt are handled better: held in a zeroizing memory buffer, referenced by an opaque token, and resolved only when written to an environment file (mode 0600) — never entering the model transcript or the session database.

What an agent can reach, and how to constrain it

Configure these per agent under Settings → Security, which exposes Access Mode (Read Only / Read + Write), Workspace Only, Path Policy → Forbidden Paths, and Command Policy → Block List and Always Ask List. Forbidden Paths takes one absolute or ~/-relative path per line; the in-app example is the set most people want — ~/.ssh, ~/.aws, /etc, and on Windows your .ssh folder and System32.

Paths are checked twice, independently: syntactic validation rejects null bytes, .. components, and URL-encoded traversal such as ..%2f, while Workspace Only separately tests containment inside the session's allowed roots.

Set Forbidden Paths. It defaults to empty, and it is what keeps an agent out of ~/.ssh and your cloud credentials.

Approval prompts

Commands are classified by risk before running. High-risk patterns — by default sudo and shutdown — are blocked outright. Medium-risk patterns pause for approval: the shipped list covers rm -rf, dd, reboot, su, network tools such as wget, nc and ssh, and destructive git operations including git clean, git reset --hard, the git push --force variants and git branch -D. Both lists are editable, with Policy Reset → Reset to defaults.

Commands with irreversible external side effects always require confirmation: git push, gh pr/issue/release, npm/yarn/pnpm publish, cargo publish, twine upload, and pip upload. Matching runs on the normalized pipeline, so chaining or piping does not slip a command through.

Isolation: worktrees, not an OS sandbox

Warning: ORG-2 does not run agents in an OS-level sandbox. There is no seatbelt or sandbox-exec profile, no Landlock, no container. Agent processes run as your user with your environment. Isolation comes from the policy layer above and from git, not from the kernel.

What you do get is worktree isolation: a sub-agent can run in a temporary git worktree, so its file and shell activity does not touch your working tree and its work lands on its own branch. Stale worktrees are pruned in the background — by default at most 8 per repository, cleaned up every 6 hours.

For anything untrusted, combine the layers: run it in a worktree, set Access Mode to Read Only, and populate Forbidden Paths. If you need kernel-level confinement, run ORG-2 inside a VM or container you control.

Secrets hygiene in repos an agent works in

File-walking tools use a .gitignore-aware walker, so ignored files are not swept into context by a broad search, and the workspace summary the agent gets at session start skips dotfiles apart from .gitignore and .env.example. That reduces accidental exposure but is not a boundary — an agent with read access and a specific path can still read an ignored file. Keep real secrets out of the workspace directory, add ~/.ssh and ~/.aws to Forbidden Paths, use the in-session secrets prompt for values an agent must not see, and review the replay before sharing a session.

What is transmitted, and to whom

To your model providers: prompts, conversation history, and whatever file contents or command output the agent pulls into context — sent directly from your machine with your own key, not proxied by us. See API keys.

To ORG-2 when you sync: only what your Session access mode allows for your Allowed workspaces, and full replay only for requests you approve. Never your API keys, never your source tree. See Cloud and sync.

Nothing else. There is no crash reporter and no third-party analytics SDK. Updates are cryptographically signed and verified against a key baked into the app.

Diagnostics and telemetry

Diagnostics are opt-out, not opt-in. privacy.diagnosticsLevel defaults to default, and the app uploads an aggregate snapshot every 12 hours by default (configurable between 1 and 24).

Collection is aggregates and bucketed values, never content: app version and launch count, OS family and coarse version, CPU/RAM and app memory buckets, success and failure counts per internal operation name, session counts by category, workspace counts, and at the default level model names with per-model run counts. There are no prompts, messages, file contents, file paths, repository names, hostnames, or usernames. Identity is a random UUID generated once per install — no email, no account id.

The sanitizer works by allowlist: it builds a fresh record, copies in only recognized fields, and caps every string, so an unrecognized key cannot be forwarded. Snapshots queue to ~/.orgii/diagnostics/queue.jsonl and upload over HTTPS to an ORG-2-operated endpoint, which also records the country its edge observes.

To change it, edit ~/.orgii/settings.jsonc:

{
  "privacy.diagnosticsLevel": "performance-only",
  "privacy.offlineMode": true
}

• performance-only drops usage aggregates and keeps performance counters.
• off is a minimisation tier, not a kill switch — it still sends a minimal existence heartbeat with session, workspace, and external-tool counts plus the install id.
• privacy.offlineMode: true is the actual kill switch. It disables non-essential outbound network calls including all diagnostics uploads.

Note: There is currently no settings-screen toggle for these keys. Editing ~/.orgii/settings.jsonc is the supported way to change them.

The cloud path: transport, storage, and org isolation

Traffic to ORG-2 Cloud is HTTPS. Sign-in uses a magic link with PKCE completed in your browser, and tokens return to the desktop app in a URL fragment, so they never reach a web server or its logs; only a fixed set of desktop callbacks is accepted, closing off open-redirect abuse.

Isolation between orgs is enforced in the database: every table has row-level security enabled, and clients never issue raw table queries. All access goes through stored procedures that check org membership — and in several cases admin or owner role — before reading or writing, and those procedures are granted only to authenticated users.

Be clear-eyed about storage: the schema adds no application-level or end-to-end encryption of session payloads. Synced replay is stored as it arrives, protected by row-level security and platform disk encryption rather than a key only you hold, so anyone with legitimate administrative database access could read it. That is why Session access defaults to Off and full replay requires per-request approval. The self-hosted path applies row-level security to every table its setup SQL creates, but key custody, backups, and network exposure are yours.

Reporting a vulnerability

Do not open a public GitHub issue for a security vulnerability. Email security@orgii.ai with a description and impact, reproduction steps, affected versions and platforms, and any mitigations you know of. PGP-encrypted email is available on request.

Published targets: acknowledgement within 48 hours, triage within 5 business days, a patch within 14 days of triage for critical and high issues and 90 days for medium and low, and coordinated disclosure once a patch ships. Reporters are credited unless they prefer anonymity, and only the latest release receives security patches.

Next steps

• Cloud and sync — what each backend stores and how sharing modes work.
• API keys — adding provider keys and which agents use them.
• Tools — what each built-in tool can touch.
• MCP — reviewing an MCP server before you connect it.