Il vero problema delle credenziali nell’IA si risolve togliendo i segreti, non con l’ennesimo rilevatore di attacchi

Mentre il settore discute della sicurezza dell’IA, uno degli strati chiave, la concessione degli accessi, si può già chiudere. L’infrastruttura access-first di Toqen.app è operativa da dicembre 2025.

·
Corridoio di un data center con cavi e il titolo dell’articolo
Un segreto che viaggia in rete si può rubare. Una prova che non lascia mai il dispositivo, no.

Nel settembre 2026 Dario Amodei, a capo di Anthropic, ha pubblicato un saggio in cui sostiene che i presidi di sicurezza esistenti non stanno al passo con la velocità dei modelli di IA. Nello stesso mese Anthropic ha diffuso un rapporto sui vettori di attacco reali, e uno dei principali resta il furto di token, password e chiavi API, insieme all’intercettazione delle credenziali.

Oggi la comunità cerca attivamente modi per rendere verificabili e controllabili le azioni dei sistemi di IA. Ma per costruire un presidio che regga serve dare il nome giusto alla natura del cambiamento.

L’IA non rompe la crittografia, scala l’automazione

L’intelligenza artificiale aumenta la scala degli attacchi: l’errore umano costa meno a chi attacca e le credenziali trasferibili tradizionali diventano un bersaglio ancora più attraente. Un modello può generare phishing personale ventiquattro ore su ventiquattro, clonare voci e setacciare tracce digitali.

Ma la logica dell’attacco non cambia: trovare e rubare un segreto trasferibile, una password, un codice SMS, un token bearer, per presentarlo a nome del titolare. Finché esiste un segreto che viaggia in rete, lo si può intercettare, estorcere o comprare.

Per questo va cambiata non solo la rilevazione degli attacchi, ma l’architettura stessa dell’accesso.

L’architettura access-first

Per access-first intendiamo un’architettura in cui la sicurezza non parte dal monitoraggio e dal rilevamento della compromissione, ma dall’eliminazione completa dei segreti trasferibili dal percorso di rete dell’autenticazione.

In Toqen.app questo è realizzato a livello di hardware e di protocollo:

  1. La chiave non lascia il dispositivo. La chiave privata di firma nasce dentro un chip isolato, Secure Enclave o Android Keystore, e fisicamente non può essere estratta né inviata in rete.
  2. Nei database non ci sono segreti. Il server conserva solo la chiave pubblica per verificare la firma crittografica. Una fuga del database del servizio non serve a nulla per entrare.
  3. Ogni accesso è unico. La firma viene prodotta di nuovo per una specifica sfida monouso. Intercettare il traffico non permette di estrarre la chiave privata né di ripetere la richiesta firmata.
  4. Protezione dal phishing relay e dalla sostituzione di context e origin. A differenza di una conferma puramente meccanica, l’applicazione Toqen.app riceve i parametri originali della richiesta, il Relying Party ID, il tipo di azione richiesta e la sfida monouso, direttamente su un canale verificato. Sullo schermo del telefono vedi il nome reale del servizio e l’ambito dell’accesso, anche se sei finito su un sito falso o se qualcuno prova a farti autorizzare la sessione di un altro.

Questo elimina il segreto trasferibile come classe di attacco in fase di autenticazione: semplicemente non c’è nulla da intercettare e ripresentare in rete.

Un confine onesto. Toqen.app chiude lo strato in cui l’accesso viene concesso la prima volta. La compromissione del telefono stesso, un malware nel sistema operativo o lo sfruttamento di vulnerabilità di codice altrui dentro una sessione già aperta sono altri strati di sicurezza e richiedono risposte dedicate.

Pratica e cronologia

Accanto alla discussione in corso nel settore esiste già un approccio funzionante per uno strato concreto del problema: concedere accesso in sicurezza senza far circolare alcuna credenziale trasferibile.

L’architettura di Toqen.app è partita a dicembre 2025. Sapendo che l’interazione sicura negli scenari human-to-agent e agent-to-agent sarebbe diventata una sfida critica per tutto il settore, ho inviato i materiali del progetto alle aziende principali:

  • 10 aprile 2026: inviata a OpenAI la descrizione di Toqen.app come infrastruttura di access layer per i sistemi agentici, nell’ambito della loro raccolta di proposte Industrial Policy for the Intelligence Age.
  • 15 aprile 2026: ricevuta la conferma che la proposta era stata accolta per la valutazione.
  • 27 aprile 2026: inviate specifiche integrative e possibili formati di integrazione, pilota, grant, supporto infrastrutturale.

Gli stessi materiali sono stati inviati al team di Anthropic.

Conclusione e una domanda aperta

Con un flusso enorme di iniziative in arrivo è del tutto naturale che l’analisi dettagliata di ogni proposta richieda tempo. Il punto è un altro: un segmento preciso di questo problema difficile ha già una risposta pratica, con un nucleo funzionante, un client mobile open source e un’architettura collaudata.

Toqen.app è aperto alla collaborazione con chi costruisce infrastruttura per l’IA, con ricercatori di sicurezza e con team di ingegneria.

Il codice del client mobile è aperto all’audit, mentre documentazione tecnica e contatti sono su toqen.app.

Se gli agenti di IA guadagnano sempre più autonomia, il prossimo strato di infrastruttura di sicurezza va costruito attorno a segreti che si possono rubare o attorno a prove di accesso che non si possono portare via?

Smontarlo passo per passo

L’intera catena di accesso si tocca meglio di quanto si legga: una password ordinaria accanto a una firma che non lascia mai il telefono, e un simulatore di attacchi che mostra esattamente cosa porta via chi attacca in ogni caso.

Come funziona Toqen.app: un percorso interattivo

Leggi tutto