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:

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

Datenbank-Endpunkte klassifizieren nach Engine:

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.

Die Egress-Firewall

Unterhalb der Zugangsdaten-Zeilen beherbergt der Bereich die Ausgehende Verbindungen-Firewall des Arbeitsbereichs: eine geordnete Regeltabelle, die bestimmt, welche Verbindungen die VM überhaupt öffnen darf — jedes Protokoll, jedes Ziel, nicht nur die Dienste, die Schutzmechanismen klassifizieren. Regeln werden von oben nach unten geprüft, die erste Übereinstimmung gewinnt, und ein segmentiertes Steuerelement Nicht zugeordneter Verkehr wählt den Standard für alles, worauf keine Regel passt: Zulassen (der Standard für neue Arbeitsbereiche) oder Verweigern für eine abgeriegelte Positivlisten-Haltung.

Jede Regel besteht aus fünf Teilen:

Ein aufklappbarer Bereich am unteren Rand zeigt denselben Regelsatz in seinem kanonischen pf-Format — eine Regel pro Zeile, abschließend mit default allow oder default deny —, so werden die Regeln gespeichert, und das ist es, was die CLI und verwaltete Profile transportieren:

allow tcp api.github.com:443
allow web api.example.com GET,POST     # nur diese Verben erreichen die Site
deny  web api.internal PUT,DELETE      # diese Verben blockieren, den Rest erlauben
deny  udp any:53
deny  any 10.0.0.0/8
default deny

Die Durchsetzung erfolgt Host-seitig und in Schichten, sodass ein kompromittierter Agent sie nicht umgehen kann: Der virtuelle Netzwerk-Switch wendet die Regeln auf jeden Datenfluss anhand der Ziel-IP und des per DNS-Mitschnitt ermittelten Hostnamens an (alle Protokolle, einschließlich einfachem TCP und UDP), und der MITM-Proxy wendet sie erneut anhand des TLS-Servernamens und — bei web-Regeln — anhand der einzelnen HTTP-Methode an. Genau die Methoden-Dimension erlaubt es einem Arbeitsbereich, eine API zu lesen, in die er nicht schreiben darf: allow web api.example.com GET,POST gibt dem Agenten Abfragen ohne Mutationen, auf der Übertragungsstrecke, unabhängig davon, welches Werkzeug innerhalb der VM die Anfrage stellt.

Regeländerungen gelten sofort für laufende Sitzungen — das Speichern des Arbeitsbereichs aktualisiert die aktive Richtlinie ohne Neustart, auch für Headless-Sitzungen. Jedes Urteil wird als Firewall-Zeile im Fenster Sicherheits-Zeitleiste erfasst und auf registrierten Installationen als egress.firewall-Ereignis im Stream der Organisation.

Hinweis: Lokale Inferenz ist konstruktionsbedingt ausgenommen: Eine allow-Regel für den Inferenz-Endpunkt auf dem Host (bromure.llm) wird Ihren Regeln vorangestellt, sodass selbst default deny Agenten nicht von den Lokalen Modellen abschneiden kann. Dieser Verkehr verlässt Ihren Mac nie.

Transparentes Abfangen

Die Firewall wäre nur beratend, wenn die VM den Proxy einfach ignorieren könnte — das kann sie nicht mehr: Der virtuelle Switch leitet die Port-80- und Port-443-Flüsse der VM transparent in den Host-Proxy um — keine Umgebungsvariablen nötig, nichts, was der Gast abschalten kann. Einfaches HTTP auf Port 80 wird genauso abgefangen und untersucht wie HTTPS. Das ist für jeden Arbeitsbereich standardmäßig aktiv.

Die Notausstiegsluke ist der Schalter Transparentes Abfangen deaktivieren unterhalb der Regeltabelle. Ihn einzuschalten hindert den Switch daran, :80/:443 umzuleiten, sodass Schutzmechanismen und die web-Regeln der Firewall nur noch den Verkehr sehen, der die Proxy-Umgebungsvariablen freiwillig nutzt — verwenden Sie ihn nur für einen Arbeitsbereich, der unter dem Abfangen wirklich kaputtgeht (etwa starkes Certificate Pinning, das die eingebaute Passthrough-Liste nicht abdeckt), und betrachten Sie die Firewall als beratend, solange er aktiv ist.

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).
• Die Schreibrichtlinien decken die oben aufgeführten Dienste ab; Datenverkehr zu anderen Hosts wird über die Host-, Port- und Methodenregeln der Egress-Firewall geregelt statt über semantische Klassifizierung. Für Paket-Downloads siehe Lieferkette, und für den KI-Datenverkehr des Agenten siehe Prompt-Injection.