SANS: Zero Trust для ИИ-агентов нужно начинать с инвентаризации
Организациям следует начинать Zero Trust для ИИ-агентов с инвентаризации и наблюдаемости, а не с блокировок и политик доступа, говорится в чек-листе SANS. Исследование Veeam показало, что 70% компаний уже используют ИИ-процессы, работающие с чувствительными корпоративными данными без полного надзора, а 67% ИТ-служб не могут полностью отслеживать автономные сценарии, которые создают сотрудники.
Почему политика не работает без реестра агентов
Авторы отмечают, что контроль доступа не даст результата, если у агента нет назначенного владельца, описанной области работы и записи в инвентаре. Прокси или слой авторизации может применять правила только к известным системам; неизвестные агенты остаются вне зоны действия таких мер.
Проблему усиливает shadow AI — самостоятельное применение и создание инструментов сотрудниками. Сначала обычно появляется технология, а затем, если появляется, управление ею. Немедленная блокировка незнакомых сервисов без картины использования способна остановить и легитимные сценарии.
В качестве примера автор приводит инцидент в METR, некоммерческой организации, известной оценкой инцидента Hugging Face с агентами OpenAI. Злоумышленник обнаружил личный экземпляр Amazon EC2 сотрудника с агентным приложением, обошёл аутентификацию и получил через агента API-ключ провайдера моделей. За три недели ключ без лимита расходов был использован на объём токенов, эквивалентный 600 тыс. долларов.
Одной точки наблюдения недостаточно
ИИ-агенты работают в сети, на конечных устройствах, в браузерах и в сторонних SaaS-сервисах. Сетевой сенсор при TLS-шифровании видит адрес назначения и объём данных, но не промпт, вызов инструмента или возможную передачу данных. Endpoint-средства могут не видеть браузерные функции, а SaaS-агенты могут быть незаметны и для сети, и для устройства.
SANS рекомендует сводить несколько классов телеметрии: DNS и SNI, отпечатки JA4 и журналы egress-прокси, данные endpoint о процессах, API-ключах в переменных окружения и локальных средах выполнения агентов. Дополнить картину помогают журналы браузера об расширениях и встроенных помощниках, а также сведения об OAuth-разрешениях, выпуске API-ключей и консолях провайдеров.
LLM-шлюз, например LiteLLM, может централизовать видимость и применение политик, но только для агентов, которые уже направлены через него. Поэтому шлюз не заменяет поиск неизвестных развертываний. Риск особенно заметен в цепочках, где цепочки злоупотребления заимствованным доверием показывает, как доверенные механизмы могут стать точкой входа для атакующего.
Непрерывный аудит и отдельная идентичность
Периодическая проверка быстро теряет актуальность: агента можно развернуть или клонировать за секунды. В такой среде краткоживущие копии способны унаследовать доступ родительского агента, выполнить задачу и исчезнуть до очередного аудита. Поэтому наблюдение должно быть непрерывным, а за результат автоматизированного контроля должен отвечать конкретный сотрудник.
Для содержательных порогов мониторинга SANS предлагает назначать каждому агенту собственную идентичность, привязывать разрешения к активной задаче, ограничивать вывод данных за пределы среды и отделять модель от подключённых сервисов слоем авторизации. Логи должны отражать не только промпты, но и вызовы инструментов и совершённые действия.
Практический вывод для бизнеса: сначала стоит выявить агентов, их владельцев, API-ключи, расходы и точки доступа к данным, затем сопоставить сигналы из разных систем и настроить постоянный контроль. Лишь после этого ограничения, шлюзы и аварийное отключение смогут применяться к известным и атрибутированным объектам.