Schutzmechanismen
Schutzmechanismen sind die Host-seitige Steuerung von Bromure Agentic Coding darüber, wie die Zugangsdaten eines Arbeitsbereichs verwendet werden dürfen. Wie der Bereich selbst es formuliert: Schutzmechanismen regeln, wie die konfigurierten Zugangsdaten dieses Arbeitsbereichs verwendet werden. Vor Nutzung fragen blendet bei der ersten Verwendung eines Zugangsdatums in einer Sitzung eine Host-seitige Bestätigung ein. Eine Schreibrichtlinie entfernt oder blockiert destruktive Operationen auf der Übertragung — durchgesetzt im Proxy, sodass ein kompromittierter Agent in der VM sie nicht umgehen kann. Hier erscheinen nur Zugangsdaten, die Sie konfiguriert haben.
Der Bereich zeigt eine Zeile pro konfiguriertem Zugangsdatum, in derselben Reihenfolge, in der der Bereich Zugangsdaten sie auflistet. Jede Zeile zeigt den Titel und den bzw. die Hosts des Zugangsdatums und trägt zwei Steuerelemente:
- Ein Kontrollkästchen Vor Nutzung fragen (auf dem Steuerelement selbst mit Freigabe zur Nutzung erforderlich beschriftet) — das Zustimmungs-Gate pro Zugangsdatum, das vom Bereich Zugangsdaten hierher verschoben wurde.
- Eine inline eingebettete Auswahl für die Schreibrichtlinie, die nur dort angezeigt wird, wo der Dienst des Zugangsdatums eine solche unterstützt.
Wenn der Arbeitsbereich keine Zugangsdaten hat, zeigt der Bereich einen Leerzustand — Keine Zugangsdaten zum Schützen — der Sie zurück zum Bereich Zugangsdaten verweist. Details zur Durchsetzung, Fehlerformate und Audit-Protokolle werden im Deep Dive zu Prompt-Injection und Schutzmechanismen behandelt.
Vor Nutzung fragen
Jede Zeile hat ein Kontrollkästchen Vor Nutzung fragen, das standardmäßig ausgeschaltet ist. Wenn es eingeschaltet ist, pausiert der Proxy bei der ersten Verwendung dieses Zugangsdatums in einer Sitzung und blendet einen Zustimmungsdialog ein, der zeitlich begrenzte Freigaben anbietet — 5 Minuten, 1 Stunde oder den Rest der Sitzung — oder Nicht zulassen. Freigaben existieren nur im Arbeitsspeicher und werden gelöscht, wenn das Sitzungsfenster geschlossen wird, und jede aktive Entscheidung wird unter Fenster → Zugangsdaten-Freigaben… aufgeführt. Das Zustimmungsmodell, die Zusammenführung gleichzeitiger Prompts und das Freigabe-Fenster werden unter Zugangsdaten und die Übertragungsgrenze behandelt.
Dieses Kontrollkästchen gilt für jedes Zugangsdatum, einschließlich einfacher API-Schlüssel, SSH-Schlüssel und manueller Token — die Zeilen ohne Schreibrichtlinie zeigen nur dieses Steuerelement.
Schreibrichtlinie
Wo der Dienst eines Zugangsdatums seinen eigenen Datenverkehr klassifizieren kann, zeigt die Zeile auch eine Auswahl für die Schreibrichtlinie. Sie erscheint bei:
- Git-Forges — GitHub-, GitLab-, Bitbucket-Token.
- AWS-Zugangsdaten.
- DigitalOcean-Token.
- Container-Registries (Docker Hub, ghcr.io und andere).
- Kubernetes-Kontexten.
- Datenbank-Endpunkten (MongoDB, ClickHouse, Elasticsearch).
Jede Schreibrichtlinie bietet dieselben vier Modi:
| Modus | Verhalten |
|---|---|
| Aus | Keine Filterung. |
| Vor Schreibvorgang fragen | Lesevorgänge werden durchgelassen. Jeder Schreibvorgang pausiert für einen Host-seitigen Zustimmungsdialog, der die exakte Operation anzeigt, mit zeitlich begrenzten Freigaben (siehe unten). |
| Destruktives blockieren | Löschungen, Drops und Terminierungen werden blockiert; Erstellungen und Aktualisierungen werden durchgelassen. |
| Nur lesen | Jede Mutation wird blockiert; nur Lesevorgänge werden durchgelassen. |
Neue Arbeitsbereiche verwenden standardmäßig Vor Schreibvorgang fragen für jeden Dienst, der eine Richtlinie unterstützt (über die Voreinstellungsvorlage). Arbeitsbereiche, die vor der Einführung der Schutzmechanismen erstellt wurden — oder Profile, deren JSON das Feld auslässt — werden als Aus dekodiert.
Hinweis: Die Schreibrichtlinie gilt pro Dienst, nicht pro Zugangsdatum. Zwei Zugangsdaten für denselben Dienst — etwa zwei GitHub-Token — teilen sich eine Richtlinie, sodass eine Änderung der Auswahl in einer der beiden Zeilen sie für beide ändert.
Hinweis: Schutzmechanismen klassifizieren Operationen; sie verbergen keine Zugangsdaten. Das Zugangsdatum selbst wird weiterhin vom Proxy wie unter Zugangsdaten konfiguriert injiziert und ausgetauscht. Kombinieren Sie eine Nur lesen-Schreibrichtlinie mit dem Kontrollkästchen Vor Nutzung fragen derselben Zeile für einen tiefengestaffelten Schutz.
Wie jeder Dienst Aufrufe klassifiziert
| Dienst | Geltungsbereich | Klassifizierung |
|---|---|---|
| Kubernetes | Die Kubernetes-API-Server aus den kubeconfigs dieses Arbeitsbereichs | GET/HEAD/OPTIONS = Lesen; DELETE = destruktiv (einschließlich deletecollection); andere Verben = Schreiben. Blockierte Aufrufe geben ein Kubernetes-Status-403-JSON zurück, das kubectl sauber darstellt. |
| AWS | Alle *.amazonaws.com-Hosts | Der Aktionsname aus dem Header X-Amz-Target (Dienste mit JSON-Protokoll wie DynamoDB und Lambda) oder dem Formularparameter Action= (Dienste mit Query-Protokoll wie EC2, IAM, SQS) wird nach Präfix klassifiziert: Delete*/Terminate*/Remove*/Purge*/Destroy*/Deregister*/Revoke* = destruktiv; Get*/List*/Describe* und ähnliche = Lesen. Fällt bei S3 und REST-artigen Anfragen auf die HTTP-Methode zurück. Blockierte Aufrufe geben einen AccessDeniedException-Body zurück. |
| DigitalOcean | api.digitalocean.com und *.digitalocean.com | HTTP-Methode: DELETE = destruktiv; GET/HEAD = Lesen. |
| Container-Registries | Die unter Zugangsdaten konfigurierten Registries plus Docker-Hub-Endpunkte | Pull (GET) = Lesen; Push (PUT/POST) = Schreiben; DELETE = destruktiv. Blockierte Aufrufe geben einen Registry-artigen DENIED-Fehler-Body zurück. |
| GitHub | github.com-REST-API und Git über HTTPS | Methodenbasiert für REST. git push (git-receive-pack) zählt als Schreibvorgang — blockiert bei Nur lesen, abgefragt bei Vor Schreibvorgang fragen; git fetch (git-upload-pack) ist immer ein Lesevorgang. |
| GitLab | gitlab.com-REST-API und Git über HTTPS | Dieselbe Klassifizierungslogik wie GitHub. |
| Bitbucket | bitbucket.org-REST-API und Git über HTTPS | Dieselbe Klassifizierungslogik wie GitHub. |
Datenbank-Endpunkte klassifizieren nach Engine:
| Engine | Lesen | Schreiben | Destruktiv |
|---|---|---|---|
| MongoDB (Atlas Data API) | find, findOne, aggregate | insert, update, replace | deleteOne, deleteMany |
| ClickHouse | SQL, dessen führendes Schlüsselwort SELECT, SHOW, DESCRIBE, EXPLAIN, WITH … ist | INSERT, CREATE, ALTER, … | DROP, TRUNCATE, DELETE und ALTER … DELETE / DROP COLUMN / DROP PARTITION / CLEAR |
| Elasticsearch | _search, _msearch, _count, _mget, _sql und andere Query-Endpunkte (auch über POST) | _bulk, _update, Dokumentindizierung | DELETE und _delete_by_query |
Eine orangefarbene inline eingeblendete Warnung erscheint, wenn eine Richtlinie gesetzt ist, es aber nichts gibt, worauf sie sich beziehen könnte — keine kubeconfigs für einen Kubernetes-Kontext, kein gesetzter Host für einen Datenbank-Endpunkt — da der Schutzmechanismus dann keine Hosts hat, auf die er angewendet werden kann.
Hinweis: Wenn bei ClickHouse kein SQL-Text in der Anfrage sichtbar ist, blockiert Nur lesen die Anfrage (Bromure kann nicht beweisen, dass es ein Lesevorgang ist), während Destruktives blockieren sie durchlässt (es irrt zugunsten des Durchlassens).
Der Zustimmungsdialog (Vor Schreibvorgang fragen)
Im Modus Vor Schreibvorgang fragen werden Lesevorgänge stillschweigend durchgelassen, und jeder Schreibvorgang pausiert für einen Host-Dialog mit dem Titel Allow write on "<scope>" from workspace "<name>"?. Der Dialogtext zeigt die exakte Operation wortwörtlich — die literale SQL-Anweisung für eine Datenbank oder METHOD /path für einen REST-Aufruf — sodass Sie genehmigen, was tatsächlich ausgeführt wird, nicht eine Zusammenfassung. Die Schaltflächen sind:
- Für 15 Minuten zulassen (die Standardschaltfläche)
- Einmal zulassen — erzeugt absichtlich keine Freigabe, sodass der nächste Schreibvorgang erneut abgefragt wird. Nützlich, um einen geschwätzigen Agenten Schreibvorgang für Schreibvorgang zu auditieren.
- Für den Rest der Sitzung zulassen
- Nicht zulassen — der Agent erhält denselben harten Fehler, den die Blockiermodi erzeugen. Die Ablehnung wird 60 Sekunden lang gemerkt, sodass ein Agent, der denselben Schreibvorgang in einer Schleife wiederholt, nicht jede Sekunde erneut abgefragt wird.
Freigaben gelten pro Arbeitsbereich und pro Protokoll-Geltungsbereich: ein Kubernetes-API-Host, AWS als Ganzes, eine Container-Registry, jede Git-Forge als Ganzes oder ein Datenbank-Host. Das Zulassen von ClickHouse-Schreibvorgängen auf einem Host gewährt nirgendwo sonst etwas. Gleichzeitige identische Schreibvorgänge werden zu einem einzigen Dialog zusammengeführt, und alle Entscheidungen existieren nur im Arbeitsspeicher — sitzungsgebundene Freigaben werden beim Abbau der Sitzung gelöscht.
Wenn der Arbeitsbereich headless über SSH oder die CLI angesteuert wird, werden dieselben vier Optionen als Textprompt innerhalb des tmux des Arbeitsbereichs angeboten; keine Antwort bedeutet Ablehnung.
Hinweis: Schreib-Freigaben der Schutzmechanismen werden in keinem Fenster aufgeführt. Das Fenster Zugangsdaten-Freigaben (Menü Fenster → Zugangsdaten-Freigaben…) zeigt nur Zustimmungsentscheidungen für Zugangsdaten — die Vor Nutzung fragen-Freigaben; eine Schreibrichtlinien-Freigabe läuft nach ihrer eigenen Uhr oder beim Abbau der Sitzung ab.
Was der Agent sieht, wenn ein Aufruf blockiert wird
Blockierte Aufrufe geben einen protokollgerechten 403-artigen Fehler-Body zurück — ein Kubernetes-Status-JSON, eine AWS-AccessDeniedException, eine Registry-DENIED-Payload — dessen Nachricht mit „blocked by Bromure Guardrails“ endet. Der Agent sieht einen sauberen, gewöhnlichen API-Fehler, den er melden kann, statt einer hängenden Verbindung. (Blockierungen der Lieferkette verwenden stattdessen HTTP 451, gerade damit die beiden auf einen Blick unterscheidbar sind — siehe Lieferkette.)
Einschränkungen
- Git-Force-Push kann auf der Übertragung nicht von einem normalen Push unterschieden werden, sodass Destruktives blockieren ihn nicht blockiert — nur Nur lesen und Vor Schreibvorgang fragen kontrollieren Pushes. Explizite Löschungen über die Forge-REST-APIs werden weiterhin erfasst.
- Kubernetes- und Container-Registry-Richtlinien gelten nur für Hosts, die aus den kubeconfigs und konfigurierten Registries des Arbeitsbereichs abgeleitet werden; Datenbankrichtlinien benötigen den unter Zugangsdaten gesetzten Host des Endpunkts. Ein Schutzmechanismus, der keinen Geltungsbereich hat, filtert nichts (der Bereich warnt Sie inline).
- Schutzmechanismen decken die oben aufgeführten Dienste ab. Beliebiger HTTPS-Datenverkehr zu anderen Hosts wird nicht klassifiziert — für Paket-Downloads siehe Lieferkette, und für den KI-Datenverkehr des Agenten siehe Prompt-Injection.