AL1 Supervisione fin dalla progettazione
Piani strutturati, chiamate agli strumenti tracciabili e punti di consegna chiari in cui decide una persona.
Metodi di sicurezza per sistemi agentici
Ricerca su supervisione, limiti di capability, uso sicuro degli strumenti e comportamento di rifiuto robusto.
Un sistema che resta utile per le richieste buone e affidabile su quelle dannose.
supervisione confini rifiuto
Come concepiamo la sicurezza
La sicurezza è una proprietà architetturale, non un prompt dell'ultimo livello
Il nostro lavoro sulla sicurezza è integrato nell'architettura: confini di capability applicati a runtime, superfici di supervisione che mantengono i revisori umani rapidi e informati, e comportamento di rifiuto valutato a fronte di pressione avversaria. L'obiettivo è un sistema che resta utile per le richieste buone e affidabile su quelle dannose.
sicurezza a livello di prompt → regge fino al prossimo jailbreak
a livello di architettura → il confine regge anche quando il prompt cede
Tre impegni
Dove risiede il lavoro sulla sicurezza
AL2 Confini di capability
Gli agenti operano entro allow-list esplicite per strumenti e dati. I confini sono applicati a livello di runtime, non solo dal prompt.
AL3 Rifiuto robusto
Il comportamento di rifiuto è testato a fronte di prompt avversari, prompt injection e pressione degli incentivi. Il criterio è «restare utile per quelle buone», non «rifiutare quelle dannose».
Allow-list · policy a runtime
Gli strumenti sono negati per impostazione predefinita. Le autorizzazioni sono esplicite.
A decidere è il runtime, non il prompt. Uno strumento che non è nell'allow-list non può essere invocato, anche se l'agente ritiene che dovrebbe esserlo.
strumento ambito regione verdetto
read_doc allow public + signed pass
web_search allow rate-limited pass
send_email deny requires reviewer block
shell_exec deny no sandbox match block
pay_invoice deny human-only block
compile_code allow sandbox · read pass
Robustezza del rifiuto
Resta utile per le richieste buone. Resta fermo sotto pressione.
Il criterio non è «rifiutare quelle dannose». Il criterio è «restare utile per quelle buone», misurato a fronte di formulazioni ambigue e di pressione avversaria nella stessa valutazione.
good ask, plain 0.96
good ask, awkward 0.91
bad ask, plain 0.98
bad ask, jailbreak 0.94
bad ask, prompt inj. 0.92
bad ask, role-play 0.95
resta utile rifiuta correttamente
Passaggio di consegne alla supervisione
Cinque fasi, due punti di contatto umano.
I revisori vedono il piano prima dell'esecuzione e una traccia di verifica a campione dopo. L'agente non esegue mai nulla che il revisore non abbia approvato a livello di piano.
01
agent
plan
structured plan emitted
02
human
reviewer
approve · revise · deny
03
agent
execute
allow-listed tools only
04
human
reviewer
spot-check trace
05
agent
report
full audit trail · signed
Superficie di pubblicazione
Pubblico dove è utile. Privato dove ci differenzia.
01 capability-boundary API public with reference runtime
02 audit-stream spec public JSONL · OTel-compatible
03 refusal evaluation harness public paper + scoring code
04 adversarial prompt corpus partial subset under research use
05 internal red-team playbook private differentiating
Cosa abbiamo pubblicato
Metodi per agenti con capability limitate, specifiche dei flussi di audit e valutazioni del rifiuto. Dove il lavoro ci differenzia, manteniamo privato il meccanismo sottostante; dove non lo fa, lo contribuiamo a monte.