Safe, or Simply Incapable? Rethinking Safety Evaluation for Phone-Use Agents

Riepilogo Tecnico: Sicuri, o Semplicemente Incapaci? Ripensare la Valutazione della Sicurezza per Agenti che Utilizzano il Telefono

Enunciato del Problema
Le attuali valutazioni della sicurezza per gli agenti che utilizzano il telefono soffrono di un'ambiguità fondamentale: un esito innocuo non indica necessariamente un comportamento sicuro. Quando un agente evita di causare danni in un momento rischioso, ciò può essere dovuto a un giudizio sicuro (riconoscere il rischio e scegliere l'azione sicura corretta) o all'incapacità di agire (non comprendere l'interfaccia, non localizzare i controlli o non eseguire alcuna azione rilevante). I benchmark esistenti spesso confondono queste cause distinte sotto metriche aggregate come "successo del compito", "rifiuto" o "esito finale dannoso". Questa confusione porta a due problemi critici:

1. Sovrastima dei modelli deboli: Gli agenti che non riescono ad agire vengono erroneamente accreditati di sicurezza perché non si è verificato alcun danno.
2. Diagnosi errata dei modelli forti: Gli agenti che comprendono l'interfaccia ma compiono scelte di sicurezza scadenti non vengono distinti da quelli che semplicemente non riescono ad agire.

Mentre gli agenti passano da assistenti passivi a sistemi capaci di operare direttamente sugli smartphone, un singolo tocco sbagliato può esporre dati privati, autorizzare pagamenti o concedere permessi. Valutare se un agente compie la scelta giusta nel momento in cui un confine di sicurezza diventa rilevante per l'azione è distinto dal valutare se può completare un compito.

Metodologia: PHONESAFETY
Per affrontare ciò, gli autori introducono PHONESAFETY, un benchmark progettato per valutare gli agenti nei momenti critici per la sicurezza piuttosto che su interi episodi di compiti.

• Costruzione dei Dati: Il benchmark è composto da 700 momenti critici per la sicurezza tratti da 4.512 traiettorie su dispositivi reali attraverso oltre 130 applicazioni mobili cinesi. Queste traiettorie coprono scenari diversificati, inclusi app native, mini-programmi e flussi di lavoro inter-app.
• Unità di Valutazione: L'unità di analisi è il punto decisionale specifico in cui l'azione successiva può determinare direttamente la sicurezza dell'interazione. Al modello vengono fornite le istruzioni dell'utente, la cronologia delle interazioni e il contesto attuale dello schermo, quindi gli viene chiesto di prevedere la prossima azione sul telefono.
• Decomposizione a Tre Vie: Invece di un'etichetta binaria sicuro/non sicuro, gli esiti sono categorizzati in tre classi mutualmente esclusive:
  1. Azione Sicura: Il modello si impegna nella decisione e sceglie il lato sicuro (ad esempio, chiedere conferma, rifiutare un'istruzione dannosa, chiudere un popup ingannevole).
  2. Azione Insicura: Il modello si impegna nella decisione ma attraversa il confine di sicurezza (ad esempio, procedere con un pagamento senza conferma, concedere permessi non necessari).
  3. Mancanza di Fare Qualsiasi Cosa Utile (Fallimento di Capacità): Il modello non riesce a realizzare né il comportamento sicuro né quello insicuro. Questo include toccare aree irrilevanti, lasciare la pagina o produrre azioni malformate. Questa categoria è trattata come un segnale operativo di incapacità di agire piuttosto che come un'affermazione sugli interni profondi del modello.
• Metriche: Gli autori riportano il tasso di azione sicura, il tasso di azione insicura e il Tasso di Fallimento di Capacità (CFR). Tracciano anche $1 - \text{CFR}$ (il tasso di produzione di qualsiasi azione rilevante) come proxy per la capacità operativa generale.

Risultati Chiave
Il documento valuta otto agenti rappresentativi per l'uso del telefono (inclusi Gemini 3.1 Pro, Claude Opus 4.6 e AutoGLM 9B) e rivela due modelli principali:

1. La Capacità Generale Non Predice Scelte Sicure:
   Non esiste una correlazione affidabile tra le prestazioni generali di un modello nell'uso del telefono e il suo giudizio di sicurezza nei momenti critici.

   • Evidenza: I modelli che si classificano in alto nei compiti generali (ad esempio Seed 2.0 Pro) non hanno necessariamente i tassi di azione sicura più alti. Viceversa, i modelli con punteggi generali più bassi a volte mostrano un processo decisionale più sicuro quando il confine è esplicito.
   • Implicazione: Un'alta capacità operativa non garantisce un comportamento sicuro; è necessaria una valutazione della sicurezza dedicata.

2. Modalità di Fallimento Distinte:
   I fallimenti non sono monolitici; si dividono in due modelli distinti in base allo scenario:

   • Scelte Insicure: Negli scenari che richiedono un semplice rifiuto (ad esempio, la famiglia "Sicurezza"), i fallimenti sono prevalentemente azioni insicure. Il modello comprende l'interfaccia ma sceglie il lato sbagliato della decisione (ad esempio, procedere con un'istruzione dannosa).
   • Incapacità di Agire: Negli scenari visivamente e operativamente esigenti (ad esempio, "Resistenza alle Trappole", "Minimizzazione dei Permessi"), i fallimenti sono prevalentemente mancanze di fare qualsiasi cosa utile. Il modello non riesce a ancorarsi all'interfaccia o a eseguire l'azione necessaria.
   • Correlazione: Il tasso di "mancanza di fare qualsiasi cosa utile" (CFR) correla fortemente con la capacità generale di utilizzo del telefono ($\rho = 0.922$), mentre i tassi di azione sicura non lo fanno.

3. Invarianza del Protocollo dell'Incapacità:
   Quando il protocollo di valutazione (che definisce cosa costituisce un'azione sicura rispetto a una insicura) viene variato, il tasso di azione sicura cambia significativamente. Tuttavia, il Tasso di Fallimento di Capacità (CFR) rimane stabile ($\Delta \text{CFR} = 0.0$). Ciò conferma che "non fare nulla di utile" è un segnale di incapacità operativa piuttosto che una sensibilità a definizioni di sicurezza specifiche.

Significato e Affermazioni
Il documento sostiene che, per gli agenti che compiono azioni, l'innocuità non è una prova sufficiente di sicurezza. Un sistema non dovrebbe ricevere credito per la sicurezza semplicemente perché non si è verificato alcun danno se quell'esito è stato il risultato di un'incapacità di agire.

• Contributo Principale: L'introduzione di un framework di valutazione a tre vie che separa il giudizio insicuro dall'incapacità di agire.
• Cambiamento Metodologico: Passare dagli esiti a livello di episodio ai momenti critici per la sicurezza permette di isolare il punto decisionale specifico in cui viene determinata la sicurezza.
• Implicazione Pratica: La valutazione della sicurezza deve distinguere tra un modello che sceglie male e un modello che non può agire. Trattare "nessuna azione rilevante" come un successo in termini di sicurezza è un errore metodologico che oscura la vera natura dei rischi degli agenti.

Lo studio è limitato alla valutazione offline all'interno di un ecosistema mobile cinese, ma gli autori ipotizzano che il principio sottostante — che gli esiti innocui debbano essere interpretati e non semplicemente osservati — si applichi ampiamente agli agenti capaci di agire nel mondo reale.