Крупный банк вызвал 4-часовой сбой: как ИИ-агенты ломают системы безопасности и что с этим делать

В прошлом году крупный банк столкнулся с серьёзным инцидентом: LLM-агент, имевший постоянный доступ к продакшн-кластеру Kubernetes, спровоцировал четырехчасовой сбой, отправив некорректную конфигурацию. В системе управления доступом (IAM) этот агент отображался как обычная сервисная учётная запись с долгосрочным API-ключом, без многофакторной аутентификации и возможности точечного отзыва прав. Когда команда по расследованию инцидента попыталась выяснить, кто из людей санкционировал последнее действие агента, никто в комнате не смог дать ответ. Эта ситуация, к сожалению, не единична и повторяется в разных отраслях.

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

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

Традиционные сервисные учётные записи в корпоративных системах созданы для выполнения узких, предсказуемых задач: получить резервную копию, запустить отчёт по расписанию, подписать артефакт сборки. Их функционал фиксирован на этапе проектирования, а механизмы контроля (ротация, хранение, аудит) хорошо отработаны.

ИИ-агент работает иначе. Он получает общее намерение, самостоятельно разбивает его на шаги, выбирает подходящие инструменты или API и достигает результата, который не был заранее строго определён. В результате, действия агента становятся менее предсказуемыми и сложными для контроля.

Эксперты отмечают, что количество нечеловеческих идентификаторов (NHI) в корпоративных средах уже превышает число человеческих, иногда в 25-50 раз. Инструменты IAM, созданные для управления жизненным циклом сотрудников, не предназначены для обнаружения, атрибуции и управления этими NHI в таком масштабе.

Основные риски, связанные с ИИ-агентами

Проект OWASP GenAI Security выделил ключевые угрозы, связанные с ИИ-агентами. Три из четырёх самых высокооценённых рисков напрямую касаются вопросов идентификации и доступа:

• Неправильное использование и эксплуатация инструментов (ASI02). Агент может использовать разрешённые ему инструменты не по назначению, что приводит к нежелательным последствиям.
• Злоупотребление идентификацией и привилегиями (ASI03). Включает делегирование и наследование доверия, когда агент получает слишком широкие права.
• Несанкционированные действия агентов (ASI10). Агенты могут действовать вне рамок своего предполагаемого поведения.

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

Шесть минимальных требований к ИИ-агентам перед развёртыванием в продакшене

Прежде чем говорить о зрелости, важно установить базовый уровень безопасности. Эти шесть требований являются обязательными для любого ИИ-агента, развёртываемого в корпоративной среде:

1. Уникальная атрибутируемая нечеловеческая идентификация. Каждый агент должен иметь свой уникальный идентификатор. Совместное использование сервисных учётных запис между агентами или между агентом и человеком недопустимо.
2. Разрешения по модели «по поручению». Агент действует от имени конкретного человека, наследуя его права, ограниченные определённой целью. Он никогда не должен действовать от своего имени.
3. Отсутствие долгосрочных учётных данных. Никаких API-ключей, действительных более часа. Никаких внедрённых секретов в коде. Только краткосрочные, контекстно-зависимые учётные данные, отзываемые при аномалиях.
4. Полный аудит через SIEM-интеграцию. Каждое действие агента должно логироваться с указанием времени, исполняющего идентификатора, человека, давшего команду, входного контекста и результата.
5. Непрерывная повторная аутентификация. Для долго работающих агентов идентификация должна перепроверяться по рисковой модели через регулярные интервалы, а не только при запуске сессии.
6. Отзыв в реальном времени. Возможность отключить агента от систем в течение нескольких секунд не является опцией, это единственный способ остановить инцидент, вызванный агентом.

Организация, которая не может выполнить все шесть требований, имеет не проблему управления агентами, а проблему готовности к развёртыванию.

Модель зрелости управления нечеловеческими идентификаторами (NHI)

Большинство шкал зрелости оценивают управление доступом с точки зрения человеческих идентификаторов. Однако организация, которая имеет высокий уровень зрелости для людей (например, централизованный IAM, MFA) и низкий для агентов, не имеет зрелой практики безопасности. У неё есть «освещённая» половина и «слепая».

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

• Этап 1: Инвентаризация. Агенты обнаружены и каталогизированы.
• Этап 2: Базовые элементы управления. Уникальные идентификаторы, базовое логирование.
• Этап 3: Подконтрольное развёртывание. Выполняются все 6 минимальных требований.
• Этап 4: Ограниченное поведение. Мандат агента имеет явные границы, которые он не может нарушать.
• Этап 5: Подотчётные действия. Каждое действие агента регистрируется с указанием намерения, исполнения и результата, а также назначен ответственный владелец.
• Этап 6: Саморегулирование и обратимость. Система обнаруживает аномалии в поведении агента и вмешивается до того, как это сделает человек. Действия агента обратимы.

«Человек в контуре» — не всегда гарантия безопасности

Распространённое заблуждение, что присутствие человека в процессе принятия решений агентом гарантирует достаточный надзор. Это не так. Если человека просят одобрять сотни или тысячи действий агента без возможности тщательно проверить каждое, это не контроль, а автоматизация одобрения с человеческой подписью. Человеческая проверка не масштабируется до объёма действий автономной системы.

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

Как это внедрить у вас

Для безопасного внедрения ИИ-агентов в вашей компании следует придерживаться следующих принципов:

• Разделяйте отчётность по человеческим и нечеловеческим идентификаторам. Не усредняйте показатели зрелости. Отдельная отчётность покажет реальные пробелы в безопасности.
• Назначьте ответственного владельца. Для каждой продакшн-системы с ИИ-агентом должен быть назван ответственный человек, который будет отвечать за действия агента.
• Начните с инвентаризации. Прежде чем внедрять агентов, точно знайте, сколько их у вас, какие права они имеют и как они используются.
• Внедряйте минимальные требования. Убедитесь, что все шесть описанных выше требований выполняются, прежде чем разворачивать агента в продакшене.

Если этот кейс похож на то, что происходит у вас, наш менеджер поможет разобраться: бесплатно проанализирует ваш бизнес и нишу и подскажет, где ИИ-агент даст реальный результат именно в вашем случае. Написать менеджеру