L'etichetta della credenziale non è l'ambito della credenziale.

La crittografia è a prova di proiettile. SRP-6a secondo RFC 5054, AES-256-GCM, confronti a tempo costante, prova a conoscenza zero. 1Password ha realizzato correttamente la parte crittografica. L'errore sta sull'etichetta.

Questo mese due ingegneri di Token Security hanno impiegato tre giorni nell'ingegneria inversa del protocollo di autenticazione SRP proprietario di 1Password. Non stavano cercando una vulnerabilità: volevano sostituire un bridge SCIM con un client Python per la gestione delle identità non umane. Quello che hanno trovato è uno scarto fra ciò che la credenziale dichiara di poter fare e ciò che effettivamente può fare [1][2].

Un service-account token con ambito limitato a un singolo vault e permessi di sola lettura può elencare ogni utente dell'organizzazione. Ogni gruppo. Ogni appartenenza a un gruppo. Ogni permesso a livello di vault su tutti i vault. Nomi, email, stato, timestamp dell'ultima autenticazione. L'etichetta del token recita "un solo vault". L'API dice il contrario [1].

1Password ha confermato: il comportamento è intenzionale. Lo scoping granulare è in roadmap, senza data [2].

A cosa accede davvero il token

Gil Portnoy e Henry, scrivendo per Token Security, hanno documentato cinque endpoint API che un service-account token "da un solo vault" può raggiungere con esito pienamente positivo [1]:

/api/v2/users restituisce ogni utente dell'organizzazione: UUID, nome, email, stato, tipo, timestamp dell'ultima autenticazione. /api/v1/groups restituisce ogni gruppo con i relativi permessi e stato. I comandi CLI per l'appartenenza ai gruppi, per gli utenti e i permessi dei vault e per i gruppi di vault restituiscono tutti dati reali. /api/v3/account restituisce i metadati dell'account. /api/v2/vault/{id}/vaultaccess restituisce informazioni sull'accesso al vault.

Nessuno di questi endpoint ha come ambito il singolo vault per cui il token era stato generato. Al token era stato detto "leggi un vault". L'API gli ha consegnato la mappa dell'intera organizzazione [1].

Il punto più netto è questo: l'enumerazione non funziona attraverso l'SDK ufficiale di 1Password. Quel percorso restituisce UNSUPPORTED o FORBIDDEN. Funziona invece tramite l'API interna della CLI, che i ricercatori hanno dovuto analizzare in ingegneria inversa. Lo "scope" è una restrizione lato client imposta dall'SDK. La credenziale sottostante consente lettura su scala organizzativa. Un attaccante non usa il vostro SDK [1].

I ricercatori hanno costruito il client in circa 420 righe di Python. Cinque endpoint API. Visibilità completa sull'organizzazione. Hanno pubblicato l'analisi il 16 luglio [1].

La serratura non è il problema. Il mazzo di chiavi sì.

I ricercatori su questo punto sono cauti. La crittografia è genuinamente robusta. L'implementazione SRP usa la prova a conoscenza zero standardizzata dalle RFC: il server non vede mai la password, il client non vede mai il salt e ogni fallimento di autenticazione restituisce lo stesso messaggio di errore, così che un attaccante non ricavi alcuna informazione. 1Password ha documentato le proprie deviazioni non standard (fra cui un verso dei Beatles tratto da "Penny Lane" nascosto in una costante crittografica come easter egg) e tali deviazioni sono neutre dal punto di vista della sicurezza [1].

Il problema non è la serratura. È ciò che la chiave apre. Quando una credenziale è etichettata come "con ambito limitato a un solo vault", gli amministratori la forniscono agli agenti convinti che il raggio d'impatto sia ridotto. L'agente riceve una credenziale. La credenziale riceve l'organigramma. Nessuno lo ha voluto, ma nessuno può nemmeno vederlo accadere [1].

Quando si fornisce a un agente un token "con ambito", l'agente opera nell'ambito che l'API applica effettivamente, non in quello descritto dall'etichetta. Se l'agente viene compromesso — attraverso un prompt injection, un file di convenzione avvelenato, un attacco alla supply chain o uno qualsiasi dei vettori che le difese basate sul testo non possono chiudere del tutto — l'attaccante non ottiene un solo vault. Ottiene la topologia organizzativa: chi appartiene a quale gruppo, chi ha accesso a quali vault, quando ciascuna persona si è autenticata l'ultima volta. È la fase di ricognizione di un breach, consegnata in un'unica chiamata API [1].

Lo scarto fra ambito documentato ed ambito effettivo non è esclusivo di 1Password. Ogni API di gestione delle credenziali prende decisioni autorizzative implicite che gli amministratori non vedono. Ciò che Token Security ha dimostrato è che lo scarto è reale, misurabile e sfruttabile con un weekend di lavoro e un hook di Frida [1].

Cosa fa di diverso un vault progettato per questo

Il compito di una credenziale è sopravvivere al mondo in cui si trova. Se un token "con ambito" può mappare in silenzio la vostra organizzazione, quell'ambito non è mai stato reale. È stata un'etichetta.

Clavitor non etichetta le credenziali e spera. L'agente riceve una singola credenziale con nome esplicito, recuperata in tempo reale nell'istante della chiamata, iniettata in un'unica richiesta, e poi scomparsa. Non esiste un token permanente che un attaccante possa riutilizzare. Non esiste un endpoint di mappa organizzativa nascosto dietro un'etichetta di ambito che nessuno ha verificato. Il vault non espone all'agente possibilità di enumerazione. L'agente raggiunge ciò per cui è stato nominato, e nient'altro.

Ogni accesso viene registrato sul singolo agente che lo ha effettuato, sul vault e non sull'endpoint su cui l'agente è in esecuzione. Se un token viene compromesso, il raggio d'impatto è l'ambito di quella singola chiamata, non la topologia organizzativa che vi sta dietro.

I principi dietro a un vault che applica lo scope anziché limitarsi a etichettarlo: The Ten Rules of Credential Management

Clavitor (@clavitorai) è il credential vault creato per gli agenti AI, e contro di essi. clavitor.ai

Fonti

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — thread su X sull'individuazione dell'escalation di ambito, 16 luglio 2026 — "1Password confirmed this is by design, to support vault-management workflows"