Security and privacy

Nib is local-first. The agent runtime runs on your machine, and your code and session history stay there unless you use a cloud feature. Model requests go to the provider you chose: directly with your own keys, or through Nib's managed gateway when you use Nib models. Nib needs an account, so the app also talks to Nib's servers to sign you in.

What runs whereСкопировать ссылку на раздел

Your code and session history stay on your machine unless you use a cloud feature such as sync or artifacts. The Privacy Policy lists exactly what reaches Nib's servers.

You can turn on end-to-end encryption for synced sessions in Settings → Account. It's off by default; without it, synced sessions are readable on our servers, encrypted in transit and at rest.

What leaves your machineСкопировать ссылку на раздел

• Model requests. To do its work, the agent sends the model your prompts, the instructions it loaded, and the content of files and command output it read. With your own keys, these go directly from the daemon to the provider you chose, under that provider's data policy. With Nib models, they go through Nib's managed gateway, which passes them to the model provider through OpenRouter and doesn't keep their content (Your data). Choose a provider whose retention and training terms suit your code. A local model through Ollama or LM Studio keeps everything on your machine.
• Tool traffic. WebFetch and WebSearch make requests to the sites and search service involved. WebSearch uses your own search key when you've set one; otherwise, when you're signed in, it goes through Nib's managed search on the gateway. MCP servers receive what the agent sends them. Shell commands do whatever they do; use the sandbox to limit them.
• Update checks. The desktop app asks updates.nib.gg for a newer version at launch and every 4 hours, and when you choose Check for Updates…. The request carries the app's version, platform and update channel.

TelemetryСкопировать ссылку на раздел

Crash reports and usage metrics are off by default. Nib asks once, and you can change your choice in Settings → Privacy. DO_NOT_TRACK=1 or NIB_TELEMETRY=off turns both off regardless. Reports are scrubbed of paths, secrets and code on your machine and again on the server, aren't linked to your account, and are kept for up to 90 days. There is no third-party analytics. Details: Privacy Policy.

Keys and secretsСкопировать ссылку на раздел

• Desktop app: provider keys are stored in the OS credential store (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux). Nib's database holds only a reference. Key values are never logged or included in error messages.
• CLI: keys come from environment variables, or from an apiKeyHelper command in settings for keys that rotate.
• Shell commands run with secrets stripped from their environment, so a command the agent runs doesn't inherit your provider keys.
• MCP configuration can reference secrets as ${VAR}. Expanded values are never shown to the model.
• Cloud: keys stored in the cloud are encrypted with envelope encryption under a managed key.

The local daemonСкопировать ссылку на раздел

• Binds 127.0.0.1 only. Listening on any other interface requires an explicit flag intended for cloud sandboxes.
• Uses a random port and a new bearer token on every launch. Every request needs the token. The address and token are written to a discovery file only you can read, so the CLI and editor extensions can find the daemon.
• Accepts browser requests only from allowed origins (the desktop app's own), checked on both HTTP and WebSocket connections.
• The desktop app never writes the token to disk or logs.
• Hooks, MCP servers and shell commands don't inherit the token.

For the full picture of trust boundaries and controls, see Security model.

Safeguards around the agentСкопировать ссылку на раздел

Checks fail closed. A classifier that's unavailable or a hook that can't be reached results in a prompt or a denial, never a silent allow. So does a sandbox that can't be applied, except on a platform that has none (Windows, and Linux without bubblewrap): there shell commands run unsandboxed, each judged by the permission mode, and the session says so when it starts. sandbox.failIfUnavailable: true refuses them instead. See Without a sandbox.

Prompt injectionСкопировать ссылку на раздел

Text the agent reads (web pages, issues, files from dependencies) can contain instructions aimed at the agent. Nib's design assumes this will happen:

• Content from tools is data. It doesn't carry your authority.
• Messages from other agents arrive as information, not as instructions from you, and can't grant permissions.
• The permission engine, protected paths and sandbox apply no matter what the model was persuaded to try.

Treat a repository you don't trust the way you'd treat running its code: review its .nib/ and .claude/ folders, hooks and MCP servers before trusting the workspace.

Desktop app hardeningСкопировать ссылку на раздел

• Loads only its bundled interface; no remote content.
• A strict content security policy limits the UI's connections to itself, the loopback daemon, and Nib's own cloud and Hub.
• All calls from the UI to the native shell pass through an isolation layer with an explicit allowlist.
• The macOS app isn't notarized by Apple yet, so macOS won't open a downloaded copy until its quarantine flag is cleared. Updates are signature-checked against a key compiled into the app.

Data on diskСкопировать ссылку на раздел

The data directory is ~/.nib for the CLI and ~/Library/Application Support/gg.nib.desktop/daemon for the desktop app on macOS. Delete it to remove all local session history.

Reporting a vulnerabilityСкопировать ссылку на раздел

Please report security issues privately to security@nib.gg rather than in a public issue. Our vulnerability disclosure policy explains what is in scope, our response times and our safe-harbour commitment.