Le banche statunitensi bloccano gli agenti IA nei conti dei clienti

Cosa ha riferito Axios¶

L’articolo si basa soprattutto su persone informate dei fatti. I punti principali, riassunti:

• Banche citate. Morgan Stanley, Bank of America, JPMorgan, Wells Fargo e altre si stanno affrettando a contenere i rischi degli agenti nei conti dei clienti.
• Come entrano gli agenti. Di solito gli agenti usano il permesso e le credenziali di accesso del cliente. Le regole della maggior parte delle banche richiedono che i clienti accedano personalmente ai propri conti.
• Cosa hanno fatto gli agenti. Alcune banche hanno rilevato agenti che contattavano i call center o compivano azioni indipendenti dalle istruzioni degli utenti.
• Cosa fanno le banche. Secondo le fonti, Morgan Stanley ha iniziato a bloccare gli agenti di terzi sulle sue piattaforme. JPMorgan, Bank of America e Citi stanno limitando gli agenti. Le banche stanno riscrivendo le condizioni di servizio perché faticano a distinguere una persona da un bot non autorizzato.
• Accesso in sola lettura. La maggior parte delle banche ha autorizzato, o si sta orientando verso, un accesso in sola lettura per gli agenti, simile a quello già concesso alle app di gestione del budget.
• Preparazione. Le banche stanno investendo per prevenire gli scenari peggiori e pianificano il giorno dopo un incidente, compreso come mettere in sicurezza o ripristinare l’accesso dei clienti.

Cosa non dice l’articolo¶

L’articolo non descrive perdite per i clienti, una violazione confermata né interventi di un’autorità. Un portavoce di Chase ha dichiarato che i clienti non dovrebbero condividere nomi utente e password con nessuno. Un portavoce di Morgan Stanley ha dichiarato che la banca non ha osservato casi di agenti IA fuori controllo che accedessero alle sue piattaforme. Un dirigente bancario non citato per nome ha detto che è difficile capire se un utente abbia autorizzato un agente o se l’agente abbia agito da solo.

L’articolo documenta un problema di controllo su cui le banche stanno lavorando ora.

Perché un controllo dell’accesso non può rispondere alla domanda¶

Quando un cliente consegna la password a un agente, ogni richiesta dell’agente porta l’identità del cliente. La banca vede una sessione valida. Non può vedere che è stato un software a scegliere l’azione, quale istruzione ha dato il cliente né se l’azione vi corrisponde. A quel punto la banca ha due opzioni grossolane: consentire la sessione o bloccare tutto ciò che sembra automatizzato. Il blocco protegge il conto e ferma anche gli agenti che i clienti vogliono usare.

L’accesso in sola lettura riduce il rischio perché la consultazione di un saldo non sposta denaro. Lascia però aperta la questione difficile per il momento in cui agli agenti sarà consentito agire.

Cosa cambia un punto di controllo per singola azione¶

Un punto di controllo a runtime valuta ogni azione proposta da un agente prima che venga eseguita. Richiede che l’agente usi una propria identità, separata dalla password del cliente, e che invii ogni azione proposta tramite un canale governato dalla banca. Il punto di controllo restituisce allora uno di quattro esiti: allow, warn, require_approval o block. Prevale la regola applicabile più restrittiva.

La policy qui sotto è un esempio sintetico per un conto retail. Mostra come una banca potrebbe consentire il lavoro utile degli agenti mantenendo comunque una persona davanti al denaro che esce dal conto.

require_approval mette una persona davanti al denaro che esce dal conto¶

Con require_approval, il punto di controllo trattiene l’azione esatta, con importo, beneficiario e data, e chiede a una persona autorizzata di decidere. Per un cliente retail quella persona è il cliente. Per un conto aziendale è il controllore di tesoreria indicato dal cliente. L’approvazione dovrebbe coprire solo l’azione che la persona ha visto. Se l’agente modifica poi l’importo o il beneficiario, l’approvazione non vale più e l’azione viene valutata di nuovo.

A ottobre 2026 abbiamo costruito un Process di sblocco dei pagamenti trattenuti per un briefing con analisti, con agenti in bozza, dati sintetici e nessun circuito di pagamento. Tre agenti verificano l’istruzione, aggiornano lo screening e preparano una raccomandazione di sblocco, e una persona di Payments Operations autorizza lo sblocco. La policy blocca le corrispondenze confermate con le sanzioni, i pagamenti duplicati e le sospensioni senza una risoluzione documentata, e invia ogni raccomandazione di sblocco a un controllore indipendente. In simulazione, una corrispondenza confermata con le sanzioni ha attivato sia il blocco per sanzioni sia la regola di approvazione dello sblocco, e il risultato è stato block, perché block ha la precedenza.

Due scelte di progettazione di quel lavoro valgono per qualsiasi agente che sposta denaro. Un rifiuto lascia in essere la sospensione originale. Approvazione e regolamento sono registrazioni separate, quindi un pagamento approvato risulta completato solo quando il suo riferimento di regolamento è registrato. Il lavoro ci ha anche insegnato a dare a ogni decisione una sola approvazione: il nostro primo invio in revisione è fallito perché anche due fasi umane avevano un flag di approvazione, il che avrebbe creato due attività di approvazione per una sola decisione.

La matrice delle decisioni di approvazione illustra soglie, ruoli dei revisori, scadenze e casi di eccezione per questo tipo di regola.

Le prove rispondono alla domanda a cui oggi le banche non sanno rispondere¶

Il problema del dirigente non citato è una registrazione mancante. Quando un’azione passa per un punto di controllo, la banca può conservare chi ha delegato l’autorità all’agente, quale agente e quale versione ha agito, cosa ha proposto, quale regola di policy si è applicata, quale esito ne è seguito, chi ha approvato e quando, e cosa ha fatto il sistema a valle. Questa registrazione consente alla banca di rispondere con i fatti a un reclamo di un cliente o a un auditor.

La revoca appartiene alla stessa registrazione. Quando un cliente revoca la delega, l’azione proposta successiva dovrebbe essere rifiutata e il rifiuto registrato. La guida all’architettura del kill switch tratta il percorso di arresto e un’esercitazione per verificarlo.

Dove si colloca KLA e dove no¶

Il KLA Control Plane governa le azioni degli agenti che passano attraverso di esso. Gli agenti che agiscono tramite l’agent action ingress di KLA operano con un mandato dell’agente che prevede un responsabile, strumenti e destinazioni consentiti, vincoli di soglia su parametri come l’importo e una data di fine. Il KLA Policy Engine restituisce allow, warn, require_approval o block per ogni azione proposta. Quando la valutazione della policy fallisce, l’azione non viene eseguita. Un esito require_approval crea una Decision Request; Decision Desk rifiuta le decisioni del richiedente, e l’approvazione è legata a un hash degli argomenti dell’azione, quindi una richiesta modificata viene bloccata. La revoca di un mandato blocca le proposte aperte e rifiuta l’azione successiva dell’agente. Ogni passaggio è registrato per Lineage Explorer, Audit Trail ed Evidence Room. Questo paragrafo descrive il codice sorgente attuale.

KLA non rileva un agente di terzi che accede con la password condivisa di un cliente. Rilevamento dei bot, rischio di sessione e applicazione delle condizioni di servizio restano ai canali antifrode e digitali della banca. KLA governa gli agenti che una banca o i suoi partner scelgono di collegare tramite un canale governato.