philippeabraxas-jpg/tbp-networkTheorie und Implementierung des TBP-Protokolls zur Absicherung vernetzter KI in kleinen bis offenen Webnetzwerken
Netzwerkweite Implementierung des Teleological Bounding Protocol (TBP) — attestierte Governance von Aktionen KI-gesteuerter Agenten über ein Netzwerk, von einer einzelnen Maschine bis hin zu Unternehmensbereitstellungen bis zur WWW-Skala.
« Bestehende Zugriffskontrolle entscheidet, ob du hineinkommst; TBP entscheidet, was du drinnen tun darfst — und beweist es. Wir steuern Fähigkeiten, nicht Modelle. »
Niemals eine Partnerschaft durch Vertrauen — nur durch einen attestierten Handshake. Das ist das Ziel: Der Handshake zwischen Entitäten (Spezifikation §3) ermöglicht es Entitäten, die einander nicht vertrauen, sich gegenseitig Policy, Historie und Liveness nachzuweisen. Der Handshake selbst ist noch nicht gebaut (#33). Was dieses Repository heute enthält, ist das, was davor kommt und worauf er aufbauen wird — die PEPs, den Cell-Broker und die Registries, NAC, Supervision, die Bereitstellungsanleitungen — was TBP's Governance von einer einzelnen Maschine auf ein kleines Netzwerk von Maschinen unter einer Organisation ausweitet.
Nicht für den Produktivbetrieb. Wegwerf-Schlüssel, Maschinen, die Sie verlieren können, keine echten Daten. Er existiert, damit Sie versuchen können, TBP zu brechen, bevor es ein Produktiv-Release tut.
TBP-NETWORK liefert eine einfache Bereitstellung zum Ausführen und Angreifen, bevor ein Produktiv-Release existiert. Drei Maschinen,
jede durch ein Skript bereitgestellt: M1 die Cell (brokerd und ihre OPA), M2 ein Anwendungsserver (pepd und eine
kleine Anwendung), M3 ein Agent. Es testet, dass das Ganze funktioniert — ein Agent, der durch sein Zertifikat registriert wird,
eine Entscheidung über gegenseitiges TLS, ein Token, das von einem Server geprüft wird, die Posture des Servers, gesteuert durch die Controller — mit den
echten Binaries und der echten Durchsetzung; nur die Schlüsselzeremonie ist vereinfacht. Eine Ein-Maschinen-Variante lässt Sie die
Cell allein betrachten.
Alles befindet sich in deploy/dev-test/: wofür jede Maschine gedacht ist und warum, die genaue Vorgehensweise von frischen Debian-12-Maschinen aus, das zu testende Szenario, wo man angreifen kann, was es beweist und nicht beweist — und wie Sie uns Ihre Zahlen und Kommentare für jede Umgebung, die Sie ausprobieren, senden können, was wir uns wünschen. Alles Ausnutzbare läuft über SECURITY.md, nicht über ein öffentliches Issue.
TBP schließt nicht jedes Loch; es auditiert jedes Loch. Das ist keine Einschränkung, die man umgehen müsste, es ist das Gründungspostulat (Spezifikation §1: "wir schließen nicht jedes Loch; wir ordnen Löcher nach Auswirkung und mildern proportional — Governance ist Zuteilung, nicht Vollständigkeit"). TBP ist kein selbstgenügsames Sicherheitssystem — es ersetzt nicht SELinux, Firewalls, IAM oder Sandboxing auf OS-Ebene, und das wird es per Design nie. Was es tut, ist enger und nicht verhandelbar: keine gesteuerte Aktion wird ohne eine kryptografisch beweisbare Entscheidung ausgeführt, und keine Entscheidung — ob Erlauben oder Verweigern — entkommt der Audit-Kette unbeweisbar und unverfälscht. TBP ist eine Governance- und Attestierungsschicht über jedem Durchsetzungs-Stack, den eine Bereitstellung bereits hat, kein Ersatz dafür.
Wie stark TBP einschränkt, ist eine Bereitstellungswahl, keine Protokoll- eigenschaft. Zwischen Alles-Erlauben (Überwachungsmodus, alles protokolliert, nichts blockiert) und Alles-Verweigern liegt ein ganzes Spektrum, geformt dadurch, welche OPA-Regel- Pakete eine Cell lädt, auf welcher Skala (siehe unten) sie operiert und wie weit sie Plan-Verträge, Quorum und die (geplante) Risikobewertungsschicht vorantreibt (#177–#181). Ein persönliches Labor und eine regulierte Produktions-Cell können dasselbe Protokoll an sehr unterschiedlichen Punkten dieses Spektrums betreiben, und das ist beabsichtigt, keine Lücke — siehe "Nächste geplante Arbeiten" unten für die Regel-Paket- / Posture- Presets, die für die Admin-Konsole pro Skala geplant sind.
Genau zwei Dinge bewegen sich nicht, an keinem Punkt dieses Spektrums:
tbp4.2.1/README.md.
Dies sind die Kategorien, in denen eine schlechte Aktion nicht durch
nachträglichen Entzug des Zugriffs rückgängig gemacht werden kann; keine Bereitstellungs-Posture, kein Regel-Paket und keine
Skala lockert sie jemals.Alles andere — wie weit der erlaubte Rahmen ist, wie viel Reibung ein Betreiber akzeptiert, welche Kompositionen eine menschliche Signatur erfordern — ist eine Wahl zwischen Komplexität, betrieblichem Bedarf und dem, was eine gegebene Bereitstellung tatsächlich ausführen kann, keine Eigenschaft des Protokolls selbst.
Anmerkung zur Sprache: Die Referenzspezifikation ist jetzt
docs/spec-en-v1.0.md (Englisch) — dies ist das
Dokument, gegen das Code und Audits aufgebaut werden sollten. Seine Versionsnummer
wird bewusst auf 1.0 zurückgesetzt: Es ist ein sauberer Neustart in ein zitierfähiges, versioniertes
Dokument (§13: "konservativ versioniert; Änderungen durchlaufen signierte,
attestierte Übergänge"), keine Fortsetzung der eigenen Zählung der Arbeitsnotiz —
die höher nummerierte Arbeitsnotiz ist nicht das neuere Dokument. Die
Arbeitsnotiz des Autors — dichter, weniger linear, nützlich zum Graben nach Design-Rationale,
aber nicht die zu zitierende — existiert in zwei Sprachen:
docs/spec-v1.4.10.md (Englisch) und
docs/spec-v1.4.10.fr.md (französisches Original).
Dieselbe Konvention gilt im gesamten Repository: Jedes Dokument, das ursprünglich
auf Französisch geschrieben wurde, hat jetzt ein englisches Primärdokument an seinem ursprünglichen Pfad, wobei
das französische Original daneben als <name>.fr.md erhalten bleibt. Das Glossar
(docs/glossaire.md) ist weiterhin französischsprachig (§14 des französischen Dokuments ist
seine Terminologie-Quelle der Wahrheit) mit einer englischen Gloss-Spalte zur
Lesbarkeit — dies ist unverändert.