When an AI agent writes code, runs commands, and touches your repos, “the AI did it” isn't an answer your auditor will accept. Bromure makes every session a structured, attributable record: who ran which agent, against what, and exactly what it touched.
The problem
AI-written code with no chain of custody
A growing share of your codebase is now drafted by agents — and the trail is thin. Which engineer launched the session? Which model? What files did the agent read, change, or delete? What commands did it run, and against which systems? For most teams the honest answer is a shrug, and a shrug doesn't survive a SOC 2 audit, a security incident, or a regulator's question.
The agent operates on the engineer's laptop, under the engineer's account, with the engineer's access. From the outside, an agent's commit is indistinguishable from a human's — until something goes wrong and you need to reconstruct exactly what happened, and there's nothing to reconstruct it from.
Bromure's answer
Every session is a tamper-resistant record
Because the agent runs inside a Bromure VM, every action is captured at the boundary: the files it created, modified, and deleted with diffs; every shell command it ran; every tool it called; every endpoint it reached — all tied to the engineer's identity and the model in use, retained centrally.
The full dialogue is archived too — prompts, model responses, tool calls, the entire transcript — kept in the cloud and reviewable by security, sampleable by engineering leadership, and exportable to the same archive you already feed for email and chat retention. AI-assisted work becomes as auditable as anything else your organization does.
How it works
Every file the agent touched
Per session, per repo, per engineer — the exact set of files created, modified, or deleted, with diffs, tied to who launched the session and the model they used.
Every command and call
Each shell command the agent executed inside the VM, each file it read, each tool it invoked, each API it hit — captured live as the session runs.
The full transcript, archived
Prompts, responses, and tool calls retained centrally, queryable by team, repo, or model, and exportable to your existing retention archive.
Identity-bound and tamper-resistant
Every record carries the engineer's SSO identity and device, written to an append-only stream your SIEM can ingest the way it ingests human activity.
Injection attempts, flagged
When the content an agent read — a file, a fetched page, tool output — or a CLAUDE.md it trusted carried injected instructions, Bromure's on-device detection records it: the source, the snippet, and whether the request was logged, flagged, or blocked.
In practice
Reconstructing a session, months later
A security review asks a simple question: did any agent ever touch the payments module, and if so, what did it do? Without Bromure, that's an unanswerable question spread across dozens of laptops. With it, it's a query.
Every agent session ran inside a Bromure VM that streamed its activity to the enterprise server: the engineer's identity, the model, every file read and write with diffs, every command, every network destination, and the full prompt/response transcript. The reviewer filters to the payments repo and gets every session that touched it — three of them, two engineers, with the exact changes and the conversations that produced them.
They sample the transcripts, confirm the changes were reviewed and merged through the normal process, and attach the export to the audit file. What would have been a multi-day forensic scramble is a ten-minute query — and because the record is tamper-resistant, it stands up as evidence rather than recollection.
Stream it to your SIEM
The trail doesn't have to live in Bromure
Point Bromure at your own SIEM or OpenTelemetry Collector and the whole record follows you there. Agent activity, browser sessions, and the admin audit trail forward as OTLP/HTTP logs — each event a LogRecord with OTel semantic attributes and a severity your alerts already understand. Bromure ships from its own stored events on a rolling cursor, so a blip at your endpoint loses nothing.
Point it at your collector
Give Bromure your OTLP/HTTP logs endpoint and, if your collector needs one, an auth header — a bearer token, a Datadog key, whatever it expects. The value is stored envelope-encrypted and never shown again. Pick which of the three streams to forward.
Every agent action maps to a LogRecord carrying the engineer's SSO identity, the model, the repo, and the action — with a severity your SIEM can alert on. A blocked prompt-injection attempt arrives as a WARN your detection pipeline already routes.
Bromure forwards from its own stored events with a per-stream cursor, not from the live ingest path. If your collector goes down, nothing within retention is lost — delivery resumes from the last acknowledged position when it returns.
stream cursor last forward status
agentic_coding seq:184201 2s ago ok
web_sessions ts:17:42:08 2s ago ok
audit id:90412 2s ago ok
# endpoint outage → backoff + retry, cursor holds
# at-least-once · no loss within retention
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
How is this different from Git history?
+
Git shows the final committed diff. Bromure shows the whole session that produced it — the files the agent read but didn't change, the commands it ran, the dead ends, the network calls, and the conversation that drove it. Git tells you what landed; Bromure tells you how, and what else happened along the way.
Is the record tamper-resistant?
+
Yes. Sessions stream to an append-only log on your enterprise server as they run, carrying the engineer's SSO identity and device certificate. An engineer can't quietly edit what their agent did after the fact.
Can we feed this into our existing SIEM and retention tools?
+
Yes — natively, over OpenTelemetry. Point Bromure at your SIEM or OpenTelemetry Collector's OTLP/HTTP logs endpoint and agent activity, browser sessions, and the audit trail stream there as OTLP log records with OTel semantic attributes. Transcripts export separately to the same archive you already use for email and chat retention.
Does capturing all this slow engineers down?
+
No. Capture happens at the VM boundary, out of the engineer's way. They run Claude Code or Codex exactly as before; the record accrues automatically.
“The AI did it” is not an audit trail.
Make every agent session an attributable, tamper-resistant record your auditors will accept.