Privacy & Security

When you use a local provider (Ollama, LM Studio, llama.cpp, vLLM, etc.), all inference runs on your hardware. Conversation history, long-term memory, and your knowledge base are stored in a local SQLite database. Nothing is sent to external servers, and there is no analytics or telemetry.

To confirm your active provider: the model picker in the top bar shows which provider is in use. To change providers, go to Settings → Models → Providers.

If you use a cloud provider (OpenAI, Anthropic, Groq, etc.), your messages go to that provider's servers. Bodega One does not sit in the middle or store copies - but those messages do leave your machine. Switch to a local provider for full network isolation.

The diagnostics bundle (Settings → About → Export Diagnostics Bundle) stays on disk. Review it before sharing publicly - it can include file paths and command strings you have typed.

Air-gap mode is a single toggle that activates 14 independent enforcement layers across the app. When on, agent tools cannot make outbound connections, the auto-updater is disabled, cloud speech-to-text is blocked, Cloud Boost routes to local, and license verification enters a grace period.

To enable:

1. Open Settings → Privacy & Safety
2. Under Network Privacy, toggle Air-Gap Mode on
3. A toast confirms the change

To turn it off, toggle it again.

When air-gap is active, an Air-Gap badge appears in the top bar (shield icon + "Air-Gap" label) as a persistent visual confirmation. It is always visible while air-gap mode is on - you never have to open Settings to verify the status.

What air-gap blocks:

• web_search and web_fetch tool calls
• Shell commands that make network requests (curl, wget, git clone/fetch/pull/push, npm install, pip install, cargo install, go get, docker pull, and script execution via node, python, deno)
• Cloud speech-to-text (fall back to local faster-whisper-server)
• Auto-update checks - the Check for Updates button shows "Blocked (air-gap)"
• Cloud Boost (re-routed to local provider)
• License verification calls
• llama.cpp binary install and GGUF download endpoints (return 403)
• HuggingFace model search and repo file access (return empty results)
• Ollama binary install and model-hub pull (return 403)
• MCP servers that are marked as requiring network access

What air-gap does not block: your LLM provider's own traffic. If you have a cloud LLM configured, those messages still go out. Use a local provider for complete isolation.

Known limitation: the warning banner in Settings only fires when your provider preset is specifically openai. If you have Anthropic, Groq, Azure, or another cloud preset configured with air-gap on, no banner appears. Check your provider selection manually.

The shell tool that the agent uses to run terminal commands has four independent layers of protection:

1. Blocked-pattern list. A fixed list of destructive and credential-reading commands is rejected before execution. This is hard-coded and applies regardless of permission mode.

2. Filtered child-process environment. Shell commands run with a curated subset of environment variables (paths, build-tool vars, locale) - not your full process.env. This prevents API keys, tokens, or other secrets set at the OS level from leaking into command output. Added in beta.26.

3. Output credential scanning. After every command, the output is scanned and matched secrets are replaced with [REDACTED: type] before the result reaches the agent. Patterns covered:

• SSH private keys
• AWS access keys (AKIA...)
• GitHub PATs (ghp_, gho_)
• OpenAI API keys (sk-..., sk-proj-...)
• Anthropic API keys (sk-ant-...)
• Slack tokens, JWTs, PGP private keys
• Database connection strings (mongodb://, postgres://, etc.)
• Inline secrets in KEY=value or KEY: "value" forms
• High-entropy base64 strings over 40 characters (git SHA hashes are excluded to avoid false positives)

4. Project-directory enforcement. The working directory cannot be outside your project root. The Windows type command (equivalent to cat) is also blocked to prevent indirect credential reads.

Approval behavior: In Ask mode (the default for new sessions), every shell command pauses for your approval before it runs. An approval card appears in the Agent panel with Accept and Reject buttons. Shell commands never auto-approve regardless of which mode is set - this is enforced at the route layer.

To change the approval mode, use the Ask / Act / Plan pill in the Agent panel header.

The Agent panel mode controls when the agent waits for your approval:

Switch modes with the pill in the Agent panel header. Research, Debug, and Advisor panels are always read-only regardless of this setting.

Shell Command Sandbox (Settings → Privacy & Safety → Content Filtering) adjusts what counts as "safe" in Ask and Act modes:

• Off - every shell command requires manual approval
• Moderate - safe commands auto-approve after a 30-second timeout
• Strict - only read-only commands auto-approve

Note: regardless of sandbox level, shell commands never auto-approve - that restriction is at the route layer, not just the tool. The sandbox level affects the approval UI flow, not the underlying security gate.

In Plan mode, the agent writes a plan and stops. Nothing touches your files until you approve. Plan approvals persist to the database - they survive disconnects and app restarts. You can close the app after the agent produces a plan and come back later; the approval card will still be there.

This is intentional for long-running or background sessions.

Tool-level approvals (Ask mode prompts for individual file writes or shell commands) work differently: they auto-reject on disconnect. If you close the app while a tool approval is pending, that specific operation is cancelled. The session continues when you reconnect.

The file_system tool the agent uses to read, write, and delete files is sandboxed to your open project folder. The boundary is set to whatever folder you opened in Code mode.

Requests that escape the boundary are rejected:

• Path traversal attempts (../)
• Absolute paths outside the project
• Symlinks whose real targets point outside the project (the symlink target is resolved against the actual filesystem, not the symlink path)

Write and append operations also block a set of dangerous file extensions.

Errors from out-of-bounds attempts appear as tool call failure cards in the Agent panel.

The shell tool uses a separate enforcement path. Its working directory is blocked from escaping the project root. These two sandboxes are independent - passing the file system sandbox check doesn't bypass the shell sandbox, and vice versa.

The web_fetch tool blocks requests to private network addresses. This prevents an agent from being tricked into fetching internal services on your network (Server-Side Request Forgery).

Blocked targets:

• All private IPv4 ranges: 127.x, 10.x, 192.168.x, 172.16–31.x, 169.254.x
• localhost, 0.0.0.0
• IPv6 loopback (::1), link-local (fe80::), and unique local (fc00::/7, covers fc* and fd*)
• IPv6-mapped IPv4 addresses (::ffff:)
• Decimal and hex integer IP notation (e.g. 2130706433 resolves to 127.0.0.1)

Only http: and https: are allowed. Other protocols are rejected.

DNS rebinding protection: after the hostname passes the initial check, it is resolved to an IP address and that IP is rechecked against the private ranges. This catches hostnames that look public but resolve to a private address.

The Research, Debug, and Advisor panels cannot write files or run shell commands. This is enforced in ToolPreExecutionGuards - the guard fires at the pre-execution layer, before any tool runs, regardless of what mode the Agent panel is set to.

If you need the agent to take an action based on what Research or Debug found, copy the relevant output and send it to the Agent panel. Research also has a Save to Knowledge Base button that pins findings without writing project files.

Guardrails apply filters to user messages before the agent processes them.

To configure:

1. Open Settings → Privacy & Safety → Content Filtering
2. Toggle Enable Guardrails on
3. Adjust the sub-settings below:

4. Click Save Safety Settings to apply

When Enable Guardrails is off, the entire Content Filtering section is dimmed and none of the sub-settings apply.

Custom Blocked Patterns are validated as you type - invalid regex lines show a red error with the line number. Changes don't apply until you save.

Each MCP server has a Network Access flag set when you add it in Settings → MCP Servers. When air-gap mode is on:

• Servers marked as requiring network access cannot connect
• New server additions with network access return 403
• If a network-access server is already connected, tool calls to it are intercepted and blocked at the pre-execution layer

The network access flag is self-reported at configuration time - the app cannot verify whether a server actually makes outbound calls. The flag defaults to true (network access required) for new servers, which is the safer default.

The legacy single-server MCP endpoint blocks entirely in air-gap mode, not just network-access servers.

Memory entries and knowledge base cards are stored in local SQLite. Every query includes a user_id filter - cross-user memory access is treated as a security bug, not a missing feature.

Nothing is synced or backed up externally. To see what the agent remembers, ask it: "What do you remember about me?" To remove a specific entry, say: "Forget [fact]".

Knowledge base entries are managed via gear menu → Knowledge.