Подпись на учётных данных — это не область их действия.

Криптография безупречна. SRP-6a по RFC 5054, 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 (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — тред в X о находке по расширению области действия, 16 июля 2026 года — "1Password confirmed this is by design, to support vault-management workflows"