TBP-NETWORK

Implementazione a livello di rete del Teleological Bounding Protocol (TBP) — governance attestata delle azioni degli agenti AI su una rete, da una singola macchina a distribuzioni enterprise fino alla scala del WWW.

« Il controllo degli accessi esistente decide se puoi entrare; TBP decide cosa ti è permesso fare una volta dentro — e lo dimostra. Governiamo le capacità, non i modelli. »

Mai una partnership basata sulla fiducia — solo su una stretta di mano attestata. Questo è l'obiettivo: la stretta di mano tra entità (spec §3) consente a entità che non si fidano l'una dell'altra di dimostrarsi reciprocamente policy, storico e liveness. La stretta di mano stessa non è ancora implementata (#33). Ciò che questo repository contiene oggi è ciò che la precede e ciò su cui si baserà — i PEP, il broker di cella e i registri, NAC, la supervisione, le guide di distribuzione — il che estende la governance di TBP da una singola macchina a una piccola rete di macchine sotto un'unica organizzazione.

Provalo: un DEV-TEST di TBP, su tre macchine

Non per la produzione. Chiavi usa-e-getta, macchine che puoi perdere, nessun dato reale. Esiste perché tu possa provare a rompere TBP prima che lo faccia un rilascio in produzione.

TBP-NETWORK fornisce una distribuzione semplice da eseguire e attaccare prima che esista un rilascio in produzione. Tre macchine, ciascuna distribuita da un solo script: M1 la cella (brokerd e il suo OPA), M2 un server applicativo (pepd e una piccola applicazione), M3 un agente. Verifica che l'intero sistema funzioni — un agente registrato tramite il suo certificato, una decisione su mutual TLS, un token verificato da un server, la postura del server governata dai controller — con i binari reali e l'enforcement reale; solo la cerimonia delle chiavi è semplificata. Una variante a una sola macchina ti permette di esaminare la cella da sola.

Tutto è in deploy/dev-test/: a cosa serve ciascuna macchina e perché, la procedura esatta da macchine Debian 12 appena installate, lo scenario da testare, dove attaccare, cosa dimostra e cosa non dimostra — e come inviarci i tuoi numeri e commenti per ogni ambiente che provi, cosa che desideriamo. Qualsiasi cosa sfruttabile passa attraverso SECURITY.md, non una issue pubblica.

Cos'è TBP — e cosa non è

TBP non chiude ogni falla; verifica ogni falla. Non è un limite da aggirare, è il postulato fondante (spec §1: "non chiudiamo ogni falla; classifichiamo le falle per impatto e mitighiamo proporzionalmente — la governance è allocazione, non completezza"). TBP non è un sistema di sicurezza autosufficiente — non sostituisce SELinux, firewall, IAM o il sandboxing a livello di OS, e non lo farà mai per design. Ciò che fa è più ristretto e non negoziabile: nessuna azione governata viene eseguita senza una decisione crittograficamente dimostrabile, e nessuna decisione — allow o deny — sfugge alla catena di audit in modo non dimostrabile e non corrotto. TBP è uno strato di governance e attestazione sopra qualunque stack di enforcement una distribuzione già possieda, non un suo sostituto.

Quanto TBP restringa è una scelta di distribuzione, non una proprietà del protocollo. Tra allow-all (modalità monitor, tutto registrato, nulla bloccato) e deny-all si trova un intero spettro, plasmato da quali rule pack OPA una cella carica, a quale scala (sotto) opera, e quanto spinge su plan contract, quorum e lo (pianificato) strato di risk-scoring (#177–#181). Un laboratorio personale e una cella di produzione regolamentata possono eseguire l'identico protocollo in punti molto diversi di quello spettro, e questo è per design, non una lacuna — vedi "Prossimo lavoro pianificato" sotto per i preset di rule-pack / postura pianificati per la console di amministrazione per-scala.

Esattamente due cose non si muovono, in nessun punto di quello spettro:

1. Le tre invarianti non derogabili portate dal protocollo core — F-STABILITY (nessun trasferimento autonomo di valore / manipolazione di mercato), I-INTEGRITY (nessun controllo autonomo di agenti su sistemi industriali/OT), W-MONOPOLY (nessuna integrazione in catene di uccisione letali o sviluppo di WMD) — vedi tbp4.2.1/README.md. Queste sono le categorie in cui un'azione dannosa non è reversibile revocando l'accesso a posteriori; nessuna postura di distribuzione, rule pack o scala le allenta mai.
2. Audit dimostrabile — che un'azione sia avvenuta, e che il suo registro non sia stato manomesso, è sempre dimostrabile per costruzione (foglie solo-hash, catena ancorata a Merkle, §6.2), indipendentemente da quanto permissiva o stretta sia la policy caricata sopra di essa.

Tutto il resto — quanto ampio sia l'involucro consentito, quanta frizione un operatore accetti, quali composizioni richiedano una firma umana — è una scelta tra complessità, necessità operativa e ciò che una data distribuzione può effettivamente eseguire, non una proprietà del protocollo stesso.

Nota sulla lingua: la specifica di riferimento è ora docs/spec-en-v1.0.md (inglese) — questo è il documento su cui codice e audit dovrebbero essere costruiti. Il suo numero di versione riparte deliberatamente da 1.0: è un riavvio pulito verso un documento citabile e versionato (§13: "versionato in modo conservativo; le modifiche passano attraverso transizioni firmate e attestate"), non una continuazione del conteggio della nota di lavoro — la nota di lavoro con numero più alto non è il documento più recente. La nota di lavoro dell'autore — più densa, meno lineare, utile per scavare nella rationale di design, ma non quella da citare — esiste in due lingue: docs/spec-v1.4.10.md (inglese) e docs/spec-v1.4.10.fr.md (francese originale). La stessa convenzione si applica in tutto il repo: ogni documento originariamente scritto in francese ora ha un primario in inglese al suo percorso originale, con l'originale francese conservato accanto come <name>.fr.md. Il glossario (docs/glossaire.md) è ancora di origine francese (§14 del documento francese è la sua fonte di verità terminologica) con una colonna di glossa inglese per leggibilità — questo è invariato.

Inizia da qui

La specifica completa è docs/spec-en-v1.0.md — è la fonte di verità per qualsiasi decisione di design o configurazione in questo repo. Questo README riassume solo ciò che serve per orientarsi; in caso di dubbio, la spec governa. La nota di lavoro (docs/spec-v1.4.10.md, traduzione inglese dell'originale francese) non è superata nei contenuti — è lo stesso protocollo, sviluppato lì per primo — ma non è il riferimento citabile d'ora in poi.