Кратко: безопасность ИИ-агентов в банковской сфере требует таких средств контроля, которые способны отклонять запрещенные действия рабочих нагрузок до их завершения, поскольку оповещение не отменяет полномочия агента. Агент может использовать легитимные учетные данные для создания финансовых рисков без эксплуатации уязвимостей. Aquasec объединяет глубокую видимость на этапе выполнения с локальным применением политик благодаря архитектуре полноценного агента (full agent), применяя настроенные политики внутри работающих рабочих нагрузок без ожидания централизованного анализа. Такой контроль дополняет ограничения на уровне идентификационных данных и одобрение транзакций, блокируя поддерживаемые операции, нарушающие политику, прямо во время выполнения задач агентом.
В чем заключается пробел в управлении безопасностью ИИ-агентов?
Риски вашего банка распространяются на те полномочия, которые предоставляет агенту его рабочая нагрузка, и они могут значительно превышать его назначенную задачу. Безопасность ИИ-агентов должна связывать эту задачу с применимыми ограничениями на доступ и выполнение.
В Kubernetes такие полномочия могут проистекать из учетной записи службы, связанной облачной роли, смонтированных учетных данных и доступных сетевых путей. Инструкции по проверке записей не удаляют учетные данные и не закрывают соединения. Следовательно, тщательно составленный промпт оставляет технические разрешения рабочей нагрузки неизменными. Агент по-прежнему может пытаться совершать действия, которые бизнес никогда не планировал ему поручать.
Почему внутренним ИИ-агентам требуются собственные средства контроля на этапе выполнения?
Подключение агента к производственным инструментам наделяет его решения последствиями в вашей среде. Неправильно сформулированная инструкция или вредоносный промпт, внедренный в документ, могут подтолкнуть его к действиям, которые разрешены его текущими правами доступа.
Блокировка внешних агентов на этапе входа клиента в систему никак не ограничивает внутреннего агента, использующего идентификационные данные рабочей нагрузки. Банк по-прежнему несет эти риски внутри своих кластеров. Безопасность не может ждать программного эксплойта, чтобы подтвердить необходимость вмешательства, поскольку нежелательная операция может использовать действительный набор учетных данных и разрешенное соединение.
В чем недостатки проверок доступа и оповещений для ИИ-агентов?
Контроль идентификационных данных, сканирование образов и установка патчей остаются обязательными. Они снижают избыточные полномочия и устраняют уязвимое ПО. Однако выявление уязвимости оставляет обнаруженный доступ открытым до тех пор, пока что-то его не изменит.
Добавление телеметрии этапа выполнения автоматически не закрывает этот пробел. Датчик может фиксировать операцию, не имея возможности заблокировать ее локально. В модели, которая экспортирует телеметрию для централизованного анализа и реагирования, выполнение может продолжаться, пока принимается решение.
Для агента, подключенного к финансовой системе, это различие имеет принципиальное значение. Расследование уже завершенной операции и предотвращение ее завершения приводят к совершенно разным результатам для банка.
Как банкам разделить наблюдение за ИИ-агентами и действия с их стороны?
Агенту, назначенному для проверки транзакций, не следует автоматически предоставлять полномочия на их инициирование. Используйте выделенные учетные данные и ограничивайте доступные реквизиты ресурсами, необходимыми для его задачи. Требуйте подтверждения от приложения для совершения значимых операций, при этом доступ на чтение должен быть ограничен только необходимыми записями.
Затем перенесите эти границы в работающую рабочую нагрузку. Определите исполняемое поведение и сетевые назначения, необходимые для задачи, и применяйте ограничения к поддерживаемым операциям за пределами этой области. Средства контроля должны срабатывать, когда агент неверно истолковывает инструкцию, не полагаясь на то, что модель сама распознает свою ошибку.
Как Aquasec обеспечивает соблюдение границ для рабочих нагрузок ИИ-агентов?
Мы встраиваем механизм принятия решений о принудительном исполнении непосредственно в работающую рабочую нагрузку с помощью компонента Aquasec Enforcer. Наша архитектура полноценного агента сочетает подробную телеметрию этапа выполнения с принятием локальных решений на основе политик на уровне ядра. В режиме принудительного исполнения он может блокировать поддерживаемые операции, нарушающие настроенную политику, не дожидаясь централизованного анализа или ответа аналитика.
Предотвращение дрифта (Drift Prevention) делает это различие очевидным. Когда агент пытается запустить бинарный файл, появившийся после развертывания, настроенное средство контроля может заблокировать выполнение. Сетевые политики также могут запрещать соединения с неразрешенными назначениями, ограничивая пути, которые в противном случае могли бы оставаться доступными из-за прав доступа рабочей нагрузки.
Эти средства контроля воздействуют на саму операцию. Команды безопасности получают способ ограничивать поддерживаемое поведение рабочей нагрузки до тех пор, пока права доступа не будут исправлены, и при этом принудительное завершение всего контейнера не становится действием по умолчанию. Авторизация на уровне приложения по-прежнему отвечает за решение о том, какие транзакции агент имеет право выполнять.
Как соотносятся подходы к безопасности ИИ-агентов на этапе выполнения?
Оцените, что происходит с инициированной операцией. Приведенное ниже сравнение разделяет оценку защищенности на основе обнаружения и обнаружение на основе телеметрии без локального принудительного контроля. Записи Aquasec предполагают настроенные для принудительного исполнения поддерживаемые средства контроля.
Архитектурное различие заключается в том, может ли компонент безопасности применить ограничение внутри рабочей нагрузки, не дожидаясь отдельного рабочего процесса реагирования.
Каким образом ИИ-агент может создать финансовый риск без использования эксплойта?
Действительный доступ может превратить задачу с нечетко определенной областью действия в непреднамеренную транзакцию.
Пример: агенту по сверке поручено разрешить проблему с неудачным взаиморасчетом. Его рабочая нагрузка обладает учетными данными для осуществления платежей и имеет доступ к внутренней службе переводов. Без отдельной проверки на одобрение он может попытаться провести взаиморасчет повторно с другого финансирующего счета. Каждый шаг может использовать разрешенную операцию.
Этот гипотетический сценарий объясняет возможные риски; он не является зарегистрированным инцидентом с клиентами или измеренным результатом работы продукта. Отсутствующая граница находится между назначенной задачей и полномочиями, доступными для ее выполнения.
Какие ошибки ослабляют средства контроля рабочих нагрузок ИИ-агентов?
Исключения могут заново открыть тот доступ, который политика этапа выполнения должна была ограничить. Не одобряйте широкие исключения только для того, чтобы убрать блокировку. Проверяйте необходимую зависимость и ограничивайте исключение строго тем, что требуется приложению.
Не воспринимайте разрешенное соединение как одобрение транзакции. Если операции чтения и перевода используют одну и ту же разрешенную службу, приложение должно авторизовать их раздельно. Сетевые ограничения рабочей нагрузки не определяют, является ли отдельная финансовая транзакция легитимной.
Чего банкам следует требовать от безопасности ИИ-агентов в дальнейшем?
Банки должны сделать продемонстрированное принудительное исполнение обязательным условием для расширения доступа ИИ-агентов. Прежде чем предоставлять агенту расширенные полномочия, требуйте доказательств того, что средства контроля, защищающие его рабочую нагрузку, способны остановить запрещенное поведение, для предотвращения которого они созданы. Оповещение, которое оставляет операцию без изменений, не соответствует этому стандарту.
Мы внедряем это принудительное исполнение непосредственно в работающую рабочую нагрузку с помощью Aquasec Enforcer. Наша архитектура полноценного агента объединяет глубокую видимость на этапе выполнения с локальным применением политик, позволяя настроенным средствам контроля блокировать поддерживаемые операции без ожидания централизованного анализа или ответа аналитика. Это дает банкам способ ограничить то, что рабочая нагрузка агента может выполнять, наряду с мерами контроля идентификации и приложений, управляющими его доступом.
Посмотрите эту демоверсию, чтобы увидеть, как принудительное исполнение на этапе выполнения от Aquasec меняет исход таких атак в Kubernetes.
FAQ
Чем отличается безопасность агентов ИИ от мониторинга среды выполнения в Aquasec?
Aquasec объединяет телеметрию среды выполнения с локальным применением политик с помощью архитектуры полноценного агента. Для поддерживаемых операций в режиме применения рабочей нагрузке не нужно ждать централизованного анализа, прежде чем настроенное ограничение сможет заблокировать действие.
Может ли безопасность агентов ИИ остановить нецелевое использование действительных учетных данных?
Aquasec может отклонять поддерживаемые операции рабочей нагрузки, нарушающие настроенную политику, даже когда учетные данные доступны. Запрос, который остается разрешенным, по-прежнему требует авторизации и любого необходимого одобрения в приложении.
Охватывает ли эта стратегия безопасности агентов ИИ внешне размещенные агенты?
Применение политик Aquasec распространяется на поддерживаемые рабочие нагрузки, где оно развернуто. Защита кластеров банка не означает автоматическую защиту агентов, работающих на ноутбуках или внешних платформах. Для таких развертываний требуются собственные средства контроля доступа.
Филип Пирсон (Philip Pearson) — полевой технический директор (CTO) с более чем десятилетним опытом руководства в сфере кибербезопасности, включая работу в должности директора по информационной безопасности (CISO) в четырех различных организациях. Он специализируется на внедрении передовых практик безопасности и стратегических инициатив для повышения устойчивости к киберугрозам в облачных средах. Обладая опытом работы как в качестве старшего облачного инженера, так и руководителя по кибербезопасности, Филип привносит богатый багаж знаний в области безопасности Kubernetes, облачных архитектур и моделирования угроз. В его послужном списке — роли, в которых он способствовал развитию концепции Zero Trust, соблюдения требований и управления операционными рисками с помощью дальновидных методологий, защищающих современные и будущие цифровые ландшафты. Филип также является членом Cloud Security Alliance и активно участвует в его работе.
