Нечеткие идентификаторы тормозят работу агентов искусственного интеллекта на этапах проверки безопасности. Джексон Коннелл, старший менеджер по маркетингу продуктов IBM, рассказывает на портале The New Stack о четырех решениях, которые необходимо принять для обеспечения безопасности агентных систем на уровне платформы.

Многие агентные проекты могут успешно пройти этап разработки. Затем они попадают на этап проверки безопасности — и именно здесь все может остановиться. Нечеткие модели идентификации и слишком широкие разрешения быстро становятся препятствием.

Вы, вероятно, видели это: агент службы поддержки клиентов работает хорошо; он обрабатывает заявки и возвраты средств, обеспечивает без сбоев весь рабочий процесс. Затем служба безопасности задает простой вопрос: под чьим идентификатором это работает? Ответ останавливает процесс: это общая учетная запись с широкими разрешениями, без четкого владельца, без журнала аудита и без контроля минимальных привилегий.

Коренная проблема несложная. Это неопределенная идентификация и плохо определенные разрешения. И эта проблема быстро усугубляется. Исследование «Tech Leader Study 2026», проведенное Oxford Economics и IBM, показывает, что опрошенные предприятия планируют развернуть в среднем 1661 ИИ-агента, что на 38% больше, чем сегодня. Каждый новый агент добавляет еще одну идентификацию, которую необходимо защитить, и без четких ограничений проблема быстро усугубляется.

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

Для решения этих проблем разработчики, архитекторы и DevOps-инженеры, создающих агентные системы, а также ИТ-руководители, ответственные за их утверждение, могут воспользоваться следующим руководством.

Четыре решения по идентификации, которые требуются каждой агентной системе

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

Вот четыре наиболее важных выбора, которые необходимо сделать:

Идентификация рабочей нагрузки vs. общие учетные записи служб. Общие учетные записи служб просты в использовании, и именно это делает их опасными. Когда несколько агентов действуют под одной учетной записью, становится трудно определить, что произошло и что пошло не так после этого. Если учетная запись будет скомпрометирована или использована не по назначению, все, чего она касалась, будет раскрыто.

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

Статические ключи API vs. краткосрочные учетные данные. Статические ключи API, как правило, остаются навсегда. Они жестко закодированы в приложениях, передаются между системами и редко меняются — это делает их постоянной уязвимостью, ожидающей эксплуатации.

Краткосрочные учетные данные работают иначе. Они выдаются по запросу, привязаны к конкретной задаче и автоматически истекают. На практике это часто основано на федерации идентификации (например, с использованием токенов OIDC) в сочетании с системами, которые могут выдавать динамические учетные данные во время выполнения, а не хранить долговременные секреты в коде или конфигурации.

Прямая передача учетных данных vs. доступ через брокера. Передача учетных данных непосредственно агенту проста. Она также непрозрачна. У вас нет естественной точки для оценки политики или понимания того, что происходит в реальном времени.

Доступ через брокера вводит в поток контрольную точку. Запросы проходят через брокера, политики оцениваются в реальном времени, и для каждой сессии выдаются временные учетные данные. Это добавляет инфраструктуру, но восстанавливает прозрачность и обеспечение соблюдения политик.

Фрагментированное логирование vs. полная история идентификации. Большинство систем регистрируют то, что произошло. Гораздо меньше систем фиксируют, кто инициировал действие или как оно распространялось по цепочке агентов и служб.

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

Когда компромиссы становятся реальными рисками

Это не абстрактные архитектурные предпочтения. Они проявляются как конкретные уязвимости.

Nightfall AI сообщает, что организации ежегодно раскрывают почти 350 секретов на 100 сотрудников, при этом 35% раскрытых ключей API все еще активны. В сочетании с постоянными учетными данными и общими идентификаторами потенциальный радиус атаки быстро растет.

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

Отладка нарушений на интуитивном уровне

Рассмотрим ситуацию, когда агент, работающий под общей учетной записью с долгосрочным ключом, внезапно резко увеличивает доступ к данным. Это ошибка? Нарушение? Обычное поведение? Сложно сказать. Отзыв ключа может решить проблему, но при этом может нарушить работу полудюжины несвязанных рабочих процессов. Так вы отлаживаете на интуитивном уровне.

Быстрые пути уменьшают трение на начальном этапе и накапливают риски со временем.

Стандартизация идентификации на уровне платформы

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

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

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