Etiketten på autentiseringsuppgiften är inte uppgiftens omfattning.

Kryptografin är ogenomtränglig. RFC 5054 SRP-6a, AES-256-GCM, jämförelser med konstant tidsåtgång, nollkunskapsbevis. 1Password fick kryptografin rätt. Det de fick fel är etiketten på burken.

Denna månad ägnade två ingenjörer på Token Security tre dagar åt att baklängeskonstruera 1Passwords proprietära SRP-autentiseringsprotokoll. De letade inte efter en sårbarhet. De försökte ersätta en SCIM-brygga med en Python-klient för verktyg riktade mot icke-mänskliga identiteter. Det de hittade var en klyfta mellan vad autentiseringsuppgiften säger att den kan göra och vad den faktiskt kan göra [1][2].

En tjänstekontotoken som avgränsats till ett valv, med läsbehörighet, kan lista varje användare i organisationen. Varje grupp. Varje gruppmedlemskap. Varje valvbehörighet i samtliga valv. Namn, e-postadresser, status, tidsstämplar för senaste autentisering. Tokenets etikett säger "ett valv". API:t säger något annat [1].

1Password bekräftade. Beteendet är avsiktligt. Finmaskig avgränsning finns på färdplanen utan datum [2].

Vad tokenet faktiskt når

Gil Portnoy och Henry, som skrev för Token Security, dokumenterade fem API-slutpunkter som en "ett-valv"-token för tjänstekonto kan nå med fullständig framgång [1]:

/api/v2/users returnerar varje användare i organisationen: UUID, namn, e-postadress, status, typ, tidsstämpel för senaste autentisering. /api/v1/groups returnerar varje grupp med dess behörigheter och status. CLI-kommandona för gruppmedlemskap, valvanvändare och behörigheter samt valvgrupper returnerar allt levande data. /api/v3/account returnerar kontometadata. /api/v2/vault/{id}/vaultaccess returnerar information om valvåtkomst.

Ingen av dessa slutpunkter är avgränsad till det enskilda valv som tokenet skapades för. Tokenet fick beskedet "läs ett valv". API:t gav det en karta över hela organisationen [1].

Här är den skarpare poängen: uppräkningen fungerar inte via 1Passwords officiella SDK. Den vägen returnerar UNSUPPORTED eller FORBIDDEN. Den fungerar via CLI:ns interna API, som forskarna var tvungna att baklängeskonstruera. "Omfattningen" är en SDK-restriktion på klientsidan. Den underliggande autentiseringsuppgiften har läsbehörighet i hela organisationen. En angripare använder inte ditt SDK [1].

Forskarna byggde klienten på ungefär 420 rader Python. Fem API-slutpunkter. Full organisationsynlighet. De publicerade rapporten den 16 juli [1].

Låset är inte problemet. Nyckelringen är det.

Forskarna är noggranna med den här punkten. Kryptografin är verkligen stark. SRP-implementationen använder ett RFC-standardiserat nollkunskapsbevis: servern ser aldrig lösenordet, klienten ser aldrig saltet, och varje misslyckad autentisering returnerar samma felmeddelande så att en angripare inte får veta något. 1Password har dokumenterat sina egna avvikelser från standarden (inklusive en Beatles-rad från "Penny Lane" inbakad i en kryptografisk konstant som ett påskägg) och avvikelserna är säkerhetsneutrala [1].

Problemet är inte låset. Det är vad nyckeln öppnar. När en autentiseringsuppgift märks som "avgränsad till ett valv" ställer administratörer ut den till agenter i tron att skadeomfattningen är liten. Agenten får en autentiseringsuppgift. Autentiseringsuppgiften får organisationskartan. Ingen ville det, men ingen ser heller att det händer [1].

När du ger en agent en "avgränsad" token arbetar agenten inom den omfattning som API:t faktiskt tvingar fram, inte den omfattning som etiketten beskriver. Om agenten komprometteras, via en promptinjektion, en förgiftad konventionsfil, ett leverantörskedjeangrepp eller någon av de vektorer som textbaserade försvar inte helt kan stänga, får angriparen inte ett valv. Den får organisationsstrukturen: vilka som finns i vilken grupp, vilka som har tillgång till vilka valv, när varje person senast autentiserade sig. Det är rekognoseringsfasen av ett intrång, levererad i ett enda API-anrop [1].

Klyftan mellan dokumenterad omfattning och faktisk omfattning är inte unik för 1Password. Varje API för hantering av autentiseringsuppgifter fattar underförstådda behörighetsbeslut som administratörer aldrig ser. Det Token Security bevisade är att klyftan är verklig, mätbar och utnyttjbar med en helgs arbete och en Frida-krok [1].

Vad ett valv som byggts för det här gör annorlunda

Autentiseringsuppgiftens uppgift är att överleva världen den befinner sig i. Om en "avgränsad" token tyst kan kartlägga din organisation var omfattningen aldrig verklig. Det var en etikett.

Clavitor etiketterar inte autentiseringsuppgifter och hoppas. Agenten får en enda uttryckligen namngiven autentiseringsuppgift, hämtad live i ögonblicket för anropet, injicerad i en enda förfrågan, och borta. Det finns ingen permanent token som en angripare kan återanvända. Det finns ingen slutpunkt för organisationskartan bakom en omfattningsetikett som ingen verifierat. Valvet utsätter inte uppräkning för agenten. Agenten när det den namngavs att nå, och inget mer.

Varje åtkomst loggas till den specifika agent som utförde den, i valvet, inte på den slutpunkt där agenten körs. Om en token komprometteras är skadeomfattningen det enda anropets omfattning, inte organisationsstrukturen bakom.

Principerna bakom ett valv som verkställer omfattning i stället för att etikettera den: De tio reglerna för hantering av autentiseringsuppgifter

Clavitor (@clavitorai) är autentiseringsvalvet byggt för AI-agenter, och emot dem. clavitor.ai

Källor

[1] Token Security (Gil Portnoy, Henry) — Att baklängeskonstruera 1Passwords proprietära SRP-autentiseringsprotokoll — @TheTokenSec

[2] @TheTokenSec — X-tråd om fyndet om utökad omfattning, 16 juli 2026 — "1Password bekräftade att det här är avsiktligt, för att stödja arbetsflöden för valvhantering"