Production Access

Let the agent into production. Approve before it mutates.

Debugging a live incident or running a migration means giving an agent real production access — and real production access is exactly what you can't hand an autonomous loop. Bromure lets the agent read freely, then stops at the door of every mutating action and asks you first.

The problem

Read access is fine. It's the writes that end careers.

An agent that can query production is a debugging superpower. An agent that can `DROP TABLE`, `terraform apply`, delete a bucket, or push a hotfix is one confident hallucination away from an outage. The same loop that reads the logs to find the bug will, unprompted, “fix” it against the live system.

So teams do the safe thing and keep agents out of production entirely — and lose the one place agents are most useful: the live incident, the data-shaped bug, the migration that only fails on real data. The choice on offer is autonomy you can't trust or access you won't grant.

Bromure's answer

Reads flow. Mutations stop and wait for a human.

Bromure runs the agent inside a VM that reaches production only through a credential proxy — and the proxy knows the difference between a read and a write. Queries, gets, and describes pass straight through. Anything that mutates state — a write, a delete, a DDL statement, a deploy, a destructive API call — pauses and surfaces a permission prompt showing the exact operation, for the engineer to approve or deny before it runs.

The agent keeps its momentum on everything safe and blocks only where it matters. You see precisely what it's about to do — the SQL, the API call, the resource — and nothing touches production until you say yes. Deny it, and the agent gets the rejection and adapts, the same as any other tool error.

How it works

Read-through, write-gated

The proxy classifies every operation. Read-only calls pass without friction; mutating calls halt for explicit human approval. Agent speed where it's safe, a hard stop where it isn't.

See exactly what it'll do

Each prompt shows the literal operation — the SQL statement, the API verb and target, the resource being changed — before it executes. No blind “allow all.”

Credentials never reach the agent

Production access is injected by the proxy at the network layer. The agent operates against prod without ever holding a credential it could leak or misuse.

Every decision recorded

Approvals, denials, and the operations behind them are logged per session and engineer — a complete record of what the agent did to production and who allowed it.

In practice

An agent on a live incident, without the cold sweat

It's 2 a.m. and a service is throwing errors on a subset of rows. An engineer points their agent at the production replica through Bromure. The agent queries the live data, correlates it with recent deploys, and narrows the bug to a malformed column written by a migration three hours ago — all read-only, all flowing without interruption.

The agent proposes the fix: an `UPDATE` against the affected rows. Because that mutates production, Bromure pauses. A permission prompt shows the engineer the exact statement — table, predicate, estimated row count — and waits. The engineer reads it, tightens the `WHERE` clause, and approves. Only then does the write reach the database.

The incident closes in twenty minutes instead of two hours. The session record shows every query the agent ran, the single mutation it proposed, the engineer's edit, and the approval — so the post-mortem writes itself, and nobody has to wonder whether the agent quietly did anything else.

Policy as config

Define what's gated in one policy block

The proxy's read/write classification is declarative. Pass a policy per profile and the agent inherits it on every session. Here's the shape for the backends teams gate most.

MongoDB / ClickHouse

Reads — finds, aggregations, SELECTs — pass; inserts, updates, deletes, and DDL gate by default. Optionally carve out a scratch database the agent may mutate freely.

[proxy.mongodb]
mode = "read-through"
# find / aggregate / count pass without prompting
gate = ["insert", "update", "delete", "drop"]

[proxy.clickhouse]
mode = "read-through"
# SELECT passes; writes and DDL gate
gate = ["INSERT", "ALTER", "DROP", "TRUNCATE"]
# allow unprompted writes only here
allow_write_databases = ["scratch"]

AWS, Kubernetes & cloud APIs

Describe / list / get calls pass; anything that creates, changes, or deletes a resource — a cloud resource or a Kubernetes object — prompts for approval with the full request shown.

[proxy.aws]
mode = "read-through"
allow_verbs  = ["Describe*", "List*", "Get*"]
gate_verbs   = ["Create*", "Update*", "Put*", "Delete*", "Terminate*"]
show_request = true

[proxy.kubernetes]
mode = "read-through"
# get / list / watch pass
gate_verbs = ["create", "apply", "patch", "delete", "scale", "exec"]

HTTP & internal services

GET and HEAD flow; POST, PUT, PATCH, and DELETE to production hosts gate. Scope by host so staging stays frictionless.

[proxy.http]
read_methods = ["GET", "HEAD"]
gate_methods = ["POST", "PUT", "PATCH", "DELETE"]

[[proxy.http.hosts]]
match = "*.prod.internal"
gate  = true

[[proxy.http.hosts]]
match = "*.staging.internal"
gate  = false

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 does Bromure know a call is a mutation?

The credential proxy understands the protocols it brokers — SQL, cloud APIs, HTTP verbs, Git. It classifies operations by effect: SELECT and GET pass; INSERT/UPDATE/DELETE/DDL, write APIs, and destructive calls are gated. Tune the policy per profile — gate everything, or allow writes to a scratch schema while gating the rest.

Does the prompt slow every action down?

Only mutations prompt. The vast majority of what an agent does against production while debugging is read-only, and that flows at full speed. The human is in the loop precisely and only where state changes.

What does the agent see when I deny?

A normal tool rejection. The agent treats it like any failed call — it can explain, propose an alternative, or ask for guidance — without the mutation ever having happened.

Can I approve a batch of operations at once?

Yes. Approvals can be granted per-operation or scoped — approve a class of operation for the rest of the session, or pre-authorize a specific migration — with every grant recorded. The default is tight; you loosen it deliberately.

Isn't this just a fancy `--dry-run`?

No. A dry-run shows what would happen and still needs a blind real re-run. Bromure gates the real call itself: the agent is mid-execution, you see the exact operation, and your approval is what lets it proceed — or not. Nothing runs twice, and nothing runs unapproved.

Give the agent production. Keep your hand on the switch.

Read-through, write-gated access that lets agents work on live systems without ever mutating them behind your back.

Try it — free Contact us