Мітка на облікових даних — це не область доступу цих облікових даних.

Криптографія бездоганна. RFC 5054 SRP-6a, AES-256-GCM, порівняння за постійний час, доказ із нульовим розголошенням. 1Password зробив криптографію правильною. Неправильною виявилася мітка на банці.

Цього місяця двоє інженерів із Token Security провели три дні, розбираючи фірмовий протокол автентифікації SRP від 1Password. Вони не шукали вразливість. Вони намагалися замінити SCIM-міст Python-клієнтом для інструментів роботи з нелюдськими ідентифікаторами. Те, що вони знайшли, — це розрив між тим, що облікові дані декларують, і тим, що вони насправді можуть [1][2].

Токен сервісного облікового запису, обмежений одним сховищем із правами лише на читання, може перелічити кожного користувача організації. Кожну групу. Кожне членство в групі. Кожен дозвіл рівня сховища в кожному сховищі. Імена, електронні адреси, стани, час останньої автентифікації. Мітка токена каже «одне сховище». API каже інше [1].

1Password підтвердив. Така поведінка закладена в дизайн. Гранулярне обмеження області доступу є в дорожній карті без зазначеної дати [2].

Що токен насправді охоплює

Ґіл Портной і Генрі, пишучи для Token Security, задокументували п'ять кінцевих точок API, які токен сервісного облікового запису «одного сховища» може викликати з повним успіхом [1]:

/api/v2/users повертає кожного користувача організації: UUID, ім'я, електронну адресу, стан, тип, час останньої автентифікації. /api/v1/groups повертає кожну групу з її дозволами та станом. Команди CLI для членства в групах, користувачів і дозволів сховища, а також груп сховища повертають актуальні дані. /api/v3/account повертає метадані облікового запису. /api/v2/vault/{id}/vaultaccess повертає інформацію про доступ до сховища.

Жодна з цих кінцевих точок не обмежена одним сховищем, для якого токен було видано. Токену сказали «читати одне сховище». API дав йому мапу всієї організації [1].

Ось гостріший момент: перелічення не працює через офіційний SDK 1Password. Цей шлях повертає UNSUPPORTED або FORBIDDEN. Воно працює через внутрішній API CLI, який дослідникам довелося розбирати реверс-інжинірингом. «Область доступу» — це обмеження на боці клієнтського SDK. Самі облікові дані дають читання на рівні організації. Зловмисник не користується вашим SDK [1].

Дослідники побудували клієнт приблизно на 420 рядках Python. П'ять кінцевих точок API. Повна видимість організації. Опис вони опублікували 16 липня [1].

Проблема не в замку. Проблема в зв'язці ключів.

Дослідники обережні в цьому питанні. Криптографія справді сильна. Реалізація SRP використовує стандартизований RFC доказ із нульовим розголошенням: сервер ніколи не бачить пароль, клієнт ніколи не бачить сіль, і кожна невдала автентифікація повертає те саме повідомлення про помилку, тож зловмисник не дізнається нічого. 1Password задокументував власні нестандартні відхилення (зокрема рядок із «Penny Lane» The Beatles, захований у криптографічній константі як великоднє яйце), і ці відхилення нейтральні щодо безпеки [1].

Проблема не в замку. Проблема в тому, що відкриває ключ. Коли облікові дані позначені як «обмежені одним сховищем», адміністратори видають їх агентам, вірячи, що радіус ураження вузький. Агент отримує облікові дані. Облікові дані отримують організаційну структуру. Ніхто цього не планував, але ніхто й не бачить, як це відбувається [1].

Коли Ви даєте агенту «обмежений» токен, агент працює в межах тієї області, яку API реально застосовує, а не тієї, яку описує мітка. Якщо агента скомпрометовано — через ін'єкцію в підказку, отруєний файл конвенцій, атаку на ланцюг постачання чи будь-який інший вектор, який текстові засоби захисту не можуть повністю закрити, — зловмисник отримує не одне сховище. Він отримує топологію організації: хто в якій групі, хто має доступ до яких сховищ, коли кожна людина востаннє автентифікувалася. Це фаза розвідки під час злому, видана одним викликом API [1].

Розрив між задокументованою областю доступу та фактичною не унікальний для 1Password. Кожен API керування обліковими даними ухвалює неявні рішення щодо авторизації, яких адміністратори ніколи не бачать. Те, що довела Token Security, — це те, що розрив реальний, вимірюваний і придатний для експлуатації з вихідними та одним гачком Frida [1].

Чим відрізняється сховище, створене для цього

Завдання облікових даних — вижити в тому середовищі, де вони перебувають. Якщо «обмежений» токен може мовчки відобразити вашу організацію, то область доступу ніколи не була справжньою. Це була мітка.

Clavitor не маркує облікові дані й не сподівається на краще. Агент отримує один явно названий обліковий запис, отриманий у реальному часі в момент виклику, впроваджений в один запит і зниклий. Немає постійного токена, який зловмисник міг би повторно використати. Немає кінцевої точки з мапою організації за міткою області доступу, яку ніхто не перевірив. Сховище не відкриває агенту перелічення. Агент досягає того, для чого його названо, і нічого більше.

Кожен доступ журналюється щодо конкретного агента, який його здійснив, у сховищі, а не на вузлі, де агент працює. Якщо токен скомпрометовано, радіус ураження — це область одного виклику, а не організаційна топологія за ним.

Принципи сховища, яке застосовує область доступу, а не маркує її: Десять правил керування обліковими даними

Clavitor (@clavitorai) — це сховище облікових даних, створене для ШІ-агентів і проти них. clavitor.ai

Джерела

[1] Token Security (Ґіл Портной, Генрі) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — тред в X про знахідку ескалації області доступу, 16 липня 2026 р. — «1Password підтвердив, що це закладено в дизайн для підтримки сценаріїв керування сховищами»