Het label op het inloggegeven is niet de scope van het inloggegeven.
Een 1Password-servicetoken met scope op één kluis kan de hele organisatie in kaart brengen: elke gebruiker, elke groep, elk toegangsrecht. Het label zei één kluis. De API was het daar niet mee eens. Scope moet worden afgedwongen, niet gelabeld.
De cryptografie is ondoordringbaar. RFC 5054 SRP-6a, AES-256-GCM, constant-time vergelijkingen, zero-knowledge-bewijs. 1Password heeft de cryptografie goed voor elkaar. Wat ze fout hebben is het etiket op het blik.
Deze maand hebben twee engineers van Token Security drie dagen besteed aan het reverse-engineeren van 1Passwords eigen SRP-authenticatieprotocol. Ze zochten niet naar een kwetsbaarheid. Ze probeerden een SCIM bridge te vervangen door een Python-client voor tooling rond non-human identities. Wat ze vonden was een kloof tussen wat het inloggegeven zegt te kunnen doen en wat het daadwerkelijk kan doen [1][2].
Een service-accounttoken met scope op één kluis, met alleen leesrechten, kan elke gebruiker in de organisatie oplijsten. Elke groep. Elk groepslidmaatschap. Elk toegangsrecht op elke kluis. Namen, e-mailadressen, statussen, laatste authenticatietijdstippen. Het label van de token zegt "één kluis." De API zegt iets anders [1].
1Password heeft het bevestigd. Het gedrag is zo bedoeld. Granulaire scoping staat op de roadmap, zonder datum [2].
Wat de token daadwerkelijk bereikt
Gil Portnoy en Henry, schrijvend voor Token Security, documenteerden vijf API-endpoints waar een service-accounttoken met "één kluis"-scope met volledig succes langs kan [1]:
/api/v2/users geeft elke gebruiker in de organisatie terug: UUID, naam, e-mailadres, status, type, laatste authenticatietijdstip. /api/v1/groups geeft elke groep terug met zijn rechten en status. De CLI-commando's voor groepslidmaatschap, kluisgebruikers en rechten, en kluizen en groepen geven allemaal live data terug. /api/v3/account geeft accountmetadata terug. /api/v2/vault/{id}/vaultaccess geeft informatie over kluistoegang terug.
Geen van deze endpoints is scoped op de ene kluis waar de token voor is aangemaakt. De token was verteld: "lees één kluis." De API gaf hem een kaart van de hele organisatie [1].
En dan het scherpere punt: de enumeratie werkt niet via 1Passwords officiële SDK. Dat pad geeft UNSUPPORTED of FORBIDDEN terug. Het werkt via de interne API van de CLI, die de onderzoekers moesten reverse-engineeren. De "scope" is een client-side SDK-beperking. Het onderliggende inloggegeven heeft organisatiebrede leestoegang. Een aanvaller gebruikt niet jouw SDK [1].
De onderzoekers bouwden de client in ongeveer 420 regels Python. Vijf API-endpoints. Volledig zicht op de organisatie. Ze publiceerden het verslag op 16 juli [1].
Het slot is niet het probleem. De sleutelhanger wel.
De onderzoekers zijn voorzichtig op dit punt. De cryptografie is echt sterk. De SRP-implementatie gebruikt een volgens RFC gestandaardiseerd zero-knowledge-bewijs: de server ziet nooit het wachtwoord, de client ziet nooit de salt, en elke mislukte authenticatie geeft dezelfde foutmelding terug zodat een aanvaller niets leert. 1Password heeft hun eigen afwijkingen van de standaard gedocumenteerd (waaronder een songtekstregel van The Beatles uit "Penny Lane", verstopt in een cryptografische constante als easter egg) en die afwijkingen zijn veiligheidsneutraal [1].
Het probleem is niet het slot. Het is wat de sleutel opent. Wanneer een inloggegeven gelabeld is als "scoped op één kluis", voorzien beheerders agents ervan in de veronderstelling dat de impact smal blijft. De agent krijgt een inloggegeven. Het inloggegeven krijgt de organigram. Niemand had dat bedoeld, maar niemand kan het ook zien gebeuren [1].
Wanneer je een agent een "scoped" token geeft, opereert de agent binnen de scope die de API daadwerkelijk afdwingt, niet de scope die het label beschrijft. Als de agent wordt gecompromitteerd, via een prompt injection, een vergiftigd convention-bestand, een supply-chain-aanval of een van de vectoren die tekstgebaseerde verdediging niet volledig kan sluiten, krijgt de aanvaller niet één kluis. Die krijgt de organisatietopologie: wie zit in welke groep, wie heeft toegang tot welke kluizen, wanneer iemand voor het laatst is geauthenticeerd. Dat is de verkenningsfase van een inbreuk, geleverd in één API-call [1].
De kloof tussen gedocumenteerde scope en effectieve scope is niet uniek voor 1Password. Elke API voor inloggegevensbeheer neemt impliciete autorisatiebeslissingen die beheerders nooit zien. Wat Token Security heeft bewezen is dat die kloof echt, meetbaar en exploiteerbaar is met een weekend werk en een Frida hook [1].
Wat een kluis die hiervoor gebouwd is anders doet
De taak van een inloggegeven is om de wereld te overleven waarin het zit. Als een "scoped" token je organisatie stil in kaart kan brengen, was de scope nooit echt. Het was een label.
Clavitor labelt inloggegeven niet en hoopt dan het beste. De agent krijgt één expliciet benoemd inloggegeven, live opgehaald op het moment van de call, geïnjecteerd in één request, en weg. Er is geen blijvende token die een aanvaller kan hergebruiken. Er is geen endpoint met een organigramkaart achter een scopelabel dat niemand heeft geverifieerd. De kluis stelt enumeratie niet beschikbaar aan de agent. De agent bereikt waarvoor hij benoemd is, en verder niets.
Elke toegang wordt gelogd op de specifieke agent die hem uitvoert, in de kluis, niet op het endpoint waarop de agent draait. Als een token gecompromitteerd is, is de impact de scope van die ene call, niet de organisatietopologie erachter.
De principes achter een kluis die scope afdwingt, in plaats van hem te labelen: De tien regels van inloggegevensbeheer
Clavitor (@clavitorai) is de inloggegevenskluis gebouwd voor AI-agents, en ertegen. clavitor.ai
Bronnen
[1] Token Security (Gil Portnoy, Henry) — Reverse-engineeren van 1Passwords eigen SRP-authenticatieprotocol — @TheTokenSec
[2] @TheTokenSec — X-thread over de scope-escalatiebevinding, 16 juli 2026 — "1Password bevestigde dat dit zo bedoeld is, om vault-managementworkflows te ondersteunen"