Безопасность ИИ-агентов: инженерная задача на каждом уровне стека

Почему безопасность ИИ-агентов — инженерная задача

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

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

Безопасность зависит от всего стека агента

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

Сценарий атаки: вредоносные инструкции в документе

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

Как встроить безопасность в работу агентов

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

Идентичность и права агента

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

Политики доступа и подтверждение человеком

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

Проверка инструментов и зависимостей

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

Доказательства безопасности до развёртывания

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

1. Назначенный ответственный должен использовать результаты тестов, чтобы решить, готов ли система к развёртыванию, и обеспечить корректирующие действия по проваленным тестам.
2. Сбои, обнаруженные при тестировании или эксплуатации, должны воспроизводиться, исследоваться и устраняться.
3. Каждая находка может стать повторяемым тестом, позволяющим проверять, что исправление продолжает работать в будущих релизах.

Расследование инцидентов и инструменты защитников

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

Способный ИИ может поддерживать эту работу, помогая находить уязвимости, проверять исправления и расследовать атаки. Его ценность следует оценивать по воспроизводимым находкам, проверяемым исправлениям и ускорению реакции. Примеры включают CrowdStrike SafeMind для тестирования и укрепления защит через повторяющиеся симуляции атак, Palo Alto Networks Prisma AIRS для непрерывного red teaming по мере изменения моделей и приложений, Capital One VulnHunter для ИИ-анализа безопасности кода и ReversingLabs Spectra Assure для ИИ-анализа программных пакетов с целью обнаружения вредоносного ПО и подделок.

NVIDIA OpenShell и Open Secure AI Alliance

NVIDIA OpenShell — это открытая безопасная среда исполнения, которая применяет политики вне досягаемости агента и обеспечивает изолированное выполнение, управляя доступом агентов к данным, сети и системным ресурсам. Партнёры Open Secure AI Alliance строят решения на базе OpenShell: Cisco DefenseClaw добавляет уровень управления, а JFrog интегрируется с OpenShell для сканирования и проверки навыков агентов и применения политик доступа к ним.

Обмен доказательствами в сообществе

Обмен доказательствами того, что не сработало, какие меры контроля оказались эффективными и как были проверены исправления, помогает другим командам укреплять свои системы. Исследования NVIDIA в области безопасности и Open Secure AI Alliance поддерживают этот обмен, привнося исследования, практические инструменты и экспертизу в широкое сообщество безопасности.

Выводы

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