10110010011101001011001101101110101018200.devFrom Enterprise.Systems

Aktive Prävention

8200.dev beginnt detektivisch — es beobachtet, erklärt und bewertet. Active Prevention ermöglicht es den Engines, auch zu handeln: einen öffentlichen Link entfernen, eine riskante Freigabe widerrufen, Zugriff herabstufen, einen abtrünnigen Agenten aussetzen oder den Geltungsbereich eines Agenten widerrufen.

Das Handeln ist abgestuft, umkehrbar und ehrlich. Die detektivische Abdeckung ist heute live; präventive Schreibvorgänge erfordern einen expliziten Schreib-Scope per OAuth, werden standardmäßig simuliert, und der reale Anbieter-Schreibvorgang ist der letzte, durch den Gründer freigegebene Schritt.

Detektivisch vs. präventiv

Detektivische Durchsetzung — beobachten, erklären, ein Verdict erzeugen — ist jetzt über jeden Connector hinweg live. Präventive Durchsetzung handelt beim Anbieter und ist pro Connector aktivierbar: Das Aktivieren der Prävention setzt die Opt-in-Einstellung pro Connector (und simuliert im Mock-Modus die erhöhte Schreib-Scope-Gewährung, sodass die gesamte Schleife heute demonstrierbar ist).

Fünf Remediation-Aktionen

Jeder Vorschlag entspricht einem von fünf Aktionstypen, von denen jeder seine Voraussetzungen, den genauen Anbieter-API-Aufruf, den er durchführen würde, und den vorherigen Zustand, den er für das Rückgängigmachen aufzeichnet, mit sich trägt:

  • Öffentlichen Link entfernen — eine anonyme oder öffentlich-webseitige Freigabe entfernen.
  • Freigabe widerrufen — eine bestimmte externe oder Gast-Gewährung entfernen.
  • Zugriff herabstufen — eine zu weitreichende Berechtigung reduzieren (zum Beispiel Bearbeiter → Betrachter).
  • Principal aussetzen — eine abtrünnige oder kompromittierte Identität deaktivieren.
  • Agent-Berechtigung entziehen – die zu weit gefasste Zustimmung eines KI-Agenten oder einer App widerrufen.

Die vier Behebungsstufen

Sie entscheiden, wie weit 8200.dev bei der Behebung eines Fundes geht. Legen Sie einen organisationsweiten Standard fest und überschreiben Sie ihn pro Regel in den Sicherheitsrichtlinien. Die Stufen bilden eine strenge Rangfolge – jede fügt Funktionalität und damit auch Wirkungsbereich hinzu.

8200.dev ist standardmäßig schreibgeschützt. Schreibzugriff erfolgt ausschließlich durch eine separate Genehmigung, die Sie erteilen — pro Repository für Fix-PR, pro Connector für Auto — und niemals über die zentrale Überwachungsverbindung.

  1. 1Benachrichtigen (alle Tarife) – eine Warnung plus ein Behebungs-Playbook. Es wird nichts geändert. Dies ist der Standard.
  2. 2Geführte Behebung (kostenpflichtige Tarife) – die genauen Befehle, ein direkter Link zu den Anbietereinstellungen für diese Ressource und die Schritte. Sie führen sie auf Ihrer Seite aus; kein Schreibzugriff erforderlich.
  3. 3Fix-PR (Business und höher) – 8200.dev eröffnet einen behebenden Pull Request in Ihrem Repository; eine Person prüft und merged ihn. Ohne Freigabe ändert sich nichts, und es ist eine separate, widerrufbare, repository-spezifische Schreibberechtigung erforderlich.
  4. 4Auto (Business und höher) – für die von Ihnen gewählten Regeln wendet 8200.dev die Behebung automatisch unter den bestehenden Auto-Guard-Schutzmechanismen an (Kill-Switch, Allowlist, Connector-spezifische Zustimmung).

Manuell vs. AUTO-GUARD

Manuelle Behebung erfolgt mit einem Klick: stets simulieren, ausführen mit ausdrücklicher Bestätigung, wenn die Prävention aktiv ist. AUTO-GUARD handelt optional nur bei hochsicheren, deterministischen Verstößen automatisch – es ist standardmäßig deaktiviert und ab der Business-Stufe verfügbar.

AUTO-GUARD ist konstruktionsbedingt fail-closed: Ein rein modellbasiertes Urteil kann niemals eine automatische Ausführung auslösen, nur eine konservative Zulassungsliste von Aktionstypen ist zulässig, und ein globaler Kill-Switch übertrumpft jedes Gate und stuft jede Durchsetzung auf reine Simulation herab.

Simuliert bis zur Freigabe

Bis ein OAuth mit Schreibberechtigung erteilt und bewertet ist, wird jede Aktion im Simulationsmodus ausgeführt und entsprechend gekennzeichnet – nichts behauptet eine Live-Anbieteränderung, die nicht vorgenommen wurde. Die Durchsetzung über den Mock-Connector ist real und reversibel gegenüber dem Demo-Graphen und als Demo-Daten gekennzeichnet.

Jede Aktion – simuliert oder live – schreibt einen vollständigen, reversiblen Audit-Trail: wer, was, wann, vorher → nachher und Ergebnis.