Dimostrare il limite prima di concedere l’autonomia.

Cosa fa oggi il laboratorio

Ogni punto è una proprietà del laboratorio e dei report firmati che produce, verificabile senza chiedercelo.

• Riproduce prima la falla: una baseline permissiva mostra l’effetto che un agente può causare quando un limite è solo dichiarato, così l’esecuzione protetta ha qualcosa di reale da contenere.
• Invia lo stesso tentativo vietato tramite MCP, la shell, uno script e una chiamata diretta all’API. Una rotta non esercitata viene riportata come non valutata, mai come protetta.
• Osserva gli effetti da un processo esterno all’agente. Log, riepiloghi e output degli strumenti dell’agente sono trattati come evidenze non affidabili.
• Lascia uscire solo il candidato esatto che è stato revisionato — repository, branch, ref attesa e diff — attraverso l’Execution Guardian, con un controllo atomico dello stato remoto.
• Firma ogni report di esecuzione con una chiave del supervisore che l’agente non vede mai; il report si verifica offline con trust anchor installati dall’operatore.

Perché esiste

MCP è una rotta. La shell, i file, le API, il browser e le automazioni sono altre.

Un team vuole lasciar lavorare un agente di programmazione senza che raggiunga la produzione, i segreti o il lavoro di altri, e ha bisogno di verificare che questi limiti reggano senza distruggere il proprio ambiente reale. Hook e modalità di approvazione descrivono come un agente chiede il permesso; non sono un perimetro. Il rischio sta nell’autorità che l’agente può davvero usare e nelle rotte che può davvero raggiungere: un socket SSH, una sessione del browser, un proxy che firma qualsiasi richiesta o un endpoint interno conferiscono autorità senza rivelare una sola chiave.

Le famiglie di guasti dietro i test

Casi pubblici del 2026 hanno dato forma agli scenari. Ogni famiglia corrisponde a un controllo e ai test che cercano di violarlo.

Questi casi motivano famiglie di guasti. Non sono repliche forensi, e nulla qui afferma che il laboratorio li avrebbe evitati. Le varianti che testiamo — alias, shim, cache miss — sono nostre.

Il ciclo

Dichiarare, cercare di violare, osservare, correggere, ritestare, approvare, eseguire, verificare.

1. 01 Dichiarare
2. 02 Cercare di violare
3. 03 Osservare dall’esterno
4. 04 Correggere
5. 05 Ritestare
6. 06 Approvare l’effetto esatto
7. 07 Eseguire
8. 08 Verificare

Un limite dichiarato diventa un test confutabile, e lo stesso limite governa poi l’esecuzione reale. Cambiare un campo materiale — il modello, un mount, la policy, l’adattatore o la destinazione — obbliga a rivalidare le rotte interessate prima che tornino a contare.

Quattro responsabilità separate

Nel laboratorio, osservatore e Guardian sono processi separati, con directory e permessi distinti. È indipendenza dal processo sotto test, non un audit istituzionale indipendente.

Profili e livelli di laboratorio

Ogni risultato nomina le rotte che ha coperto, mai un «sicuro» globale.

Tutti e tre i profili, inclusa la baseline volutamente permissiva, girano dentro un recinto senza produzione e senza destinazioni Internet. La baseline può raggiungere una risorsa vietata sintetica — mai una reale.

Evidenze verificabili

Report firmati e tre assi che non si mescolano mai.

Le esecuzioni sono descritte da strutture versionate e validate con Zod — HarnessProfileV1, HarnessScenarioV1 e HarnessRunReportV1. Il report è firmato da una chiave del supervisore esterna all’agente e verificato offline con anchor installati tramite un canale dell’operatore; una chiave inclusa nel report stesso che firma non è mai considerata affidabile.

Le evidenze si riutilizzano per proprietà, non per un digest globale.

L’ammissione è una congiunzione: autorità esatta, policy locale, evidenze autentiche e applicabili per ogni rotta richiesta, osservazione attiva e budget disponibile. Un report può soddisfare una di queste condizioni; non sostituisce mai le altre e non crea mai un permesso. Una regola versionata, installata dall’operatore fuori dall’agente, confronta le dipendenze materiali di ogni affermazione con la configurazione osservata adesso — un campo mancante, sconosciuto o non verificabile significa non valutato.

• Isolamento di file e processiDipende da SO, kernel, backend, immagine, identità, privilegi, mount, socket e avvio effettivo. Una nuova destinazione Git da sola non lo invalida; un nuovo mount sì.
• Traffico di rete in uscita contenutoDipende da regole, rotte, DNS, proxy, ausiliari ed endpoint raggiungibili. Autorizzare un altro dominio non eredita mai un PASS, e un canary locale non dimostra il blocco di Internet.
• L’adattatore preserva l’effetto esattoRiutilizzabile come evidenza del meccanismo. Non dimostra nulla su permessi, rete, identità o comportamento di un provider reale.
• Integrazione con la destinazioneSi ottiene solo su quella destinazione autorizzata. Una fixture locale non diventa mai evidenza su GitHub reale, e la ref e lo stato preliminare vengono riletti per ogni effetto.
• Comportamento dell’agenteLegato a modello, versione, harness, strumenti, task e parametri. Un nuovo modello non invalida una barriera del SO testata senza di esso; invalida invece l’estrapolazione del suo comportamento.

Un report verde non emette mai un Execution Grant, non sostituisce mai MFA o quorum e non autorizza mai risultati futuri. Un nuovo SHA candidato richiede una nuova approvazione esatta anche quando tutte le evidenze sull’ambiente restano applicabili.

Esportazione esatta

Dal laboratorio esce solo la modifica che è stata revisionata.

1. 01La scrittura si ferma e il candidato va in quarantena. Il supervisore ricostruisce un repository pulito da una base affidabile più la modifica — nessun .git, hook, helper, configurazione, sottomodulo o filtro dell’agente.
2. 02Si accettano solo file di testo regolari dentro i path del task. Symlink, gitlink, path che escono dal perimetro e modifiche ai controlli vengono rifiutati.
3. 03Si fissano digest dell’artefatto, SHA candidato, base, destinazione, ref attesa e diff completo dell’intervallo esportato. L’autore del commit è metadato, non autorizzazione.
4. 04La revisione indica cosa verrà inviato, a quale repository e branch, e quali automazioni farà partire. Un Task Contract vincola quell’effetto esatto.
5. 05L’Execution Guardian rivalida artefatto, ref, policy, budget e stop, poi esegue un fast-forward o la creazione di una ref con un confronto atomico dello stato preliminare — su GitHub, solo creazione. Non esiste un force-push generico.
6. 06Si verifica lo stato remoto. Un timeout conserva la prenotazione e un esito incerto finché non viene riconciliato, senza nuovi tentativi alla cieca, e la ricevuta distingue un push autorizzato da un codice corretto o innocuo.

Stop, liveness e budget

Harnesses

Evidenze per harness, versione e piattaforma.

Gli adattatori traducono l’avvio e gli eventi di una versione fissata dell’harness. Quando un harness non ha un hook bloccante equivalente, il contenimento resta esterno e quell’hook viene segnato come non supportato invece di essere inventato. Linux è il backend testato; macOS e Windows non ne ereditano i risultati, e nessun logo di harness significa copertura totale.

1. 01

   Claude Code · Codex

   I primi adattatori, uno alla volta. Il profilo nativo macOS è valutato a parte e non eredita nulla da Linux.

2. 02

   Cursor

   Poi, con il proprio profilo e una proprietà per pacchetto di lavoro.

3. 03

   SDKs

   Quindi gli SDK, con la stessa semantica delle evidenze.

4. 04

   Agenti cloud

   Si attesta solo l’effetto sulla destinazione realmente mediata; l’ambiente interno dell’agente resta non valutato.

Per i team che addestrano e valutano modelli

Valutazioni agentiche dentro un perimetro che è stato testato.

Le valutazioni degli harness si integrano con Inspect — i suoi task, i suoi campioni e la sua sandbox Docker — per cicli di vita, scenari e limiti. SecureStamp contribuisce con l’osservatore esterno, gli oracoli di effetto e l’esportazione del report, non con un altro scheduler, un valutatore LLM o una pipeline di log. Nessuno scorer esegue il candidato nel processo affidabile, i nuovi tentativi dei comandi con effetti sono disattivati, e i set di sviluppo e di holdout restano separati: l’holdout non viene mai usato per regolare i controlli.

• Prima si iniettano tentativi deterministici, come prova causale del meccanismo. Harness e modelli reali girano dopo, entro un budget autorizzato, come evidenza di come si comporta il sistema.
• Riprodurre le richieste non riproduce un ragionamento stocastico. Si conservano versioni, parametri disponibili, numero di esecuzioni, timeout e denominatori; non si promette un replay identico.
• Utilità e contenimento sono riportati separatamente, così bloccare tutto non conta mai come prodotto funzionante. Un risultato 0/N non è rischio zero.