Bromure puts a host-side proxy between an AI agent and every real credential

Two sibling apps share one tree, and only one has a release train

The repository description states the split plainly: this repo ships two sibling apps, both built on Apple's Virtualization.framework. Bromure is the browser, where every browser session runs in a throwaway Linux VM and closing the window destroys it. Bromure Agentic Coding is the sandbox for AI coding agents, named as Claude Code, Codex, Grok, Kimi Code and Oh My Pi. Written in Swift, MIT licensed, default branch main, homepage bromure.io, 294 stars and 17 forks at capture time, with 3 open issues. Now look at the releases. All three recent tags are named for the coding half only: agentic-coding-v5.0.0 on 2026-09-26, agentic-coding-v5.0.1 on 2026-09-29, and agentic-coding-v5.0.2 on 2026-09-30. Three tags in five days, none of them for the browser. The last push to main was 2026-09-30, so the project is plainly active; the asymmetry is about release discipline rather than activity, and it means the versioning you can see tells you nothing about how the browser app is distributed.

The credential trick is a wire swap, so there is no read path at all

This is the part that is genuinely different from the usual secret manager, and it is worth understanding precisely. The mechanism is a host-side MITM proxy. Inside the VM the agent sees fake credentials; on the wire the proxy exchanges those stubs for the real values, which never cross into the guest. The consequence is structural rather than procedural: there is no file for the agent to read, no environment variable to print, and no prompt to talk it out of, because the real value simply does not exist anywhere the agent can address. Everything else hangs off that same point. Supply-chain scanning runs there, with an age gate plus OSV, socket.dev and Depi as the named sources of verdicts. Prompt-injection detection runs there, using PromptGuard with ModernBERT. PII protection runs there too, swapping personal data on-device and restoring it in replies so the provider never receives it. The multi-model panel, local inference and remote access are all described as enforced at that one boundary. That concentration is the design, and it is also the single thing to trust or not trust.

Hiding a token is not the same as governing how it gets spent

The README makes an argument here rather than a list of features, and the argument is the sharpest writing in the repository. Keeping a raw value out of the sandbox does not stop the sandbox from spending it. Take Docker Sandboxes as the named example: it holds the raw credential outside the VM, but its proxy still attaches that credential to any outbound request the sandbox makes, so a package installed on the side can spend it against an allow-listed domain without ever seeing the value. Bromure's answer is governance rather than hiding: per-destination consent, a read-only option, and a TTL, layered on top of scanning the package before it runs. The same table notes that Capsem isolates with a hardware VM but leaves real API keys living inside the guest, and that Dev Container forwards the SSH agent and git credentials. Read the footnotes under the table too, because they concede the weak spots: the comparison was compiled from each project's public documentation in June 2026, Docker Sandboxes is called an experimental preview whose brokered credentials stay usable by anything inside the VM, and octokraft's agent-vault is noted as distinct from Infisical's product of the same name.

Eleven plan documents and ten CI variants are most of the visible tree

The top-level listing tells you what this project is actually made of, and it is heavier on intentions than on source. Naming the plan files one by one: BROWSER_PANE_PLAN.md, IOS_CLIENT_PLAN.md, NATIVE_TERMINAL_PLAN.md, REMOTE_FAT_CLIENT_PLAN.md, REMOTE_P2P_PLAN.md, SWITCHBOARD_PLAN.md, REMOTE_CONTROL.md, REMOTE_CONTROL_AC.md, PREBUILT_IMAGE.md, PROXY.md, SETTINGS_AGENTIC.md and TEST_PLAN.md, alongside BUILD_INSTRUCTIONS.md, CLAUDE.md and a whitepaper directory. Then the build pipeline: one Jenkinsfile plus ten variants named ac, acscreenshots, browser-image, e2e, e2e.ac, image, ios.testflight, resolv-stub and spaces. Directories cover Sources, Tests, Resources, ios, mcp-server, tools, scripts, shaders, manual and manual-web, with build.sh, build_and_copy.sh and package.sh at the root. Two things follow. First, remote access from a Mac, an iPhone, an iPad, the CLI or SSH is clearly the centre of gravity, and iOS is a first-class target rather than an afterthought. Second, the README documents no install command at all; downloads and full details live at bromure.io, so anything you run has to come from the website or from those build scripts.

The productivity stack is bolted to the same proxy it depends on

What makes this unusual for a security tool is how much collaboration software is attached to the isolation boundary. Agents can work in teams through rooms, a Switchboard for handing off work, and @-delegation, and the multi-model fusion panel judges and synthesises across models on the wire. Automations cover schedules, GitHub events, Linear events and chained runs. Local models run on your own silicon through on-device MLX, alongside any hosted provider. There is a k3s cluster and a private registry next to the sandbox, an isolated Chromium instance the agent drives to test its own work, and remote attachment from Mac, iPhone, iPad, CLI or SSH. On the accounting side, token usage is broken down per file, per repo and per model, and the supply-chain inventory keeps every dependency with its verdict, searchable; both rollups are said to be surfaced in Bromure Enterprise Manager. Against that, the audit row is where the comparison is least flattering to anyone: container logs only for Dev Container, full HTTP bodies stored in SQLite for Docker Sandboxes, and a full encrypted session trace here.

The name collides with bromide salts, so the tags carry the qualifier

A practical warning before you go looking for this project, because the name is phonetically dangerous. Bromure is nearly a spelling of bromide, and French drug labelling writes a long list of bromide salts with exactly this prefix: bromure de potassium, bromure de sodium, bromure de rocuronium, bromure de butylhyoscine, bromure de pyridostigmine, bromure ipratropium, bromure de pinavérium. The bare name therefore pulls you toward pharmacology rather than toward a macOS sandbox, and none of those will mention Virtualization.framework. The workaround is in the project's own naming, because the release tags say Bromure Agentic Coding and the description field says the same. Those two extra words are what find the real thing. It also tells you something about the audience: this is a project whose name needs a qualifier to be findable at all. Once you have the repository, judge the security claims on the mechanism rather than on the marketing, and do not expect to find an outside comparison, because here the comparison is written by the vendor and footnoted as compiled in June 2026.

Editorial conclusion

Bromure fits a Mac owner who wants a coding agent to run code without any possibility of reading a real credential, and who accepts a heavyweight boundary in exchange for that guarantee. It does not fit a Linux user, a headless CI job, or anyone treating the feature matrix as neutral evidence, because the grading table is written by the tool being graded and carries a June 2026 timestamp next to three releases in late September. Before installing, check which of the two siblings you actually want, since only the coding app has a visible release train, and read the eleven plan documents at the top of the tree to see how much of the roadmap is written down rather than shipped.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes