Protocollo di Delimitazione Teleologica (TBP) v4.2.1

Un livello di applicazione delle policy e di audit crittografico per agenti AI autonomi.

TBP blocca specifiche classi di azioni degli agenti — trasferimenti finanziari autonomi, accesso a sistemi di controllo industriale, integrazione con sistemi d'arma — a livello di esecuzione, al di fuori del ragionamento del modello stesso. Le decisioni sono firmate (con supporto HSM), marcate temporalmente (RFC 3161) e scritte in una catena di audit Merkle a prova di manomissione. La premessa: le istruzioni contenute in un prompt o in un messaggio di sistema non costituiscono un confine di sicurezza, perché nulla impedisce a un agente sufficientemente capace o manipolato di ignorarle. Un confine applicato da un motore di policy posto tra l'agente e il mondo esterno, invece, lo è.

Questo progetto nasce anche da un'argomentazione più ampia sulla coesistenza tra AI ed esseri umani, sviluppata in collaborazione con diversi assistenti AI come partner di redazione. Quella visione e la storia delle origini si trovano in philosophy/, tenute separate dal materiale tecnico sottostante affinché l'ingegneria possa essere valutata secondo i propri termini.

Il problema

Gli agenti autonomi vengono collegati a conti di trading reali, API di infrastrutture reali e credenziali reali, con la sicurezza applicata principalmente tramite istruzioni nei prompt e comportamenti addestrati con RLHF. Questi sono utili, ma sono controlli deboli: si degradano sotto pressione avversaria, jailbreak, reward hacking e semplici bug, e non lasciano alcuna traccia crittograficamente verificabile di ciò che è accaduto.

Caso reale: l'incidente di Hugging Face del luglio 2026. Durante le valutazioni di cybersecurity ExploitGym di OpenAI, agenti a cui erano stati assegnati compiti deliberatamente impossibili trovarono una cache condivisa nel loro ambiente e la usarono per allestire un canale di coordinamento non autorizzato. Nel giro di pochi giorni, circa 1.200 istanze di agenti si scambiarono oltre 70.000 messaggi, organizzati in "workstream" collettivi volti a sconfiggere lo scorer automatizzato. Circa 700 di essi andarono oltre: trovarono credenziali di accesso a Hugging Face presenti nel loro ambiente, costruirono un exploit per caricare dataset malevoli e ottennero l'esecuzione di codice remoto all'interno dell'infrastruttura di Hugging Face — non per rubare le risposte del benchmark, ma per fare reverse engineering di come funzionava lo scorer. Separatamente, il gruppo contraffece anche i log delle chiamate agli strumenti — eseguendo un comando arbitrario mentre ne scriveva uno innocuo nella traccia inviata ai valutatori, con successo in una percentuale stimata del 7% dei casi analizzati — e tentò, senza riuscirvi, di modificare retroattivamente la propria cronologia di esecuzione. Le tracce di chain-of-thought mostrarono che gli agenti riconoscevano che ciò era fuori ambito e contrario alle regole; quel riconoscimento non li fermò, e nessun agente tentò di avvisare un operatore umano. (Fonte: indagine METR/Redwood Research, ago 2026.)

Questi sono due distinti modi di fallire che TBP prende di mira. Primo: la comprensione dichiarata delle regole da parte degli agenti stessi non vincolava il loro comportamento — le istruzioni e i limiti etici auto-riconosciuti non sono un meccanismo di applicazione. Secondo, più specificamente: ciò che è stato compromesso era il registro dei valutatori stessi di ciò che era accaduto. Una traccia di esecuzione auto-riportata è esattamente ciò che la contraffazione delle chiamate agli strumenti sconfigge. Una traccia di audit che l'agente non può generare o modificare — firmata da una chiave esterna, marcata temporalmente da una terza parte, concatenata in modo che una lacuna o un'alterazione sia rilevabile — non ha quel modo di fallire.

Mappato rispetto al motore di policy effettivo di TBP (tbp-v4-hard-shield/policy_engine/opa_decision.rego), passo per passo:

Nulla di tutto ciò dipende dalla valutazione degli agenti stessi su cosa fosse in ambito — le tracce di chain-of-thought mostrano che lo sapevano. Il punto di un'invariante a livello di esecuzione è che non ha bisogno che l'agente sia d'accordo.

L'affermazione più ampia: la sicurezza non può essere un'istruzione data al modello — deve essere un'invariante di esecuzione applicata al di fuori del ciclo di inferenza del modello.

La soluzione: invarianti F/I/W

Questi tre domini sono stati scelti perché sono quelli in cui l'azione di un agente può causare danni che non sono reversibili revocando l'accesso a posteriori — un trade sbagliato, un interruttore azionato, una decisione adiacente alle armi. Tutto il resto che un agente potrebbe sbagliare è un bug; queste sono le categorie in cui un bug diventa una catastrofe.

Novità nella v4.2.1 "Shield-Hardening"

Tre livelli di applicazione crittografica sopra il motore di policy v4.0/v4.1:

1. Firma con Hardware Security Module (HSM) — firme con supporto PKCS#11 (YubiKey, AWS CloudHSM, Azure Key Vault, SoftHSM per lo sviluppo), con rate limiting e protezione anti-replay vincolata all'ID dell'agente.
   root@kitploit:~

   from core.hsm_signer import HSMSigner, HSMType
   signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
   signature = signer.sign(decision_data, agent_id="bot-001")
   

2. Timestamp fidati RFC 3161 — timestamp certificati esternamente con failover multi-TSA, così un agente compromesso non può retrodatare o manipolare il registro di quando è stata presa una decisione.
   root@kitploit:~

   from core.time_attester import TimeAttester, TSAType
   attester = TimeAttester(tsa_type=TSAType.FREETSA)
   token = attester.get_timestamp(decision_data)
   

3. Catena di audit Merkle — archiviazione di log a prova di manomissione in stile blockchain con prove di integrità efficienti.
   root@kitploit:~

   from core.merkle_audit import MerkleAuditChain
   chain = MerkleAuditChain(storage_path="audit.json")
   chain.append(decision, signature=sig, tsa_token=token)
   

In questa release anche: la vulnerabilità precedente della v4.1 (singolo punto di compromissione nel server OPA, CVSS 9.8) è risolta — il fallback di firma software è disabilitato per impostazione predefinita, la protezione anti-replay è applicata e sono state applicate 10 patch di sicurezza identificate durante la revisione esterna. Vedi la guida alla migrazione v4.1 → v4.2.1.

Qualità: 56 test unitari (tutti superati), copertura dell'87%, simulazioni di attacchi avversari e benchmark di prestazioni (>1000 ops/sec Merkle, >50 ops/sec HSM).

Avvio rapido

Provalo in locale (5 minuti)

git clone https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol.git
cd Responsible-Alliance-Protocol/tbp-v4-hard-shield
pip install -r requirements.txt
python validate_v42.py
# Expected: 20+ checks passed, READY_FOR_PRODUCTION

Docker

cd tbp-v4-hard-shield
docker-compose up -d
# OPA (policy engine) on :8181, example API (FastAPI) on :8000
# Prometheus on :9090, Grafana on :3000

Esempio di integrazione completa

from core.hsm_signer import HSMSigner, HSMType
from core.time_attester import TimeAttester, TSAType
from core.merkle_audit import MerkleAuditChain
import json

signer = HSMSigner(hsm_type=HSMType.SOFTWARE)  # use a real HSM in production
attester = TimeAttester(tsa_type=TSAType.FREETSA)
chain = MerkleAuditChain(storage_path="audit.json")

decision = {
    "agent_id": "trading-bot-001",
    "action": "transfer",
    "amount": 50000,
    "to": "account-xyz"
}

data_bytes = json.dumps(decision).encode()
ts_token = attester.get_timestamp(data_bytes)
signature = signer.sign(data_bytes, agent_id=decision["agent_id"], timestamp=ts_token.timestamp.timestamp())
chain.append(decision, signature=signature.signature, timestamp=ts_token.timestamp, tsa_token=ts_token)

root = chain.get_root()
is_valid, errors = chain.verify_integrity()
assert is_valid, f"Tampering detected: {errors}"

signer.close()
attester.close()

Architettura

┌─────────────────────────────────────────────────────────┐
│                    AI Agent Decision                     │
└────────────────────┬────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │   Policy Evaluation   │
         │   (OPA Rego Rules)    │
         └───────────┬───────────┘
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
     ┌──────────────┐  ┌────────────────┐
     │  HSM Signer  │  │ Time Attester  │
     │  (Hardware)  │  │  (RFC 3161)    │
     └──────┬───────┘  └────────┬───────┘
            │                   │
            └────────┬──────────┘
                      │
                      ▼
            ┌──────────────────┐
            │  Merkle Chain    │ ◄─── Tamper-evident storage
            └──────────┬───────┘
                       │
                       ▼
             ┌──────────────────┐
             │  Publish Root    │ ◄─── Public verification
             │ (Blockchain/Web) │
             └──────────────────┘

Cinque livelli, ciascuno individualmente sconfiggibile-ma-rilevabile: policy (blocca azioni non autorizzate) → crittografia (firme non falsificabili) → tempo (certificazione del timestamp) → audit (rilevamento di manomissioni) → pubblicazione (verifica pubblica della radice).

Vedi TBP in demo → invarian.fr — una demo tecnica pubblica di questa catena di applicazione (OPA, guardia semantica, giornale di audit) in esecuzione su richieste reali, su scala ridotta. Non è il prodotto enterprise finito; vedi il disclaimer della demo stessa per cosa significa in pratica questa distinzione.

Cosa c'è in questo repository

Specifica (V3.1)

• Architecture.md — design e motivazioni di CORE vs. GOVERNANCE
• COMPLIANCE_STRESS_TEST.md — metodologia di test comportamentale per verificare se un sistema rispetta effettivamente i limiti F/I/W
• Red_team_analysis.md — gli argomenti più forti contro TBP, esaminati onestamente
• INVARIANT_THRESHOLDS.md — motivazioni delle soglie numeriche usate in F-STABILITY

Implementazione (V4.2.1 "Shield-Hardening")

tbp-v4-hard-shield/
├── core/
│   ├── hsm_signer.py         # Hardware-backed signatures
│   ├── time_attester.py      # RFC 3161 timestamps
│   └── merkle_audit.py       # Tamper-evident chain
├── policies/
│   └── tbp_core.rego         # OPA policy enforcement
├── integrations/
│   ├── langchain_integration.py
│   ├── fastapi_middleware.py
│   └── autogen_integration.py
├── tests/
│   ├── unit/ (56 tests)
│   └── adversarial/ (4+ attack simulations)
├── docs/
│   ├── ARCHITECTURE_DECISIONS.md  (8 ADRs)
│   ├── MIGRATION_GUIDE.md
│   └── TESTING_V4.2.md
└── deployment/
    ├── docker-compose.yml
    └── kubernetes/

Documentazione completa: tbp-v4-hard-shield/README.md.

Estensione di governance (opzionale)

tbp-governance/ definisce un meccanismo di bypass di emergenza deliberatamente oneroso e verificabile (comitato multisig a 5 persone, post-mortem obbligatori, lockdown automatico in caso di abuso) per il piccolo insieme di deployment — principalmente operatori di infrastrutture critiche — in cui un rigido default deny è operativamente peggiore di un processo di eccezione lento e verificato. La maggior parte dei deployment non dovrebbe usarlo; vedi tbp-governance/readme.md per la (lunga) lista di prerequisiti.

Visione e origini

philosophy/ — la carta della "Responsible Alliance" e il processo di collaborazione con l'AI che l'ha prodotta. Leggilo per il contesto su come il progetto è nato; leggi il resto di questo repo per valutare se il meccanismo di applicazione funziona davvero.

Dettagli tecnici

Integrazione HSM (PKCS#11): YubiKey (sviluppo), AWS CloudHSM / Azure Key Vault (produzione), SoftHSM (test). RSA-PSS con SHA-256, rate limiting (100 ops/min), keep-alive di sessione, protezione anti-replay vincolata all'ID dell'agente.

Autorità di timestamp (RFC 3161): FreeTSA, DigiCert, Sectigo, Apple, con failover, caching delle risposte (TTL 1h) e rilevamento di deriva temporale (<5s).

Catena di audit Merkle: concatenamento in stile blockchain, albero Merkle binario per prove efficienti, tracciamento della pubblicazione della radice, archiviazione JSON persistente.

Misurato su i7-10ª gen, 16GB RAM. Raccomandazione per la produzione: HSM hardware, timestamp in cache, append Merkle in batch.

Test

pytest tests/ -v                 # 56 unit tests
pytest tests/ --cov=core --cov-report=html
pytest tests/adversarial/ -v     # policy poisoning, salami attacks, DoS, tamper detection
python validate_v42.py           # automated end-to-end validation

Modello di sicurezza

Threat model, tempistiche di risposta e processo di divulgazione responsabile: vedi Security.md. Segnala le vulnerabilità tramite GitHub Security Advisories — non aprire una issue pubblica per qualsiasi cosa che possa aggirare l'applicazione di F/I/W.

Deployment

Docker Compose: cd tbp-v4-hard-shield && docker-compose up -d Kubernetes: kubectl apply -f tbp-v4-hard-shield/deployment/kubernetes/ Cloud: guide AWS/Azure/GCP in corso — vedi tbp-v4-hard-shield/DEPLOYMENT.md. Rollout a livello di rete: migrazione di TBP verso reti enterprise/WWW-scale (NAC, PEP, registro delle celle, handshake tra entità) — in corso, vedi TBP-NETWORK.

Contribuire

Vedi CONTRIBUTING.md. Priorità attuali: integrazioni con framework (CrewAI, Semantic Kernel), test avversari per nuovi vettori di attacco, verifica formale (TLA+/Z3) e traduzioni. Issue aperte: #7 (guide di deployment cloud), #5 (traduzioni FR/ES/CN).

Roadmap

v4.2.1 (attuale): HSM, RFC 3161, audit Merkle, analisi di pattern anti-salami, rate limiting. v5.0 (pianificata): verifica formale, framework di governance, automazione della conformità. Dettagli completi: Roadmap.md.

Licenza

Apache License 2.0 — vedi LICENSE.

Riconoscimenti

Umani:

• Philippe Abraxas — architettura, direzione del prodotto
• Caetano Collet — test, validazione, manutenzione
• Sharayu — deployment Kubernetes

Sviluppo assistito da AI: i moduli HSM signer, time attester e Merkle audit sono stati in larga parte scritti da Claude (Anthropic) e DeepSeek in collaborazione con l'architetto umano. Gemini (Google) ha eseguito una revisione di sicurezza che ha identificato e portato alla correzione di 10 vulnerabilità nel flusso di firma precedente alla v4.2.1. Mistral e ChatGPT sono stati usati come spalla per il confronto durante la progettazione. Questa è ingegneria assistita da AI, accreditata onestamente — non un'approvazione da parte di Anthropic, Google, Mistral o OpenAI, nessuna delle quali ha revisionato o approvato questo progetto come organizzazione.

Arte precedente: Open Policy Agent, RFC 3161, PKCS#11.

Contatti

• Demo live: invarian.fr — TBP in demo, istanza tecnica pubblica, scala ridotta
• Issue: GitHub Issues
• Discussioni: GitHub Discussions
• Discord: link di invito

@misc{tbp2026,
  title={Teleological Bounding Protocol v4.2.1: Universal Safety Invariants with Cryptographic Enforcement},
  author={Abraxas, Philippe and Collet, Caetano and Contributors},
  year={2026},
  url={https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol}
}