Point the agent at code you don't trust. Lose nothing when it bites.
Agents clone third-party repos, install dependencies, and run build scripts written by strangers. A malicious postinstall hook or an instruction buried in a README shouldn't reach your tokens, your keys, or your network. In a Bromure VM, it can't.
The problem
Every npm install is remote code execution
The moment an agent runs `npm install`, `pip install`, or a Makefile from an untrusted repo, arbitrary code from people you've never met executes with your engineer's privileges. A poisoned postinstall script, a typosquatted package, a build step that phones home — each runs as the user, with the user's SSH keys, cloud credentials, and environment one syscall away.
Agentic coding makes this more frequent and more dangerous. The agent enthusiastically clones the repo a ticket pointed it at, installs whatever the lockfile says, and runs the test suite — and a prompt injection in the project's README can steer it toward “just run this setup script” before a human ever reviews a line.
Bromure's answer
The blast radius is a VM that's about to be deleted
Bromure runs the agent — and everything it executes — inside a disposable Linux VM with its own kernel, filesystem, and network stack. The untrusted repo, its dependencies, and its build scripts run there, not on the engineer's laptop. Real credentials never enter the VM; the agent reaches Git and package registries through a proxy that holds the secrets.
If a postinstall hook tries to read `~/.ssh`, exfiltrate an env var, or open a reverse shell, it finds an ephemeral VM with no real secrets, egress locked to an allow-list, and nothing of yours to steal. When the task ends the VM is destroyed, and whatever the package planted goes with it. And if the README or a build script tries to steer the agent itself, Bromure's on-device prompt-injection detection flags the attempt — so a hostile instruction is caught, not just contained.
How it works
Credentials never enter the room
Git and registry access run through a credential proxy. The agent and the untrusted code it runs get scoped, short-lived access — they never see a real token or SSH key.
Egress on a leash
Network access is allow-listed per profile. A dependency that beacons to a fresh domain or an IP literal is blocked, and the attempt shows up in the log.
Ephemeral build environment
Clone, install, and build all happen in a VM destroyed at task end. A persistent implant has nothing persistent to live in.
Injection caught, not just contained
An on-device classifier scans what the agent reads — READMEs, code comments, fetched pages, tool output — and the CLAUDE.md-style rules files it trusts, for instructions that try to steer it. The attempt is flagged or blocked before the model acts, not merely sandboxed after.
Untrusted by default
New repos get the locked profile automatically — downloads contained, secrets proxied, egress restricted — so “run the agent on this external project” is safe before anyone vets it.
In practice
What happens when the package is hostile
An engineer asks the agent to evaluate an open-source library a ticket suggested. The agent clones the repo into a fresh Bromure VM and runs `npm install`. Unknown to anyone, one transitive dependency ships a postinstall script that reads environment variables and POSTs them to an attacker's endpoint.
Inside the VM, the script runs — and finds nothing worth taking. There are no real credentials in the environment; Git and the registry were reached through the proxy, which never exposed a token. The POST to the attacker's domain isn't on the profile's egress allow-list, so it's dropped and logged. The session record shows the read of the environment, the blocked connection, and the destination.
The engineer reads the report, flags the package, and closes the session. The VM — and the implant, the modified files, the cached payload — is destroyed. The laptop never ran a line of the hostile code, and the only thing the attacker learned is that the door was locked.
Architecture & integration
How it's actually built
The marketing stops here. What follows is the technical substrate every Bromure deployment sits on — the same whether you're protecting a BYOD workforce or segregating classification levels inside a regulated agency.
Hypervisor-enforced isolation
Each profile runs in its own lightweight Linux VM on top of Apple's Virtualization.framework — a separate kernel, filesystem, and network stack from the host. The base image is a signed, reproducible Alpine build cloned via APFS copy-on-write at session launch (near-zero disk cost). The host cannot read VM memory; the VM cannot read the host's clipboard, filesystem, or network adapters unless profile policy explicitly allows it.
Identity: SSO for users, mTLS for devices
Enrollment and session launch are gated by two factors your organization already operates. OIDC / SAML against Google Workspace, Okta, Microsoft Entra, or Authentik identifies the user. A per-device mTLS client certificate, issued from your PKI and bound to the installation, identifies the machine. Revoke either and the next session fails to launch — no agent to tamper with, no local policy to edit around.
Profile-as-code
The work profile — allowed SaaS list, download / clipboard / screenshot posture, VPN configuration, keyboard layout, root CAs, network egress rules — is a signed declarative artifact. Version it in Git. Push it through your MDM or the Bromure config endpoint. Tampered profiles fail signature verification and the session refuses to start. What runs on the user's machine is bit-for-bit what you authored.
Per-profile network plane
Each profile carries its own virtual NIC. Choose NAT through the host, bridge to a physical interface, or tunnel via WireGuard, IKEv2 / IPsec, or Cloudflare WARP — all terminated inside the VM, invisible to the host. Layer on DNS overrides, outbound port whitelists, LAN isolation, and an HTTP proxy. Segmentation is enforced by the hypervisor, not by a sticker on the firewall.
Audit pipeline
Every request — timestamp, verb, URL, status, user, profile, device — is captured outside the VM in a tamper-resistant JSON Lines stream and delivered to the log sink you already feed (SIEM, data lake, retention archive). Optional headers-only or full-body session recording for suspicious traffic. Stable schema, documented fields, no vendor lock-in on the format.
Ephemeral by default, persistent by opt-in
Close the window, the VM is destroyed. Tokens, cookies, cache, downloads, and any malware that landed during the session go with it. Profiles that need state — a bookmarks set, a saved session, a logged-in SaaS — opt into a LUKS-encrypted persistent disk keyed to the macOS Keychain. The key never leaves the user's device.
Common questions
Doesn't a container or a fresh CI runner already do this?
+
Containers share the host kernel and are routinely escaped; CI runners often hold the very deploy credentials an attacker wants. Bromure uses hardware-isolated VMs with their own kernel and keeps real secrets out of the VM entirely behind a proxy — so even a kernel-level escape finds nothing to steal.
How does the agent push code or install private packages without secrets?
+
Through the credential proxy. It authenticates to your Git host and private registries on the VM's behalf, injecting scoped, short-lived access at the network layer. The agent gets working Git and npm; it never gets a credential it could exfiltrate.
What stops a prompt injection in a README from escalating?
+
Two layers. First, Bromure's on-device detection scans the content the agent reads — READMEs, comments, fetched pages, tool output — and the CLAUDE.md-style rules files it trusts, and flags or blocks injected instructions before the model acts. And even if one slips through, it executes inside the VM — no real credentials, allow-listed egress, no host reach — so the worst case is wasted compute in a sandbox that's about to be deleted, all of it logged.
Can we still get the build artifacts we wanted?
+
Yes. Legitimate outputs are promoted out of the VM through the same controlled path as any download — optionally VirusTotal-gated — so you keep the result without keeping the risk.
Run the untrusted repo. Keep your keys.
Give agents a build environment where hostile code finds nothing and leaves nothing behind.