Turnkey lancia Managed Secrets per l’accesso degli agenti IA alle credenziali

Turnkey ha lanciato Managed Secrets, estendendo la propria infrastruttura di wallet basata su enclave alle chiavi API, alle password, ai dati di pagamento e alle informazioni di recupero di cui hanno bisogno applicazioni e agenti IA per funzionare. Con l’annuncio del 29 ottobre, l’azienda amplia la propria attività oltre la gestione delle chiavi private, affrontando un problema più ampio: consentire al software di agire senza disseminare credenziali riutilizzabili nella propria infrastruttura.

Il prodotto consente ai team di decidere quali servizi possono recuperare una credenziale e se la richiesta richiede l’approvazione di una persona o di più parti. Nelle applicazioni finanziarie, ciò potrebbe significare rilasciare una chiave API di un exchange a un backend di trading autorizzato, impedendo al contempo che finisca nella conversazione di un assistente IA o nel suo ambiente di esecuzione.

Spostare l’accesso alle credenziali all’interno di un’enclave sicura

Le credenziali archiviate nelle variabili d’ambiente o nei file di configurazione sono comode da usare per il software, ma la compromissione del processo che le legge può esporne il contenuto. Un archivio sicuro può centralizzare la conservazione e i controlli di accesso; resta da stabilire in quale punto una credenziale diventa leggibile e quali sistemi devono essere considerati affidabili in quel momento.

Managed Secrets esegue i controlli di autorizzazione all’interno delle enclave sicure di Turnkey. Prima di importare un segreto, il client lo cifra; l’enclave lo cifra nuovamente per archiviarlo. Quando arriva una richiesta, l’enclave valuta le politiche e le approvazioni pertinenti, quindi cifra il risultato per la chiave del destinatario previsto. Il richiedente e il destinatario possono essere servizi diversi.

Questa separazione è importante. Un’applicazione può avviare un’attività e raccogliere le approvazioni senza acquisire la capacità di decifrare la credenziale necessaria per portarla a termine. La firma di chi approva autorizza il rilascio, ma non conferisce automaticamente accesso al segreto rilasciato.

La crittografia alla base dell’importazione e dell’esportazione

La documentazione sul canale sicuro di Turnkey descrive un protocollo basato sulla cifratura ibrida a chiave pubblica (HPKE). Il protocollo combina l’accordo su chiavi pubbliche con la cifratura autenticata, così che i dati sensibili possano attraversare sistemi intermedi sotto forma di testo cifrato. Durante l’importazione, il client verifica il materiale chiave firmato dall’enclave; durante l’esportazione, i dati vengono cifrati con una chiave pubblica fornita nella richiesta firmata.

Le chiavi dei destinatari sono destinate a un solo utilizzo. Turnkey sottolinea che spetta ai client rispettare questa regola: il protocollo non può impedire a un client malfunzionante di riutilizzare la chiave di destinazione. Di conseguenza, l’implementazione del client fa parte del modello di sicurezza, al pari dell’enclave.

La pagina del prodotto Managed Secrets specifica la cifratura AES-256-GCM a riposo per ogni segreto. L’API supporta sia le singole credenziali sia le richieste che riguardano più segreti. Le esportazioni in blocco falliscono per intero se manca l’autorizzazione per anche uno solo dei segreti richiesti, impedendo così il rilascio di un insieme approvato solo in parte.

Perché il destinatario continua a essere importante

L’espressione «gli agenti possono usare le credenziali senza vederle» descrive uno schema di integrazione, non garantisce che ogni processo ricevente non possa leggere il testo in chiaro. La documentazione per sviluppatori di Turnkey afferma esplicitamente che il testo in chiaro può trovarsi all’interno dell’enclave e sul client che importa o esporta un segreto.

Se la chiave del destinatario è custodita da un servizio di esecuzione separato, quest’ultimo può decifrare e usare una credenziale senza esporla al modello. Se invece quella chiave è custodita nell’ambiente di esecuzione dell’agente, tale ambiente può decifrarla. È quindi necessario proteggere il destinatario, la sua memoria e i suoi log.

Esiste un secondo limite: le politiche possono esaminare il contesto della richiesta, per esempio il dominio di checkout dichiarato, ma Turnkey non verifica in modo indipendente che tale dichiarazione sia vera. Una dichiarazione firmata attesta chi l’ha fatta. Le applicazioni hanno comunque bisogno di controlli affidabili che colleghino tale dichiarazione all’operazione effettiva.

Approvazioni che si adattano all’evoluzione dei flussi di lavoro

I team possono consentire il recupero diretto, richiedere l’approvazione di una persona o esigere l’accordo tra più ruoli di agente. Le politiche possono essere modificate senza importare di nuovo il segreto sottostante, consentendo a un flusso di lavoro di iniziare sotto stretta supervisione e di automatizzare in seguito alcune richieste selezionate.

La guida all’accesso programmabile di Turnkey mostra un agente browser e un agente di pagamento che firmano congiuntamente una richiesta. Solo l’agente di pagamento riceve i dati della carta in forma decifrabile. Prima di approvare la richiesta, il componente browser verifica che il dominio proposto corrisponda alla pagina che sta utilizzando. L’esempio mostra perché l’indipendenza dei ruoli e la convalida sono più importanti del semplice conteggio di due approvazioni.

I ruoli degli agenti possono usare credenziali di sessione con ambito limitato e scadenza, offrendo agli operatori un modo per revocare una singola istanza in esecuzione. La revoca degli accessi futuri, tuttavia, non può cancellare un segreto già decifrato da un destinatario; la rotazione delle credenziali a valle resta una misura operativa distinta.

Dall’infrastruttura per i wallet all’automazione finanziaria

L’architettura di sicurezza già adottata da Turnkey si basa su AWS Nitro Enclaves e combina l’isolamento hardware con build riproducibili e attestazione remota. La riproducibilità consente di confrontare le build del software, mentre l’attestazione fornisce prove sul codice in esecuzione nell’enclave. Managed Secrets estende queste fondamenta a credenziali diverse dalle chiavi di firma blockchain.

L’azienda indica tra gli utenti a cui si rivolge società di trading, sistemi back-end fintech, sviluppatori di agenti IA e custodi MPC. Le credenziali degli exchange e i token OAuth consentono l’accesso continuativo ai servizi; i backup delle quote di chiave e le chiavi di ripristino servono a garantire la resilienza. Si tratta di impieghi distinti, con requisiti diversi in materia di approvazione e destinatari, anche quando condividono la stessa infrastruttura di archiviazione.

Per i team che operano nel settore delle tecnologie finanziarie, l’importanza della soluzione sta nel rendere più netta la distinzione tra richiedere un’azione, autorizzare l’accesso e ricevere una credenziale utilizzabile. Managed Secrets fornisce l’infrastruttura necessaria a questa separazione. La protezione che ne deriva dipende da policy circoscritte, approvatori affidabili e un servizio adeguatamente protetto, che utilizza concretamente il segreto.