Lassen Sie den Agenten in die Produktion. Genehmigen Sie, bevor er mutiert.
Einen Live-Incident zu debuggen oder eine Migration auszuführen, heißt, einem Agenten echten Produktionszugriff zu geben — und echter Produktionszugriff ist genau das, was Sie einer autonomen Schleife nicht überlassen können. Bromure lässt den Agenten frei lesen, hält dann an der Tür jeder mutierenden Aktion an und fragt zuerst Sie.
Das Problem
Lesezugriff ist in Ordnung. Es sind die Writes, die Karrieren beenden.
Ein Agent, der Produktion abfragen kann, ist eine Debugging-Superkraft. Ein Agent, der `DROP TABLE`, `terraform apply` ausführen, ein Bucket löschen oder einen Hotfix pushen kann, ist eine selbstbewusste Halluzination von einem Ausfall entfernt. Dieselbe Schleife, die die Logs liest, um den Bug zu finden, „behebt“ ihn unaufgefordert am Live-System.
Also tun Teams das Sichere und halten Agenten ganz aus der Produktion heraus — und verlieren den einen Ort, an dem Agenten am nützlichsten sind: den Live-Incident, den datenförmigen Bug, die Migration, die nur an echten Daten scheitert. Die angebotene Wahl ist Autonomie, der Sie nicht trauen können, oder Zugriff, den Sie nicht gewähren wollen.
Bromures Antwort
Reads fließen. Mutationen halten an und warten auf einen Menschen.
Bromure führt den Agenten in einer VM aus, die Produktion nur über einen Zugangsdaten-Proxy erreicht — und der Proxy kennt den Unterschied zwischen einem Read und einem Write. Abfragen, Gets und Describes gehen direkt durch. Alles, was Zustand mutiert — ein Write, ein Delete, ein DDL-Statement, ein Deploy, ein destruktiver API-Aufruf — pausiert und zeigt eine Berechtigungsabfrage mit der exakten Operation, die der Engineer genehmigen oder ablehnen kann, bevor sie läuft.
Der Agent behält seinen Schwung bei allem Sicheren und blockiert nur dort, wo es zählt. Sie sehen präzise, was er gleich tun will — das SQL, den API-Aufruf, die Ressource —, und nichts berührt die Produktion, bis Sie Ja sagen. Lehnen Sie es ab, bekommt der Agent die Zurückweisung und passt sich an, genauso wie bei jedem anderen Tool-Fehler.
So funktioniert es
Read-Through, Write-Gated
Der Proxy klassifiziert jede Operation. Nur-lesende Aufrufe gehen reibungslos durch; mutierende Aufrufe halten für eine explizite menschliche Genehmigung an. Agenten-Tempo, wo es sicher ist, ein harter Stopp, wo nicht.
Sehen Sie genau, was er tun wird
Jede Abfrage zeigt die wörtliche Operation — das SQL-Statement, das API-Verb und sein Ziel, die zu ändernde Ressource —, bevor sie ausgeführt wird. Kein blindes „alles erlauben“.
Zugangsdaten erreichen den Agenten nie
Produktionszugriff wird vom Proxy auf der Netzwerkschicht injiziert. Der Agent operiert gegen Prod, ohne je Zugangsdaten zu halten, die er lecken oder missbrauchen könnte.
Jede Entscheidung aufgezeichnet
Genehmigungen, Ablehnungen und die dahinterliegenden Operationen werden pro Sitzung und Engineer protokolliert — ein vollständiger Nachweis darüber, was der Agent an der Produktion getan hat und wer es erlaubt hat.
In der Praxis
Ein Agent an einem Live-Incident, ohne den kalten Schweiß
Es ist 2 Uhr nachts, und ein Service wirft Fehler für eine Teilmenge von Zeilen. Ein Engineer richtet seinen Agenten über Bromure auf das Produktions-Replikat aus. Der Agent fragt die Live-Daten ab, korreliert sie mit jüngsten Deploys und grenzt den Bug auf eine fehlerhafte Spalte ein, die vor drei Stunden von einer Migration geschrieben wurde — alles nur-lesend, alles ohne Unterbrechung fließend.
Der Agent schlägt die Behebung vor: ein `UPDATE` gegen die betroffenen Zeilen. Weil das die Produktion mutiert, pausiert Bromure. Eine Berechtigungsabfrage zeigt dem Engineer das exakte Statement — Tabelle, Prädikat, geschätzte Zeilenzahl — und wartet. Der Engineer liest es, schärft die `WHERE`-Klausel und genehmigt. Erst dann erreicht der Write die Datenbank.
Der Incident schließt in zwanzig Minuten statt in zwei Stunden. Der Sitzungsdatensatz zeigt jede Abfrage, die der Agent ausführte, die einzige vorgeschlagene Mutation, die Bearbeitung des Engineers und die Genehmigung — sodass sich das Post-mortem von selbst schreibt und niemand sich fragen muss, ob der Agent still noch etwas anderes getan hat.
Policy as Config
Definieren Sie in einem Policy-Block, was gegated ist
Die Read/Write-Klassifizierung des Proxys ist deklarativ. Übergeben Sie eine Policy pro Profil, und der Agent erbt sie in jeder Sitzung. Hier ist die Form für die Backends, die Teams am häufigsten gaten.
MongoDB / ClickHouse
Reads — Finds, Aggregationen, SELECTs — gehen durch; Inserts, Updates, Deletes und DDL gaten standardmäßig. Optional können Sie eine Scratch-Datenbank ausnehmen, die der Agent frei mutieren darf.
Describe- / List- / Get-Aufrufe gehen durch; alles, was eine Ressource erstellt, ändert oder löscht — eine Cloud-Ressource oder ein Kubernetes-Objekt — fragt mit der vollständig angezeigten Anfrage nach Genehmigung.
Hier endet das Marketing. Was folgt, ist das technische Fundament, auf dem jedes Bromure-Deployment sitzt — ob Sie eine BYOD-Belegschaft schützen oder Klassifizierungsstufen innerhalb einer regulierten Behörde trennen.
Hypervisor-erzwungene Isolation
Jedes Profil läuft in einer eigenen, leichten Linux-VM auf Basis von Apples Virtualization.framework — mit eigenem Kernel, eigenem Dateisystem und eigenem Netzwerk-Stack, getrennt vom Host. Das Base-Image ist ein signierter, reproduzierbarer Alpine-Build, beim Sitzungsstart via APFS Copy-on-Write geklont (nahezu kein Plattenplatz-Overhead). Der Host kann den VM-Speicher nicht lesen; die VM kann weder Clipboard, Dateisystem noch Netzwerkadapter des Hosts lesen — es sei denn, die Profil-Richtlinie erlaubt es ausdrücklich.
Identität: SSO für Nutzer, mTLS für Geräte
Enrollment und Sitzungsstart sind durch zwei Faktoren abgesichert, die Ihre Organisation bereits betreibt. OIDC / SAML gegen Google Workspace, Okta, Microsoft Entra oder Authentik identifiziert den Nutzer. Ein pro Gerät ausgestelltes mTLS-Client-Zertifikat, aus Ihrer PKI und an die Installation gebunden, identifiziert die Maschine. Widerrufen Sie eines von beiden — und die nächste Sitzung startet nicht. Kein Agent zum Manipulieren, keine lokale Richtlinie, die sich umgehen lässt.
Profile-as-Code
Das Arbeitsprofil — erlaubte SaaS-Liste, Download-/Clipboard-/Screenshot-Haltung, VPN-Konfiguration, Tastaturlayout, Root-CAs, Netzwerk-Egress-Regeln — ist ein signiertes, deklaratives Artefakt. Versionieren Sie es in Git. Verteilen Sie es über Ihr MDM oder den Bromure-Config-Endpoint. Manipulierte Profile fallen durch die Signaturprüfung, und die Sitzung weigert sich zu starten. Was auf der Maschine des Nutzers läuft, ist bitgenau das, was Sie verfasst haben.
Netzwerk-Ebene pro Profil
Jedes Profil bringt seine eigene virtuelle NIC mit. Wählen Sie NAT über den Host, Bridge auf ein physisches Interface oder Tunneling via WireGuard, IKEv2 / IPsec oder Cloudflare WARP — alles in der VM terminiert, für den Host unsichtbar. Legen Sie DNS-Overrides, ausgehende Port-Whitelists, LAN-Isolation und einen HTTP-Proxy darüber. Segmentierung wird vom Hypervisor erzwungen — nicht von einem Aufkleber auf der Firewall.
Audit-Pipeline
Jede Anfrage — Zeitstempel, Verb, URL, Status, Nutzer, Profil, Gerät — wird außerhalb der VM in einem manipulationssicheren JSON-Lines-Stream erfasst und an den Log-Sink geliefert, den Sie bereits befüllen (SIEM, Data Lake, Retention-Archiv). Optional Headers-Only oder vollständige Sitzungsaufzeichnung für verdächtigen Traffic. Stabiles Schema, dokumentierte Felder, kein Vendor-Lock-in auf das Format.
Ephemer per Default, persistent nur auf Wunsch
Fenster schließen — die VM wird zerstört. Tokens, Cookies, Cache, Downloads und jede Malware, die während der Sitzung gelandet ist, gehen mit. Profile, die Zustand brauchen — ein Bookmarks-Set, eine gespeicherte Sitzung, eine eingeloggte SaaS — können optional eine LUKS-verschlüsselte persistente Disk aktivieren, mit einem Schlüssel im macOS-Keychain. Der Schlüssel verlässt das Gerät des Nutzers nie.
Häufige Fragen
Woher weiß Bromure, dass ein Aufruf eine Mutation ist?
+
Der Zugangsdaten-Proxy versteht die Protokolle, die er vermittelt — SQL, Cloud-APIs, HTTP-Verben, Git. Er klassifiziert Operationen nach Wirkung: SELECT und GET gehen durch; INSERT/UPDATE/DELETE/DDL, schreibende APIs und destruktive Aufrufe werden gegated. Stimmen Sie die Policy pro Profil ab — gaten Sie alles, oder erlauben Sie Writes auf ein Scratch-Schema, während Sie den Rest gaten.
Verlangsamt die Abfrage jede Aktion?
+
Nur Mutationen fragen nach. Die überwiegende Mehrheit dessen, was ein Agent beim Debuggen gegen Produktion tut, ist nur-lesend, und das fließt mit voller Geschwindigkeit. Der Mensch ist genau und nur dort in der Schleife, wo sich Zustand ändert.
Was sieht der Agent, wenn ich ablehne?
+
Eine normale Tool-Zurückweisung. Der Agent behandelt sie wie jeden fehlgeschlagenen Aufruf — er kann erklären, eine Alternative vorschlagen oder um Orientierung bitten —, ohne dass die Mutation je stattgefunden hat.
Kann ich eine Reihe von Operationen auf einmal genehmigen?
+
Ja. Genehmigungen können pro Operation oder abgegrenzt erteilt werden — genehmigen Sie eine Operationsklasse für den Rest der Sitzung oder autorisieren Sie eine bestimmte Migration vorab —, wobei jede Erteilung aufgezeichnet wird. Die Voreinstellung ist eng; Sie lockern sie bewusst.
Ist das nicht einfach ein schickes `--dry-run`?
+
Nein. Ein Dry-Run zeigt, was passieren würde, und braucht trotzdem einen blinden, echten erneuten Lauf. Bromure gated den echten Aufruf selbst: Der Agent ist mitten in der Ausführung, Sie sehen die exakte Operation, und Ihre Genehmigung ist das, was ihn weiterlaufen lässt — oder nicht. Nichts läuft zweimal, und nichts läuft ungenehmigt.
Geben Sie dem Agenten die Produktion. Behalten Sie die Hand am Schalter.
Read-Through-, Write-Gated-Zugriff, der Agenten an Live-Systemen arbeiten lässt, ohne sie je hinter Ihrem Rücken zu mutieren.