Merkelappen på legitimasjonen er ikke omfanget av legitimasjonen.

Kryptografien er vanntett. RFC 5054 SRP-6a, AES-256-GCM, sammenligninger med konstant tid, nullkunnskapsbevis. 1Password fikk kryptografien riktig. Det de tok feil på, er merkelappen på boksen.

Denne måneden brukte to ingeniører i Token Security tre dager på å reversere 1Passwords proprietære SRP-autentiseringsprotokoll. De lette ikke etter et sårbarhetspunkt. De forsøkte å erstatte en SCIM-bro med en Python-klient for verktøy som håndterer ikke-menneskelige identiteter. Det de fant, var et gap mellom det legitimasjonen sier den kan gjøre, og det den faktisk kan gjøre [1][2].

Et tjenestekonto-token avgrenset til én hvelv, med lesetillatelser, kan liste hver bruker i organisasjonen. Hver gruppe. Hvert gruppemedlemskap. Hver hvelvtillatelse på tvers av alle hvelv. Navn, e-postadresser, statuser, tidspunkter for siste autentisering. Tokenets merkelapp sier «én hvelv». API-et sier noe annet [1].

1Password har bekreftet det. Oppførselen er tilsiktet. Finmasket avgrensning er på veikartet uten dato [2].

Hva tokenet faktisk når

Gil Portnoy og Henry, som skriver for Token Security, dokumenterte fem API-endepunkter som et tjenestekonto-token for «én hvelv» kan treffe med fullt hell [1]:

/api/v2/users returnerer hver bruker i organisasjonen: UUID, navn, e-post, status, type, tidspunkt for siste autentisering. /api/v1/groups returnerer hver gruppe med tillatelser og status. CLI-kommandoene for gruppemedlemskap, hvelvbrukere og tillatelser, og hvelvgrupper returnerer alle levende data. /api/v3/account returnerer kontometadata. /api/v2/vault/{id}/vaultaccess returnerer informasjon om hvelvtilgang.

Ingen av disse endepunktene er avgrenset til den ene hvelven tokenet ble utstedt for. Tokenet ble fortalt «les én hvelv». API-et ga det et kart over hele organisasjonen [1].

Her er det skarpere poenget: oppregningen fungerer ikke gjennom 1Passwords offisielle SDK. Den veien returnerer UNSUPPORTED eller FORBIDDEN. Den fungerer gjennom CLI-ens interne API, som forskerne måtte reversere. «Omfanget» er en klient-side SDK-restriksjon. Den underliggende legitimasjonen er organisasjonsomfattende lesing. En angriper bruker ikke SDK-en din [1].

Forskerne bygde klienten på omtrent 420 linjer Python. Fem API-endepunkter. Full organisasjonssynlighet. De publiserte rapporten 16. juli [1].

Låsen er ikke problemet. Nøkkelknippet er det.

Forskerne er nøye med dette poenget. Kryptografien er faktisk sterk. SRP-implementeringen bruker RFC-standardisert nullkunnskapsbevis: serveren ser aldri passordet, klienten ser aldri saltet, og hver autentiseringsfeil returnerer samme feilmelding, slik at en angriper ikke lærer noe. 1Password har dokumentert sine egne avvik fra standarden (inkludert en Beatles-tekst fra «Penny Lane» gjemt i en kryptografisk konstant som en påskeegg) og avvikene er sikkerhetsmessig nøytrale [1].

Problemet er ikke låsen. Det er hva nøkkelen åpner. Når en legitimasjon er merket «avgrenset til én hvelv», setter administratorer agenter i drift med den i tro på at skadeomfanget er smalt. Agenten får en legitimasjon. Legitimasjonen får organisasjonskartet. Ingen ønsket det, men ingen kan se at det skjer heller [1].

Når du gir en agent et «avgrenset» token, opererer agenten innenfor det omfanget API-et faktisk håndhever, ikke det omfanget merkelappen beskriver. Hvis agenten kompromitteres, gjennom en prompt-injection, en forgiftet konfigurasjonsfil, et forsyningskjedeangrep, eller noen av vektorene som tekstbaserte forsvar ikke kan lukke fullt ut, får ikke angriperen én hvelv. De får den organisatoriske topologien: hvem som er i hvilken gruppe, hvem som har tilgang til hvilke hvelv, når hver person sist autentiserte seg. Det er kartleggingsfasen av et brudd, levert i én enkelt API-kall [1].

Gapet mellom dokumentert omfang og effektivt omfang er ikke unikt for 1Password. Hver legitimasjonsadministrerende API tar implisitte autorisasjonsbeslutninger som administratorer aldri ser. Det Token Security beviste, er at gapet er reelt, målbart og utnyttelig med en helg med arbeid og en Frida-hook [1].

Hva et hvelv bygget for dette gjør annerledes

Legitimasjonens oppgave er å overleve verdenen den befinner seg i. Hvis et «avgrenset» token stille og rolig kan kartlegge organisasjonen din, var omfanget aldri reelt. Det var en merkelapp.

Clavitor merker ikke legitimasjon og håper det beste. Agenten får én eksplisitt navngitt legitimasjon, hentet i sanntid i øyeblikket kallet skjer, injisert i én enkelt forespørsel, og borte. Det finnes ingen stående token som en angriper kan gjenbruke. Det finnes ingen kartleggingsendepunkt bak en omfangsmerkelapp som ingen verifiserte. Hvelvet utsetter ikke oppregning for agenten. Agenten når det den ble navngitt for å nå, og ingenting annet.

Hver tilgang logges til den spesifikke agenten som utførte den, i hvelvet, ikke på endepunktet agenten kjører på. Hvis et token kompromitteres, er skadeomfanget det ene kallets omfang, ikke den organisatoriske topologien bak det.

Prinsippene bak et hvelv som håndhever omfang i stedet for å merke det: The Ten Rules of Credential Management

Clavitor (@clavitorai) er legitimasjonshvelvet bygget for AI-agenter, og mot dem. clavitor.ai

Kilder

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

[2] @TheTokenSec — X-tråd om funnet om omfangseskalering, 16. juli 2026 — "1Password confirmed this is by design, to support vault-management workflows"