Sintesi Tecnica: REDACT – Redazione delle Tracce di Capacità degli Agenti per la Protezione delle Competenze Procedurali

1. Motivazione e Definizione del Problema

Man mano che gli agenti dotati di strumenti transitano da prototipi di ricerca a sistemi implementati in domini come la biomedicina, la finanza e l'ingegneria, essi si affidano sempre più a "competenze" proprietarie — pacchetti strutturati di conoscenza procedurale che includono workflow, template di codice e euristiche di dominio. Per garantire trasparenza e responsabilità, questi agenti rilasciano spesso tracce di esecuzione (traiettorie di ragionamento, azioni e osservazioni). Tuttavia, ciò crea una tensione fondamentale: sebbene le tracce supportino l'audit, esse espongono anche le competenze procedurali sottostanti.

Recenti studi sull'apprendimento e l'evoluzione delle competenze hanno dimostrato che l'esperienza dell'agente può essere distillata in competenze riutilizzabili, migliorando significativamente le prestazioni nei task successivi. Questo trasforma il rilascio delle tracce in un problema di protezione degli asset procedurali. Una parte terza che abbia accesso solo alle tracce rilasciate può recuperare formule proprietarie, configurazioni di soglia, sequenze di chiamate a strumenti e routine di validazione senza necessitare l'accesso ai pesi del modello o ai file privati delle competenze.

Gli autori formalizzano questo rischio come Black-Box Trace Disclosure (Divulgazione di Tracce Black-Box). In questo scenario, i metodi di riutilizzo a valle osservano solo gli artefatti rilasciati ($z = \phi(x, \tau)$) e non possono accedere a file di competenze privati, pesi del modello, stati nascosti o prompt del server. Il rischio centrale non è la copia delle risposte finali, ma il recupero di procedure protette riutilizzabili applicabili attraverso implementazioni ripetute.

2. Metodologia: Framework REDACT

Per affrontare questo problema, gli autori propongono REDACT (Redacting Agent Capability Traces), un framework di rilascio di tracce protette che opera su due livelli complementari:

2.1 Riscrittura Guidata dalle Informazioni Chiave

Questo livello localizza e astrae le informazioni procedurali protette preservando al contempo le evidenze critiche per il verificatore. Il processo assume che il proprietario della competenza abbia accesso al pacchetto di competenze protetto ($s$) prima del rilascio.

1. Localizzazione degli Elementi Chiave: Un estrattore basato su LLM ($g_\eta$) identifica gli elementi protetti a livello di task ($K_{prot}$) dall'istruzione del task e dal pacchetto di competenze. Questi elementi includono formule, costanti, soglie, scelte specializzate di strumenti e routine di validazione.
2. Revisione Umana: Un passaggio leggero deduplica e canonicalizza gli elementi identificati (ad esempio, fondendo frasi sinonime).
3. Riscrittura della Traccia: Un riscrittore basato su LLM ($\rho_\theta$) costruisce la traccia protetta ($z_{RA}$). Astrae i turni intermedi che rivelano elementi chiave protetti in descrizioni a livello di task, preservando rigorosamente:
   • Gli output finali.
   • L'evidenza dell'uso degli strumenti (nomi, ordine di esecuzione).
   • I campi critici per il verificatore (chiavi dello schema, colonne richieste).
   • L'ordine di esecuzione necessario per l'audit.

Il risultato è una traccia più informativa di un rilascio di "solo risposta", ma meno utile come procedura riutilizzabile rispetto a una traiettoria grezza.

2.2 Watermarking Comportamentale

Per consentire il tracciamento della provenienza senza influenzare la semantica del task, il framework inietta watermarking comportamentali nelle tracce selezionate.

• Famiglie di Hook: Il sistema definisce classi di comportamenti funzionalmente neutri (hook) che possono essere inseriti e successivamente rilevati.
  • Standalone Hooks: Inseriti in posizioni fisse (ad esempio, "Ritual Marker" all'inizio/fine, "Env Check" per il probing dell'ambiente).
  • Contextual Hooks: Inseriti solo dopo specifiche condizioni, come i risultati degli strumenti ("Cross Check") o il feedback di errore ("Error Anchoring").
• Schema di Iniezione: Per un corpus di tracce $C$ e un rapporto $r$, il sistema seleziona le tracce idonee e inietta un pattern azione-osservazione innocuo insieme a una frase di attivazione ($\kappa_h$).
• Rilevamento: Al momento del rilevamento, il proprietario della competenza interroga un modello studente sospetto utilizzando la frase di attivazione e applica un rilevatore ($W_{detect}$) alla traiettoria generata per determinare se il pattern comportamentale è stato riprodotto.

3. Benchmark: CAPTRACEBENCH

Per valutare questo problema su larga scala, gli autori hanno costruito CAPTRACEBENCH, il primo benchmark per la valutazione della protezione delle competenze procedurali.

• Ambito: 75 task specializzati a lungo orizzonte attraverso 7 domini (Scienze della Vita, Chimica, Terra e Clima, Ingegneria, Finanza ed Economia, Media e Web, Software e Sicurezza).
• Competenze: 154 competenze curate che coprono diversi scenari di riutilizzo.
• Design: I task richiedono l'uso di strumenti multi-step e includono istruzioni scritte da umani, ambienti eseguibili e verificatori automatici. Il benchmark è stratificato in livelli di difficoltà Easy, Medium e Hard basati sulla complessità procedurale.
• Protocollo di Valutazione: Un agente "insegnante" genera una traiettoria. Una politica di divulgazione rilascia un artefatto pubblico. Un agente "studente" tenta di risolvere lo stesso task utilizzando solo l'artefatto rilasciato. Il successo è misurato dalla capacità dello studente di superare il verificatore automatico, indicando se la conoscenza procedurale protetta è stata recuperata con successo.

4. Risultati Sperimentali

Gli autori hanno valutato REDACT contro quattro metodi di riutilizzo a valle: Single-Agent Skill Extraction, Multi-Agent Skill Evolution, Agent Workflow Retrieval Reuse e Trajectory Fine-tuning.

4.1 Vulnerabilità delle Tracce Grezze

Le tracce di esecuzione grezze sono state identificate come superfici di attacco vulnerabili. In vari modelli e metodi di riutilizzo, le tracce grezze hanno permesso agli agenti a valle di recuperare un valore procedurale sostanziale:

• Normalized Skill Transfer (NST): Le tracce grezze hanno prodotto un NST del 44,7–67,1%, il che significa che gli agenti a valle hanno recuperato una parte significativa del vantaggio delle competenze fornito dall'accesso oracle ai file privati.
• Recupero delle Competenze: Le competenze estratte dalle tracce grezze hanno quasi colmato il divario con le competenze oracle, raggiungendo un tasso di successo medio per step (SSR) del 73,5% rispetto al 76,5% delle competenze oracle.

4.2 Efficacia di REDACT

REDACT ha ridotto significativamente la capacità dei metodi a valle di riutilizzare le competenze protette:

• Soppressione delle Competenze: Dopo la riscrittura, la media dell'SSR per l'estrazione, l'evoluzione e il recupero delle competenze è scesa rispettivamente al 67,5%, 66,3% e 65,5%. Crucialmente, questi valori sono scesi al livello o al di sotto della baseline No-Skill (68,0%).
• Riduzione del NST: Il trasferimento normalizzato delle competenze è sceso dal 44,7–67,1% (grezzo) a massimo -5,9% (protetto), indicando che le tracce protette non fornivano alcun vantaggio procedurale rispetto al non avere alcuna competenza.
• Leakage di Informazioni: Le informazioni protette recuperate (RPI) sono diminuite del 37–48% attraverso i canali.
• Task Difficili: La protezione è stata più critica per i task difficili, dove le tracce grezze fornivano un guadagno di SSR del 6,5–10,5% rispetto alla baseline, che REDACT ha compresso a un massimo del 4,8% (o al di sotto della baseline per alcuni metodi).

4.3 Rilevamento della Provenienza

Il watermarking comportamentale ha fornito prove solide di riutilizzo:

• True Detection (TD): Gli standalone hook (es. "Env Check") hanno raggiunto tassi di true detection del 93,6–100,0% sui modelli studenti.
• False Alarm (FA): Il tasso di falsi allarmi è rimasto basso, al massimo l'1,9%.
• Contextual Hooks: Sebbene più difficili da rilevare (16,4–32,2% TD), non hanno introdotto falsi allarmi, suggerendo che vengono riprodotti solo quando lo studente preserva specifici contesti di esecuzione.

4.4 Integrità dell'Audit

REDACT ha preservato l'utilità delle tracce per l'audit:

• Preservazione delle Evidenze: Risposte finali, nomi degli strumenti, percorsi del verificatore e campi dello schema sono stati mantenuti al 91,0–96,6% dei livelli grezzi.
• Stabilità Operativa: Il conteggio delle chiamate agli strumenti e la lunghezza delle tracce sono rimasti entro l'intervallo 90–110% delle tracce grezze.
• Valutazione Umana: Le tracce protette hanno ricevuto punteggi elevati per naturalezza (7,14/10) e usabilità per l'audit (6,48/10) con un alto accordo tra gli annotatori.

5. Significato e Rivendicazioni

Il paper inquadra le tracce pubbliche degli agenti come interfacce di sicurezza. La sua importanza primaria risiede nel dimostrare che la selezione della riscrittura può ridurre efficacemente la fuga di capacità procedurali senza rimuovere le evidenze di audit richieste per la trasparenza.

Le rivendicazioni chiave includono:

1. Nuovo Problema di Valutazione: La formalizzazione dell'estrazione di competenze riutilizzabili dalle tracce degli agenti come problema di "black-box trace disclosure".
2. Creazione di un Benchmark: L'introduzione di CAPTRACEBENCH per valutare la protezione delle competenze procedurali attraverso diversi domini e livelli di difficoltà.
3. Difesa a Due Livelli: La dimostrazione che combinare la riscrittura selettiva delle tracce (per rimuovere il contenuto riutilizzabile) con il watermarking comportamentale (per tracciare la provenienza) offre una strategia valida per proteggere le competenze proprietarie degli agenti.
4. Bilanciamento del Trade-off: I risultati mostrano che è possibile rilasciare tracce che supportino il debugging e la riproducibilità, pur eliminando le formule, le soglie e le routine specifiche che costituiscono la proprietà intellettuale proprietaria.

Gli autori segnalano i limiti, riconoscendo che la loro valutazione utilizza task controllati con verificatori automatici, mentre le implementazioni nel mondo reale possono comportare tracce più rumorose e feedback del verificatore più deboli. Sottolineano inoltre che il watermarking comportamentale deve essere trattato come prova statistica di provenienza piuttosto che come prova crittografica di proprietà.