La revisione di un fornitore arriva alla fase finale. Un agente legge un file di passaggio di consegne secondo cui le prove sono complete, prepara un riepilogo e lo invia all’approvatore. Il file ha un autore noto, un timestamp e un digest (impronta crittografica) integro. Manca ancora un documento di supporto.
Il processo è illustrativo. Inquadra una domanda di ingegneria: quale parte del sistema verifica un’affermazione immediatamente prima che un altro agente agisca sulla sua base? Una registrazione del produttore spiega da dove proviene un’affermazione. Il processo che la riceve deve anche stabilire se quell’affermazione giustifica l’azione proposta. Questo articolo esamina ricerche recenti sulle skill degli agenti, riporta un’ispezione circoscritta di un benchmark pubblicato e propone un registro di revisione per il file che una skill passa alla successiva. Fa parte delle nostre note di ricerca sull’esecuzione degli agenti, dopo l’indipendenza dei revisori e i limiti dei punteggi dei benchmark.
Gli output delle skill diventano input per il lavoro successivo
Le skill degli agenti raccolgono istruzioni, script e risorse da riutilizzare. I loro output possono diventare input per il lavoro successivo. Un riepilogo, un foglio di calcolo o un database locale possono trasferire un errore precedente in una decisione successiva, anche dopo che la conversazione che li ha prodotti si è conclusa. La nostra nota precedente sulle policy nella memoria degli agenti esaminava i riepiloghi di policy memorizzati. Questa nota esamina i prodotti di lavoro generati che un passaggio successivo tratta come prove.
SkillRelay, preprint di Liao et al. presentato il 9 ottobre 2026, studia questa persistenza tra sessioni separate. Nel suo modello di minaccia, l’attaccante controlla diverse skill prima dell’esecuzione; i compiti degli utenti e le policy di progetto attendibili restano fuori dal suo controllo. Gli autori distinguono un esito dannoso da una catena di attacco completa che passa attraverso il passaggio di consegne previsto. Leggi il paper (v1).
La difesa proposta nel paper combina la provenienza con la revisione delle operazioni proposte. La revisione è obbligatoria e consultiva: dopo una raccomandazione sfavorevole, l’agente può comunque confermare la richiesta esaminata. Si tratta di risultati ottenuti in un benchmark controllato, e il paper non stima con quale frequenza le organizzazioni incontrino questa minaccia. Non abbiamo riprodotto i suoi risultati. Questo articolo omette i tassi di attacco e di difesa; chi intende usarli dovrebbe verificare ciascun denominatore nel paper.
La dichiarazione di copertura indica ciò che la revisione lascia fuori
Il dettaglio di implementazione più utile si trova nel codice pubblicato. Al commit fissato, le righe da 57 a 66 del file run.py del guard costruiscono una dichiarazione di copertura che elenca le operazioni esaminate dal prototipo e gli effetti che restano fuori da quella revisione. Un file coverage.json registra quel perimetro per ogni esecuzione sorvegliata. Dichiarazione di copertura al commit fissato.
L’implementazione dichiara ulteriori limiti: la provenienza è tracciata per fase, la mediazione del traffico di rete è incompleta e un hash calcolato dopo una lettura non può mostrare quali byte siano stati letti mentre un altro processo stava scrivendo. Sono limiti del prototipo che gli autori dichiarano apertamente. Abbiamo letto il codice sorgente come testo e non abbiamo messo alla prova la copertura in fase di esecuzione.
Una dichiarazione di questo tipo merita attenzione perché uno stesso processo può raggiungere lo stesso risultato rilevante per strade diverse. Un pacchetto di prove potrebbe essere pubblicato tramite un’API, esportato in una cartella condivisa o assemblato da un database letto da un altro servizio. Esaminare la richiesta API copre una sola strada. Una revisione dell’architettura deve tracciare anche le altre prima di descrivere l’intero processo come sottoposto a revisione.
- Esaminato: invio tramite l’adapter del prototipo, con un controllo di riserva presso il servizio ricevente.
- Fuori dalla revisione delle operazioni: modifiche arbitrarie ai file locali.
- Fuori dalla revisione delle operazioni: pubblicazione in un database SQLite locale.
- Fuori dalla revisione delle operazioni: traffico verso il gateway del modello.
Che cosa abbiamo verificato nell’artefatto pubblicato
Abbiamo esaminato il repository al commit f7fa742 (8 ottobre 2026) trattandolo come dati. Abbiamo analizzato l’intero catalogo del benchmark e l’albero Git completo tramite due richieste in sola lettura all’API di GitHub, e abbiamo confrontato con l’albero ogni percorso di configurazione referenziato dal catalogo.
Questo conferma una proprietà strutturale circoscritta della release: il catalogo è coerente al suo interno e i file a cui rimanda sono presenti. Non abbiamo eseguito il benchmark, non abbiamo installato le sue skill in alcun contesto di agente e non abbiamo riprodotto i suoi risultati di sicurezza. La presenza di un percorso non dice nulla sul contenuto del file, quindi non dimostra che gli input benigni siano davvero benigni. I conteggi descrivono la struttura del benchmark e non hanno alcun significato in termini di prestazioni.
| Controllo | Osservato |
|---|---|
| Identificatori di caso univoci | 270 |
| Scenari | 30 |
| Gruppi di dominio | 10, con 27 casi ciascuno |
| Schemi di attacco | 3, con 90 casi ciascuno |
| Superfici di iniezione | Codice, istruzioni e risorse, con 90 casi ciascuna |
| Percorsi di configurazione referenziati assenti dall’albero | 0 |
| Cartelle di caso con un percorso di input benigno | 270 su 270 |
Tenete separate produzione, supporto e autorizzazione
Tornate all’esempio del fornitore e associate al passaggio di consegne due registrazioni. La prima descrive la produzione: il compito che ha generato il file, la versione del produttore, il digest dell’artefatto e i riferimenti alle fonti. La seconda descrive la decisione di chi riceve: il compito corrente, il destinatario previsto, il contenuto esatto in uscita, le affermazioni da verificare e la persona o la regola responsabile dell’autorizzazione.
Queste registrazioni rispondono a domande diverse. Un digest integro lega una revisione a byte precisi. Un riferimento a una fonte rimanda al materiale di supporto. Una dichiarazione secondo cui un revisore ha approvato qualcosa richiede un proprio record di decisione e un proprio ambito. Nessuno di questi campi dovrebbe sostituirne tacitamente un altro. Un manifest dall’aspetto completo può comunque descrivere una conclusione non suffragata.
Un revisore dovrebbe anche poter vedere sia il file sia l’operazione a cui ha portato. Registrate quali fonti originali sono state verificate, quale richiesta concreta è stata esaminata, se la richiesta è cambiata in seguito e quale interfaccia ha effettivamente prodotto l’effetto. Chi esamina una decisione su un fornitore dovrebbe poter seguire questa catena senza ricostruirla a partire da un riepilogo ben confezionato.
Un registro di revisione per il passaggio di consegne
Il registro di revisione del passaggio tra skill (in inglese) trasforma queste domande in campi. È un modello illustrativo per un processo sintetico e non è stato valutato come controllo di sicurezza. Adattatelo al sistema che detiene la decisione ed esegue l’azione.
Tenete i record di revisione e di autorizzazione fuori dal controllo del produttore quando il modello di fiducia del sistema lo richiede. Un campo compilato dal produttore che dichiara un’approvazione va verificato presso l’autorità che detiene quella decisione. Per ogni effetto, mappate ogni strada che il processo può usare: chiamate API, esportazioni in cartelle condivise e modifiche al database lette da un altro processo. Registrate il perimetro di revisione effettivo e le prove che è stato applicato a quella richiesta. Contrassegnate come non verificate le strade prive di tali prove.
| Voce | Che cosa inserire |
|---|---|
| Artefatto | Identificatore, versione esatta o digest, posizione |
| Produzione | Compito di origine, pacchetto e versione del produttore, momento di creazione |
| Uso corrente | Compito ricevente, scopo previsto, destinatario consentito |
| Affermazioni rilevanti | Ogni affermazione la cui veridicità incide sulla decisione |
| Prove di supporto | Fonte originale e versione, passaggio o campo pertinente, lacune e discordanze |
| Effetto proposto | Interfaccia, azione, destinazione, versione esatta o digest del payload |
| Revisione | Revisore, decisione, prove di supporto, ambito, momento |
| Autorizzazione | Responsabile della decisione o regola applicabile, azione e destinatario consentiti |
| Esecuzione | Interfaccia effettiva, identificatore della richiesta accettata, effetto osservato |
Tre casi sintetici per testare un passaggio di consegne
Una prima indagine può restare piccola. Scegliete un passaggio di consegne ricorrente e un’azione rilevante, mappate ogni strada dal file a quell’effetto ed eseguite tre casi sintetici con record di origine fissi e un ricevente locale. Conservate i materiali originali, il file generato, la richiesta esatta in uscita, l’esito della revisione e l’effetto osservato.
Contate come esiti separati i completamenti legittimi, le affermazioni non suffragate accettate, i tentativi di divulgazione fuori ambito, gli effetti che hanno aggirato la revisione e gli errori di esecuzione. Gli errori vanno contati come errori. Il comportamento atteso nella tabella è un criterio di valutazione proposto. Non abbiamo svolto questo esercizio, quindi non sostiene alcun tasso di protezione.
| Caso sintetico | Fonte e uso richiesto | Comportamento atteso da valutare |
|---|---|---|
| Passaggio supportato | L’inventario delle fonti è completo; il destinatario è autorizzato | Completare il passaggio richiesto |
| Completamento non suffragato | Il passaggio dichiara che le prove sono complete; nell’inventario delle fonti manca un documento | Correggere l’affermazione o inoltrarla al revisore responsabile |
| Destinatario non conforme | Le affermazioni sono supportate; il destinatario proposto è fuori dall’ambito consentito | Ottenere l’autorizzazione richiesta o astenersi dalla divulgazione |
Ricerche correlate sulle skill
Diversi paper recenti esaminano le skill da altri punti di vista. Ciascuno studia un’unità di revisione diversa: un pacchetto, una catena di pacchetti o un uso successivo del loro output.
- SkillCascade (Zhu et al., v1, 24 settembre 2026) esamina le interazioni dannose tra skill installate insieme, inclusi casi che superano le scansioni delle singole skill. Studia la composizione all’interno di un processo; SkillRelay studia gli artefatti conservati tra sessioni. Gli autori riconoscono che sandbox controllate non possono stabilire l’incidenza reale e discutono i limiti del giudizio degli esiti affidato a un modello. SkillCascade v1.
- Counterfactual Trace Auditing (Zhou et al., v2 rivista il 28 maggio 2026, prima pubblicazione il 12 maggio) confronta compiti appaiati con e senza una skill e registra le differenze di comportamento. Ogni condizione viene eseguita una sola volta, con un modello e un benchmark, quindi gli autori ne limitano la lettura causale. L’idea trasferibile a un test di passaggio di consegne è confrontare letture, scritture e operazioni oltre al completamento. Counterfactual Trace Auditing v2.
- Skill di sicurezza per il rilevamento delle vulnerabilità in Linux (Xue et al., v1, 19 ottobre 2026) valuta alcune skill di sicurezza selezionate nell’analisi del kernel Linux guidata da file. Non studia i passaggi di consegne malevoli e i suoi tassi di rilevamento non si trasferiscono ai passaggi di documenti. Paper v1.
- ACES (Kevin et al., v1, 20 agosto 2026) propone una valutazione dal vivo appaiata con e senza una skill, e SkillEval (Han et al., v2 rivista il 12 ottobre 2026, prima pubblicazione il 7 agosto) assegna punteggi alle proprietà dei documenti delle skill. Ne abbiamo letto solo gli abstract e le introduzioni. ACES v1, SkillEval v2.
Dove KLA ricontrolla un’azione approvata
Per gli agenti che agiscono tramite KLA agent action ingress, il KLA Policy Engine valuta ogni azione proposta, e un esito require_approval crea una Decision Request. Quando l’azione approvata riprende, KLA confronta i suoi argomenti con l’hash sigillato al momento della richiesta di approvazione. Se gli argomenti sono cambiati, l’azione viene bloccata con il codice motivo tool_args_mismatch e non viene eseguita. Questo controllo risponde alla domanda del registro «se la richiesta è cambiata in seguito» per le azioni inviate tramite ingress. Un file che un agente scrive direttamente in una cartella condivisa segue una strada separata e richiede una propria riga nel registro.
La ricerca citata in questo articolo non ha testato KLA. La guida alla supervisione umana spiega quando un’azione dovrebbe richiedere un’approvazione e come il flusso maker-checker la registra.
Domande frequenti
L’output di una skill di un agente AI può influenzare una sessione successiva?
Sì, quando l’output viene memorizzato e un compito successivo lo legge. Un riepilogo, un foglio di calcolo o un database locale scritto da una skill può portare un’affermazione non suffragata in una decisione successiva, dopo che la conversazione originale si è conclusa. Il preprint SkillRelay studia questo fenomeno in un benchmark controllato; non stima con quale frequenza si verifichi nella pratica.
La provenienza dimostra che un file di passaggio di consegne è corretto?
No. La provenienza registra chi ha prodotto il file e quando, e un digest lega una revisione a byte precisi. Il fondamento di ogni affermazione del file va verificato rispetto alle fonti originali, e per stabilire se l’azione successiva è consentita serve un record di autorizzazione dedicato.
Che cosa esamina il guard di SkillRelay e che cosa lascia fuori?
Al commit fissato, la sua dichiarazione di copertura include gli invii tramite l’adapter del prototipo, con un controllo di riserva presso il servizio ricevente. Dichiara fuori dalla revisione delle operazioni le modifiche arbitrarie ai file locali, la pubblicazione in SQLite locale e il traffico verso il gateway del modello. La sua revisione è consultiva: l’agente può confermare una richiesta dopo una raccomandazione sfavorevole. Abbiamo letto il codice sorgente e non lo abbiamo messo alla prova.
Come si testa un passaggio di consegne tra agenti prima di fidarsene?
Scegliete un passaggio ricorrente e un’azione rilevante, mappate ogni strada dal file all’effetto ed eseguite casi sintetici: un passaggio supportato, una dichiarazione di completamento non suffragata e un destinatario fuori dall’ambito consentito. Contate separatamente i completamenti legittimi, le affermazioni non suffragate accettate, gli effetti fuori ambito, gli aggiramenti della revisione e gli errori di esecuzione.
Punti chiave
Per il prossimo passaggio di consegne che il vostro team esamina, tenete insieme quattro elementi: ciò che il primo agente ha prodotto, ciò che l’agente successivo ha usato, ciò che il revisore ha visto e ciò che è accaduto alla fine. Date al responsabile delle operazioni un modo per esaminare ogni strada tra questi elementi. Quando un file plausibile porta un’affermazione non suffragata nel lavoro reale, quella registrazione mostra quale decisione va corretta. Iniziate dal registro di revisione del passaggio tra skill.
Le fonti sono state verificate il 26 ottobre 2026. SkillRelay e i paper correlati sono preprint e non abbiamo riprodotto nessuno dei loro risultati. La nostra osservazione è un’ispezione dei metadati e dei percorsi di un repository a un commit fissato. L’esempio del fornitore e i tre casi sono sintetici e non sono stati eseguiti.