Доступ ИИ-агентов расширяется быстрее, чем средства управления идентификацией успевают его контролировать28.10.2026 17:30

При поддержке 1Password

Предприятия встроили ИИ-агентов в системы, на которых держится их бизнес, — и сделали это быстрее, чем научились ими управлять. Разрыв между тем, что агент способен сделать, и тем, что кто-либо в организации может увидеть, одобрить или отозвать, весьма значителен. Именно в сфере безопасности идентификационных данных этот разрыв и проявляется, а агенты с избыточными привилегиями уже показывают, насколько слабо организации контролируют их доступ.

Это несоответствие наглядно демонстрирует новое исследование 1Password: 65% разработчиков ожидают или поощряют использовать ИИ-агентов, тогда как лишь 33% заявляют, что располагают по-настоящему безопасным способом это делать. Этот разрыв отражает более широкую проблему управления, с которой сталкиваются организации: они развертывают ИИ-агентов раньше, чем выстраивают механизмы контроля над ними, говорит Джейсон Меллер, вице-президент по продуктам 1Password.

«Проблема в том, что с точки зрения внедрения агентного ИИ мы почти вышли на финишную прямую, но всё ещё находимся в самом начале обсуждения того, как закрыть разрыв в управлении, — говорит Меллер. — Из-за этого организации оказались в положении догоняющих. Темпы изменений настолько стремительны, что если организации не учатся и не адаптируются практически ежедневно, у них нет ни единого шанса опередить агентов или новых злоумышленников, вооружённых ИИ».

ИИ-агенты унаследовали несостоятельную модель доступа

Привычки в области безопасности, которые достаются агентам по наследству, и прежде были весьма шаткими. По данным 1Password, 71% респондентов обращаются с секретами как минимум одним небезопасным способом. Среди разработчиков 24% жёстко прописывают учётные данные в коде, 20% передают их через Slack или электронную почту, а 43% работают без специального хранилища.

Эти практики существовали за годы до появления агентов, и организации мирились с ними, поскольку то, как программы используют учётные данные, было предсказуемым. ИИ-агенты меняют это допущение. Они используют предоставленный им доступ для выполнения задачи, из-за чего командам безопасности трудно в реальном времени контролировать, к чему именно агенты обращаются.

«Мы привыкли к компьютерным программам, которые действуют детерминированно, но поведение агентов мы пока не можем предсказать полностью, — говорит Меллер. — Поэтому нам нужно создать совершенно новый набор систем и подходов, чтобы использовать их безопасно».

Раньше учётные данные, жёстко прописанные в скрипте, оставались скрытым риском, который кто-то ещё должен был обнаружить. На машине, где работает агент, те же самые данные теперь доступны для всего, что агент сочтёт нужным. Агенты могут причинить вред и без злого умысла — просто используя предоставленный доступ так, как команды безопасности не ожидают.

«Если ИИ-агент на вашем компьютере увидит учётные данные, которые могут пригодиться для выполнения вашего поручения, он их использует — независимо от того, разрешали вы это или нет, — говорит Меллер. — Первый шаг — убрать этот постоянный, жёстко прописанный доступ с машины и перенести его в хранилище, чтобы видеть, что на самом деле выполняет работу».

Поскольку 40% разработчиков предоставляют постоянный доступ к системам или учётным данным, многие агенты сегодня имеют доступ к конфиденциальным системам и данным сверх того, что требует задача. Это повышает цену каждого действия агента: он может раскрыть или неправомерно использовать конфиденциальную информацию прежде, чем кто-либо об этом узнает. Нечеловеческие идентичности с избыточными привилегиями уже наносят ущерб: 27% респондентов сообщили, что столкнулись с инцидентом безопасности или утечкой по вине такой идентичности.

ИИ-агенты получают доступ к большему объёму данных, чем им разрешено

Именно в доступе сходятся ценность и риски агента. В 41% организаций агенты обращаются к данным, использовать которые им никогда не разрешали. Эта закономерность прослеживается во всех изученных категориях: фактический доступ примерно вдвое превышает санкционированный.

Отчасти причина в том, что агентами управляют с помощью инструментов, созданных для людей. 35% организаций управляют ИИ-агентами в рамках существующих процессов управления идентификацией и доступом, а 21% вообще не формализовали свой подход. Поскольку агент занимает промежуточное положение между пользователем и служебной учётной записью, он может войти в одну систему через процедуру входа для человека, а в другую попасть через серверную интеграцию. Таким образом, одна задача может задействовать учётные данные двух разных типов.

71% респондентов сообщают о недостаточной прозрачности в отношении того, какие агенты используют какие учётные данные. Даже среди организаций, считающих свой подход высокозащищённым, половина всё равно отмечает пробелы в видимости использования учётных данных. В основе всего этого лежит банальная проблема идентификации: многим организациям трудно отделить действия агента от действий человека.

В результате команды безопасности не могут определить, когда агент вышел за границы доступа, или восстановить картину произошедшего впоследствии. К тому моменту, когда его активность привлечёт внимание, организации, возможно, придётся выяснять, что сделал агент, какие учётные данные использовал и кто должен за это отвечать.

Нерешённая проблема атрибуции

Когда что-то ломается, никто не может договориться, кто должен за это отвечать. На вопрос о том, кто несёт ответственность на практике, ответы распределились между руководителями команд, отдельными пользователями и топ-менеджерами, причём 65% заявили, что ответственность должен нести кто-то иной, чем нынешний владелец.

Сами агенты ответственность нести не могут. «Агенты — не люди. У них нет правосубъектности, поэтому ответственность должна быть разделена между пользователем и командой безопасности, которая устанавливает ограничения», — говорит Меллер.

Разделённая ответственность — одновременно правильный ответ и самый трудный для практической реализации, ведь чтобы распределить её, нужно восстановить, что произошло на самом деле. Агент часто проходит аутентификацию с учётными данными человека, а значит, в журнале аудита фиксируется имя того, кто мог понятия не иметь, чем занимается агент.

Атрибуция зависит от журнала аудита, который отличает агента от человека и связывает каждое действие с полномочиями, стоящими за ним. Без таких доказательств организациям приходится распределять ответственность, не имея достоверной картины произошедшего.

Что руководителям следует делать уже сейчас

На вопрос, что придало бы организациям достаточно уверенности для более широкого развертывания агентов, лишь 5% ответили, что им ничего не нужно. Остальные назвали конкретные механизмы контроля, в том числе централизованное представление о доступе людей и агентов (52%), учётные данные «точно в срок», срок действия которых истекает после каждой задачи (47%), полные журналы аудита (51%) и чёткую ответственность за действия каждого агента (53%). Добиться этого можно несколькими способами:

1. Выявите все идентичности, уже взаимодействующие с вашими системами

Невозможно управлять тем, что не инвентаризировано, и никакие политики сами по себе этот пробел не закроют. Это означает, что нужно смотреть дальше одобренных ИТ-отделом приложений — на служебные учётные записи, API-ключи и агентов, работающих вне традиционных систем идентификации, в том числе в браузерах и на локальных устройствах.

2. Распространите управление на машины разработчиков и конечные устройства

Значительная часть рисков возникает локально: учётные данные жёстко прописаны в скриптах, хранятся в текстовых файлах или остаются в репозитории на той же машине, где работает агент. Управление, которое ограничивается периметром, упустит из виду то место, где разработчики и агенты фактически выполняют свою работу.

3. Замените постоянный доступ ограниченными правами «точно в срок»

Предоставление доступа только после одобрения запроса и его отзыв по завершении работы не позволяют разрешениям задерживаться дольше необходимого.

4. Стремитесь полностью исключить учётные данные из контекста агента

Более надёжный подход — выполнять аутентификацию через посредника вне модели: доверенный центр хранит секрет и выдаёт кратковременный доступ в момент запроса. Если учётные данные никогда не попадают в контекстное окно агента, он не сможет раскрыть то, чего никогда не видел, или оставить после себя доступ.

5. Создайте журнал аудита, фиксирующий, кто или что авторизовал каждого агента

Каждое действие должно отслеживаться до ответственного за него человека или системы. Атрибуция — основа всех перечисленных выше мер контроля, поскольку организации не могут надёжно применять политики или расследовать активность, не зная, что санкционировало действие.

«Сегодня судьбу трансформации с помощью ИИ решают рядовые сотрудники — каждый сам по себе, а это недопустимо и приведёт к целому ряду весьма плачевных последствий, — говорит Меллер. — Успеха добьются те компании, которые дадут этим сотрудникам безопасный способ делать то, что они уже и так делают».

Узнайте больше о 1Password Unified Access — платформе безопасности идентификационных данных для управления доступом людей, ИИ-агентов и машинных рабочих нагрузок. Для организаций, стремящихся защитить доступ ИИ-агентов, Unified Access предлагает 1Password Privileged Access, позволяющий предоставлять агентам доступ «точно в срок» без постоянных привилегий, а 1Password Credential Broker (сейчас в открытой предварительной версии) выдаёт машинам и агентам ограниченные учётные данные во время выполнения.

Методология: 1Password провела это исследование в форме онлайн-опроса 1 000 штатных сотрудников в США, работающих в компаниях численностью не менее 250 человек. Выборка поровну разделена между специалистами по ИТ/безопасности и разработчиками/инженерами и охватывает компании разного размера, сотрудников разного уровня и разные отрасли. Данные собирались с 26 мая по 3 июня 2026 года.

Спонсорские статьи — это материалы, подготовленные компанией, которая либо оплачивает публикацию, либо имеет деловые отношения с VentureBeat; такие материалы всегда имеют чёткую маркировку. За дополнительной информацией обращайтесь по адресу sales@venturebeat.com.

Полный текст статьи читайте на VentureBeat.ru