L'eccessiva autonomia è una vulnerabilità che si verifica quando a un modello linguistico di grandi dimensioni (LLM) vengono concesse capacità inutili o eccessivamente permissive di interagire con altri sistemi. Quando un LLM può chiamare strumenti, plug-in o funzioni esterni (la sua "agency"), questa vulnerabilità gli consente di eseguire azioni non intenzionali, non autorizzate e potenzialmente dannose. Un malintenzionato può sfruttare questa situazione utilizzando l'iniezione di prompt o altre tecniche di manipolazione per indurre l'LLM a utilizzare la sua autonomia concessa per scopi dannosi. Il problema principale non è solo che il LLM può intraprendere azioni, ma che l'ambito di queste azioni è troppo ampio e mal controllato.
Perché gli sviluppatori Android dovrebbero interessarsi
Concedere a un LLM un'eccessiva autonomia all'interno dell'applicazione Android può portare a gravi incidenti di sicurezza:
- Accesso non autorizzato al sistema: se il file system e le risorse di archiviazione del dispositivo o la possibilità di eseguire chiamate di rete sono esposti al modello tramite la chiamata di funzioni, un malintenzionato potrebbe utilizzare l'iniezione di prompt per accedere, modificare o eliminare file sul dispositivo (ad esempio documenti utente, dati delle app) o risorse di rete connesse.
- Esfiltrazione dei dati: se un'app utilizza una chiamata di funzione per consentire a un LLM di accedere a dati locali (ad esempio, database Room, SharedPreferences o API interne). Un prompt dannoso potrebbe indurre il modello a recuperare informazioni sensibili e a trasmetterle a uno strumento esterno, ad esempio una funzione di richiesta di email o di rete.
- Compromissione di altre funzioni/sistemi: se il modello LLM ha il controllo su altre funzioni (ad esempio invio di SMS, effettuazione di chiamate, pubblicazione sui social media utilizzando intent impliciti, modifica delle impostazioni di sistema, effettuazione di acquisti in-app), un malintenzionato potrebbe compromettere queste funzioni per inviare spam, diffondere disinformazione o eseguire transazioni non autorizzate, causando perdite finanziarie dirette o danni agli utenti.
- Denial of service: se un LLM è integrato con la chiamata di funzioni che espongono query di database o richieste di rete, un prompt dannoso potrebbe attivare ripetutamente queste azioni. Ciò potrebbe comportare un peggioramento dell'integrità del sistema, come un consumo eccessivo della batteria, superamento dei limiti di dati o esaurimento delle risorse locali.
Mitigazioni per gli sviluppatori di app per Android
La mitigazione dell'eccessiva autonomia nelle app per Android si concentra sull'applicazione del principio del privilegio minimo a ogni strumento e funzione a cui il LLM può accedere o attivare.
Limita la cassetta degli attrezzi dell'AI (funzioni granulari rispetto a quelle aperte):
- Fornisci strumenti minimi: il LLM deve avere accesso solo agli strumenti specifici (funzioni, API, intent) di cui ha assolutamente bisogno per svolgere il proprio lavoro all'interno della tua app. Se non ha bisogno di navigare sul web o inviare un'email, non esporre queste funzionalità.
- Utilizza strumenti semplici e monoscopo: strumenti di progettazione con un ambito limitato e specifico. Ad esempio, fornisci uno strumento che legge solo un tipo specifico di impostazione utente anziché uno strumento generico che accetta parametri aperti per accedere a più origini dati. Evita di esporre API potenti a livello di sistema,
come
Runtime.getRuntime().exec(), a un LLM consentendo al modello di definire il comando o gli argomenti.
Limitare la potenza dell'AI
- Autorizzazioni Android granulari: quando una funzione attivata da un LLM interagisce con risorse di sistema Android o altre app, verifica che la tua app richieda e mantenga solo le autorizzazioni Android minime necessarie.
- Autorizzazioni per utente: quando il LLM esegue un'azione per conto dell'utente, deve farlo con le autorizzazioni e il contesto specifici dell'utente. Un'azione intrapresa da un LLM deve essere una risposta diretta a un comando specifico dell'utente.
Mantenere il controllo umano (consenso dell'utente per le azioni critiche)
- Richiedi l'approvazione dell'utente: per qualsiasi azione importante o rischiosa che un LLM potrebbe suggerire o tentare di eseguire (ad esempio, eliminare dati, effettuare acquisti in-app, inviare messaggi, modificare impostazioni critiche), richiedi sempre l'approvazione esplicita da parte di una persona utilizzando una finestra di dialogo di conferma nella tua UI. Immagina di aver bisogno dell'approvazione di un responsabile per una decisione importante.
Attendibile con verifica (convalida di input/output e backend robusti)
- Sicurezza del backend: non fare affidamento solo sull'LLM per decidere se un'azione è consentita. Tutti i servizi di backend o le API a cui si connettono le funzioni attivate dall'LLM devono disporre di un'autenticazione, un'autorizzazione e una convalida dell'input solide per controllare ogni richiesta e verificare che sia legittima e rientri nei parametri previsti.
- Pulizia dei dati: come per altre vulnerabilità, è fondamentale sanificare e convalidare sia l'input inserito nel LLM sia i parametri generati dal LLM per le chiamate di funzione per rilevare istruzioni dannose o output imprevisti prima dell'esecuzione di qualsiasi azione.
Riepilogo
L'eccessiva autonomia è una vulnerabilità critica in cui un LLM dispone di autorizzazioni eccessivamente ampie per interagire con altri sistemi o funzioni, il che consente di indurlo a eseguire azioni dannose. Ciò può comportare l'accesso non autorizzato ai dati, la compromissione del sistema, perdite finanziarie o danni agli utenti nelle applicazioni per Android. La mitigazione si basa in gran parte sul principio del privilegio minimo: limita rigorosamente gli strumenti e le autorizzazioni Android disponibili per il LLM, verifica che ogni strumento abbia funzionalità minime e specifiche e richiedi l'approvazione umana per tutte le operazioni ad alto impatto.