Die Beschriftung auf den Zugangsdaten ist nicht deren Geltungsbereich.
Ein 1Password-Service-Token, auf einen Tresor begrenzt, kann die gesamte Organisation abbilden: jeden Benutzer, jede Gruppe, jede Berechtigung. Das Etikett sprach von einem Tresor. Die API widersprach. Geltungsbereich muss durchgesetzt werden, nicht beschriftet.
Die Kryptografie ist wasserdicht. RFC 5054 SRP-6a, AES-256-GCM, konstantzeitliche Vergleiche, Zero-Knowledge-Beweis. 1Password hat die Kryptografie richtig gemacht. Was sie falsch gemacht haben, ist die Beschriftung auf der Dose.
Diesen Monat haben zwei Ingenieure von Token Security drei Tage lang das proprietäre SRP-Authentifizierungsprotokoll von 1Password reverse-engineert. Sie suchten nicht nach einer Schwachstelle. Sie versuchten, eine SCIM-Bridge durch einen Python-Client für Werkzeuge im Bereich nicht-menschlicher Identitäten zu ersetzen. Was sie fanden, war eine Lücke zwischen dem, was die Zugangsdaten laut Beschriftung dürfen, und dem, was sie tatsächlich dürfen [1][2].
Ein Service-Konto-Token, auf einen Tresor mit Leseberechtigung begrenzt, kann jeden Benutzer der Organisation auflisten. Jede Gruppe. Jede Gruppenmitgliedschaft. Jede Tresorberechtigung in jedem Tresor. Namen, E-Mail-Adressen, Status, Zeitstempel der letzten Authentifizierung. Das Etikett des Tokens sagt „ein Tresor". Die API sagt etwas anderes [1].
1Password hat das bestätigt. Das Verhalten ist beabsichtigt. Granulare Eingrenzung steht auf der Roadmap, ohne Datum [2].
Was das Token tatsächlich erreicht
Gil Portnoy und Henry haben für Token Security fünf API-Endpunkte dokumentiert, die ein Service-Konto-Token mit der Beschriftung „ein Tresor" mit vollem Erfolg aufrufen kann [1]:
/api/v2/users liefert jeden Benutzer der Organisation: UUID, Name, E-Mail-Adressen, Status, Typ, Zeitstempel der letzten Authentifizierung. /api/v1/groups liefert jede Gruppe mit ihren Berechtigungen und ihrem Status. Die CLI-Befehle für Gruppenmitgliedschaften, Tresorbenutzer und -berechtigungen sowie Tresorgruppen liefern jeweils aktuelle Daten. /api/v3/account liefert Kontometadaten. /api/v2/vault/{id}/vaultaccess liefert Informationen zum Tresorzugriff.
Keiner dieser Endpunkte ist auf den einzelnen Tresor eingegrenzt, für den das Token bereitgestellt wurde. Dem Token wurde gesagt: „lies einen Tresor". Die API gab ihm eine Karte der gesamten Organisation [1].
Der schärfere Punkt: Die Aufzählung funktioniert nicht über das offizielle SDK von 1Password. Dieser Pfad liefert UNSUPPORTED oder FORBIDDEN. Sie funktioniert über die interne API der CLI, die die Forscher reverse-engineern mussten. Der „Geltungsbereich" ist eine SDK-Einschränkung auf Clientseite. Die zugrunde liegende Berechtigung ist organisationsweiter Lesezugriff. Ein Angreifer benutzt nicht Ihr SDK [1].
Die Forscher bauten den Client in rund 420 Zeilen Python. Fünf API-Endpunkte. Volle Sicht auf die Organisation. Die Veröffentlichung erfolgte am 16. Juli [1].
Das Schloss ist nicht das Problem. Der Schlüsselbund.
Die Forscher sind an dieser Stelle vorsichtig. Die Kryptografie ist tatsächlich stark. Die SRP-Implementierung verwendet den standardisierten Zero-Knowledge-Beweis nach RFC: Der Server sieht nie das Passwort, der Client nie den Salt, und jeder Authentifizierungsfehler liefert dieselbe Fehlermeldung, sodass ein Angreifer nichts erfährt. 1Password hat die eigenen nicht standardkonformen Abweichungen dokumentiert (einschließlich einer Beatles-Zeile aus „Penny Lane", versteckt in einer kryptografischen Konstante als Osterei), und die Abweichungen sind sicherheitsneutral [1].
Das Problem ist nicht das Schloss. Es ist das, was der Schlüssel öffnet. Wenn Zugangsdaten als „auf einen Tresor begrenzt" beschriftet sind, stellen Administratoren Agenten damit bereit, weil sie glauben, der Auswirkungsradius sei eng. Der Agent erhält Zugangsdaten. Die Zugangsdaten erhalten das Organigramm. Niemand hat das beabsichtigt, aber niemand kann es auch geschehen sehen [1].
Wenn Sie einem Agenten ein „begrenztes" Token geben, arbeitet der Agent innerhalb des Geltungsbereichs, den die API tatsächlich durchsetzt, nicht innerhalb des Bereichs, den das Etikett beschreibt. Wird der Agent kompromittiert – durch eine Prompt-Injektion, eine vergiftete Konventionsdatei, einen Supply-Chain-Angriff oder einen der Vektoren, die textbasierte Abwehrmaßnahmen nicht vollständig schließen können –, erhält der Angreifer nicht einen Tresor. Er erhält die Organisationsstruktur: Wer in welcher Gruppe ist, wer Zugriff auf welche Tresore hat, wann sich jede Person zuletzt authentifiziert hat. Das ist die Aufklärungsphase eines Einbruchs, geliefert in einem einzigen API-Aufruf [1].
Die Lücke zwischen dokumentiertem und tatsächlichem Geltungsbereich ist kein Alleinstellungsmerkmal von 1Password. Jede API zur Zugangsdatenverwaltung trifft implizite Autorisierungsentscheidungen, die Administratoren nie sehen. Was Token Security nachgewiesen hat: Die Lücke ist real, messbar und mit einem Wochenende Arbeit und einem Frida-Hook ausnutzbar [1].
Was ein dafür gebauter Tresor anders macht
Die Aufgabe der Zugangsdaten ist, in der Welt zu bestehen, in der sie liegen. Wenn ein „begrenztes" Token stillschweigend Ihre Organisation abbilden kann, war der Geltungsbereich nie real. Es war ein Etikett.
Clavitor beschriftet Zugangsdaten nicht und hofft. Der Agent erhält eine explizit benannte Zugangsdaten, live abgerufen im Moment des Aufrufs, in eine einzige Anfrage injiziert, und dann weg. Es gibt kein dauerhaft gültiges Token, das ein Angreifer wiederverwenden könnte. Es gibt keinen Organisations-Karten-Endpunkt hinter einer Bereichsbeschriftung, die niemand geprüft hat. Der Tresor stellt dem Agenten keine Aufzählung zur Verfügung. Der Agent erreicht, wofür er benannt wurde, und nichts weiter.
Jeder Zugriff wird auf den konkreten Agenten protokolliert, der ihn ausgeführt hat – im Tresor, nicht auf dem Endpunkt, auf dem der Agent läuft. Wird ein Token kompromittiert, ist der Auswirkungsradius der Geltungsbereich dieses einen Aufrufs, nicht die Organisationsstruktur dahinter.
Die Prinzipien hinter einem Tresor, der Geltungsbereich durchsetzt statt ihn zu beschriften: Die zehn Regeln der Zugangsdatenverwaltung
Clavitor (@clavitorai) ist der Tresor für Zugangsdaten, gebaut für KI-Agenten – und gegen sie. clavitor.ai
Quellen
[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec
[2] @TheTokenSec — X-Thread zur Feststellung der Bereichserweiterung, 16. Juli 2026 — „1Password confirmed this is by design, to support vault-management workflows"