The useful part of an uncomfortable warning

Bandura can connect to Anthropic, Gemini, or an OpenAI-compatible /chat/completions endpoint. Its provider documentation says the desktop app uses the operating system's encrypted store: Keychain on macOS, DPAPI on Windows, and libsecret on Linux. Local Ollama and LM Studio endpoints can run without an API key.

Linux complicates that description. If the machine has no system keyring, the intended protection is unavailable. In Bandura 1.0.0-rc.7, the app started saying that keys are only weakly protected in this situation. The release also restricted the stored-key file so other local accounts could not read it and tightened existing permissions when the new version first opened it.

The important choice was to stop using reassuring language when the operating system could not support it. A warning does not strengthen the fallback, but it changes the user's options. They can install a keyring, use a local model that needs no key, or keep that credential off the machine.

Treat “encrypted store” as a conditional claim. Which store is used on each operating system? What happens when it is absent? Is the fallback permission-restricted, and does the interface describe it plainly?

Local AI has several security boundaries

Bandura's recent changes separate concerns that product pages often compress into one word.

The secret at rest

An API key needs protection from other accounts and processes on the same machine. Bandura's security page names its local files, the protection applied to each one, and the Linux keyring fallback. This is the familiar boundary, but it is only the starting point.

The prompt leaving the app

A correctly stored key can still leak after an application builds a prompt. Bandura rc.7 stopped showing the assistant credentials embedded in URLs. That matters because developers copy URLs from terminals, configuration files, and debugging tools, where user information or tokens sometimes appear inline. Secret storage cannot help once the application has placed a credential in model input.

The same question applies when an OpenAI-compatible client points at a service such as api.ish.chat. Wire compatibility determines the request format. The client still decides which URLs, files, history, and workspace fragments enter that request.

The searchable copy

Bandura rc.5 introduced a local SQLite full-text index so its assistant can search a workspace without an embedding service or another network request. Before anything is indexed, the security documentation says Bandura excludes values under credential-shaped names such as Authorization, api-key, and client_secret. It also drops text matching common secret formats, including bearer tokens, JWTs, private keys, and major provider key formats.

Keeping an index on the laptop does not make it harmless. An index creates another persistent copy and can make a forgotten secret easier for an assistant to retrieve. Filtering before the write is stronger than redacting only when search results are displayed.

Pattern filters have limits. They cannot prove that every credential format will be recognized. They reduce exposure, but they do not replace secret scanning, short-lived keys, or the simpler rule that credentials should stay outside a workspace.

The folder the agent may touch

Bandura rc.6 tightened the file paths available to the assistant inside an open workspace. Its workspace documentation describes that workspace as an ordinary folder and says the application reads and writes within it.

This is the same boundary problem we examined in LM Studio's Bionic shell and environment-aware command judging. Tool safety depends on the environment and authority around a model's proposed action. A write approval helps, but it should sit above a hard path boundary, not stand in for one.

Five checks before connecting a repository

Before giving a desktop assistant both a codebase and an API key, check the following:

1. Key storage: Verify the mechanism on every supported operating system and inspect the no-keyring fallback.
2. Outbound context: Identify which prompts, files, URLs, response bodies, and saved chat reach the configured model.
3. Derived local data: Find indexes, summaries, logs, caches, and history databases. Check how they exclude secrets and how they are deleted.
4. Tool authority: Confirm that reads and writes remain inside the selected workspace and that approvals gate the mutations they claim to gate.
5. Headless behavior: Review CI and CLI separately. They commonly receive keys through environment variables rather than the desktop store. Bandura documents BANDURA_AI_API_KEY and provider-specific fallbacks, so this is a distinct deployment path.

Feature-level wording matters. Bandura's ordinary workflow functions can run without an AI provider. A local model can avoid provider traffic. Its workspace index uses no embedding service. When hosted AI features run, the prompt and required flow context go to the endpoint the user selected. A blanket “nothing leaves your machine” claim would blur these different modes.

Read the warning, then test the boundary

Bandura remains release-candidate software, and the details discussed here come from its own documentation. They are not the result of an independent security audit. Still, the documentation demonstrates a useful discipline: identify the files, name the operating-system mechanism, explain the fallback, separate local indexing from remote inference, and state when protection is weak.

That precision gives a user something to verify. On Linux, they can check whether a keyring is actually available. In a workspace, they can plant a harmless test string shaped like a credential and confirm that search does not return it. In a proxy log, they can inspect what the assistant sends to its provider. The word local cannot answer those questions. The product's behavior can.