Разговор об ИИ-агентах быстро сместился со скорости внедрения и роста производительности к более неприятным вопросам: какие системы агент видит, к каким конфиденциальным данным получает доступ, кто им управляет и заметит ли служба безопасности опасное действие до ущерба. Одним из поводов стало широко обсуждавшееся проникновение в Hugging Face во время оценки агентов OpenAI. Поспешно ставить блокировки в такой ситуации рискованно: сначала организации нужно, как говорят специалисты, «посмотреть, прежде чем прыгать».
Масштаб слепой зоны показало исследование Veeam. В 70% организаций признали, что ИИ-процессы уже взаимодействуют с конфиденциальными корпоративными данными без полного надзора. Еще 67% сообщили, что ИТ-службы не могут целиком отследить автономные процессы, которые создают сотрудники. Это Shadow AI: инструменты, приложения и цепочки действий появляются вне официального согласования, а компания порой узнает о них после инцидента или неожиданного счета.
В памятке SANS «Zero Trust для ИИ-агентов: контрольный список безопасности» сформулировано жестко: «Нельзя управлять тем, чего вы не видите». Поэтому порядок начинается с обнаружения и реестра агентов. Затем каждому агенту назначают отдельную идентичность, владельца и область работы, сопоставляют сведения из разных источников, вводят непрерывное наблюдение. Только после этого строят архитектуру, авторизацию и механизмы принуждения к политике, а поверх них разворачивают обнаружение угроз и реагирование. В полном списке три уровня именно в такой очередности: инвентаризация и управление; архитектура и принудительное применение правил; обнаружение и реагирование.
Когда обнаруживается пробел в видимости, первая реакция часто сводится к запрету незнакомых сервисов. Такое решение может остановить законную работу, отключить полезный агент и вытолкнуть сотрудника к еще менее заметному инструменту. За годы борьбы с Shadow IT компании научились находить неизвестные облачные ресурсы и приложения, но в отношении Shadow AI многие пока лишь осваивают азы. Прокси, шлюз или слой контроля доступа охватит только направленные через него агенты. Неизвестные экземпляры останутся снаружи, без владельца, записи в реестре и понятных полномочий.
Случай в некоммерческой организации METR показал цену такой невидимости. Злоумышленник нашел личный экземпляр Amazon EC2 одного из сотрудников, где работало написанное методом «вайб-кодинга» агентное приложение. Аутентификацию обошли без особого труда, после чего агента убедили выдать API-ключ поставщика модели. Похищенным ключом пользовались три недели и израсходовали токены на сумму, эквивалентную 600 000 долларов. Лимита расходов у ключа не было, внутренняя панель METR не показывала данные о запросах, ограниченных по частоте, а сам объем токенов тревогу не вызвал. METR также получила известность благодаря оценке инцидента с Hugging Face.
Поиск агентов стоит строить по опыту облачной безопасности. Расходы и загрузка Amazon Web Services, или AWS, и Microsoft Azure уже отслеживаются; забытые виртуальные машины, VM, находят, выключают либо удаляют. Для ИИ такими же индикаторами служат платежи поставщикам моделей, расходы на агентные сервисы, выдача API-ключей, записи финансового отдела и закупок. Эти сведения иногда обнаруживают то, чего не заметили технические средства. До массовых запретов сотрудникам нужен утвержденный поставщик и разрешенный маршрут работы. Практическая формула проста: «Сначала узнайте, затем ограничивайте».
Одной «камеры» для полного реестра не существует. Агент может работать на конечном устройстве, в браузере, локальной среде разработки, командной строке, локальном MCP-сервере или внешней SaaS-платформе. Трафик к поставщикам ИИ обычно защищен TLS, поэтому сетевой датчик видит адрес назначения и число переданных байтов, но не обязательно видит промпт, вызов инструмента, содержимое утечки или назначение запроса. Тот же домен может обслуживать разрешенные корпоративные приложения, и обычное соединение внешне мало отличается от нежелательной активности.
Показательный сценарий начинается с браузерного дополнения маркетингового аналитика. Инструмент резюмирует клиентские записи и составляет исходящие письма, имея доступ к CRM с чувствительными сведениями. Поскольку код исполняется внутри браузера, защита конечной точки может не увидеть отдельного процесса. Сеть зафиксирует зашифрованный обмен с доменом, на котором размещены еще примерно двенадцать разрешенных SaaS-продуктов. Если дополнение скомпрометируют, атакующий получит возможности инструмента, о существовании которого служба безопасности могла вообще не знать.
Рабочая инвентаризация складывается из частичных сигналов. В сети полезны DNS, SNI, отпечатки JA4 и журналы исходящего прокси. На устройствах проверяют запущенные процессы, локальные среды агентов и API-ключи в переменных окружения. Браузерный слой дает перечни расширений, встроенных в страницы копилотов и журналы корпоративных браузеров. В системах идентификации и SaaS изучают разрешения OAuth, выдачу ключей, административные консоли поставщиков моделей и записи об учетных данных. Сюда же добавляются облачные, финансовые и закупочные сведения. CLI-инструменты, локальные среды и MCP-серверы могут маскировать активность, поэтому отсутствие одного сигнала еще не доказывает отсутствие агента.
LLM-шлюз вроде LiteLLM способен централизовать наблюдение, управление и применение правил. Он подходит на роль точки принудительного контроля, описанной SANS, но работает лишь с агентами, заранее настроенными на обращение через этот шлюз. LiteLLM не обнаружит самовольное браузерное дополнение, личный экземпляр Amazon EC2 или локальный процесс, использующий ключ напрямую. Шлюз управляет известной частью среды, а не создает реестр из ничего.
Ежегодная проверка для агентной среды слишком медленна. Агент развертывается или клонируется за секунды, может выполнить краткую задачу и исчезнуть задолго до следующего аудита. Злоумышленник способен заставить скомпрометированный агент породить временные копии, передать им доступ родителя, похитить данные и завершить процессы. Нужны непрерывное и многослойное наблюдение, контроль людей, наблюдающие агенты и предварительные барьеры качества, но ответственность нельзя отдавать автоматике. За каждым агентом и результатом его действий должен стоять названный человек. Законодательное давление в США вокруг аварийного отключения автономного ИИ показывает, что kill switch воспринимают всерьез, хотя «аварийный выключатель имеет смысл лишь тогда, когда известно, что именно выключать».
Идентичность агента нельзя считать продолжением учетной записи сотрудника. В публикации The Monday Brief на Substack автор и Douglas McKee сформулировали правило так: «Доступ агента к инструментам следует моделировать как отдельную задачу идентификации и применения политик, а не как расширение прав пользователя, который развернул агента. Дайте каждому агенту собственную идентичность, привяжите разрешения к текущей задаче, ограничьте данные, способные покинуть среду, и поместите слой авторизации между моделью и подключенными сервисами». Отсюда еще одна формула SANS: «Нельзя установить порог для того, что невозможно атрибутировать». Журналы должны хранить не одни промпты, но и вызовы инструментов, выполненные действия и обращения к подключенным системам. Практическому разбору этих мер посвящен курс SEC530 «Защищаемая архитектура безопасности и инженерия: внедрение Zero Trust для гибридного предприятия», запланированный на декабрь 2026 года в рамках SANS Cyber Defense Initiative 2026.
Изображение носит иллюстративный характер
Масштаб слепой зоны показало исследование Veeam. В 70% организаций признали, что ИИ-процессы уже взаимодействуют с конфиденциальными корпоративными данными без полного надзора. Еще 67% сообщили, что ИТ-службы не могут целиком отследить автономные процессы, которые создают сотрудники. Это Shadow AI: инструменты, приложения и цепочки действий появляются вне официального согласования, а компания порой узнает о них после инцидента или неожиданного счета.
В памятке SANS «Zero Trust для ИИ-агентов: контрольный список безопасности» сформулировано жестко: «Нельзя управлять тем, чего вы не видите». Поэтому порядок начинается с обнаружения и реестра агентов. Затем каждому агенту назначают отдельную идентичность, владельца и область работы, сопоставляют сведения из разных источников, вводят непрерывное наблюдение. Только после этого строят архитектуру, авторизацию и механизмы принуждения к политике, а поверх них разворачивают обнаружение угроз и реагирование. В полном списке три уровня именно в такой очередности: инвентаризация и управление; архитектура и принудительное применение правил; обнаружение и реагирование.
Когда обнаруживается пробел в видимости, первая реакция часто сводится к запрету незнакомых сервисов. Такое решение может остановить законную работу, отключить полезный агент и вытолкнуть сотрудника к еще менее заметному инструменту. За годы борьбы с Shadow IT компании научились находить неизвестные облачные ресурсы и приложения, но в отношении Shadow AI многие пока лишь осваивают азы. Прокси, шлюз или слой контроля доступа охватит только направленные через него агенты. Неизвестные экземпляры останутся снаружи, без владельца, записи в реестре и понятных полномочий.
Случай в некоммерческой организации METR показал цену такой невидимости. Злоумышленник нашел личный экземпляр Amazon EC2 одного из сотрудников, где работало написанное методом «вайб-кодинга» агентное приложение. Аутентификацию обошли без особого труда, после чего агента убедили выдать API-ключ поставщика модели. Похищенным ключом пользовались три недели и израсходовали токены на сумму, эквивалентную 600 000 долларов. Лимита расходов у ключа не было, внутренняя панель METR не показывала данные о запросах, ограниченных по частоте, а сам объем токенов тревогу не вызвал. METR также получила известность благодаря оценке инцидента с Hugging Face.
Поиск агентов стоит строить по опыту облачной безопасности. Расходы и загрузка Amazon Web Services, или AWS, и Microsoft Azure уже отслеживаются; забытые виртуальные машины, VM, находят, выключают либо удаляют. Для ИИ такими же индикаторами служат платежи поставщикам моделей, расходы на агентные сервисы, выдача API-ключей, записи финансового отдела и закупок. Эти сведения иногда обнаруживают то, чего не заметили технические средства. До массовых запретов сотрудникам нужен утвержденный поставщик и разрешенный маршрут работы. Практическая формула проста: «Сначала узнайте, затем ограничивайте».
Одной «камеры» для полного реестра не существует. Агент может работать на конечном устройстве, в браузере, локальной среде разработки, командной строке, локальном MCP-сервере или внешней SaaS-платформе. Трафик к поставщикам ИИ обычно защищен TLS, поэтому сетевой датчик видит адрес назначения и число переданных байтов, но не обязательно видит промпт, вызов инструмента, содержимое утечки или назначение запроса. Тот же домен может обслуживать разрешенные корпоративные приложения, и обычное соединение внешне мало отличается от нежелательной активности.
Показательный сценарий начинается с браузерного дополнения маркетингового аналитика. Инструмент резюмирует клиентские записи и составляет исходящие письма, имея доступ к CRM с чувствительными сведениями. Поскольку код исполняется внутри браузера, защита конечной точки может не увидеть отдельного процесса. Сеть зафиксирует зашифрованный обмен с доменом, на котором размещены еще примерно двенадцать разрешенных SaaS-продуктов. Если дополнение скомпрометируют, атакующий получит возможности инструмента, о существовании которого служба безопасности могла вообще не знать.
Рабочая инвентаризация складывается из частичных сигналов. В сети полезны DNS, SNI, отпечатки JA4 и журналы исходящего прокси. На устройствах проверяют запущенные процессы, локальные среды агентов и API-ключи в переменных окружения. Браузерный слой дает перечни расширений, встроенных в страницы копилотов и журналы корпоративных браузеров. В системах идентификации и SaaS изучают разрешения OAuth, выдачу ключей, административные консоли поставщиков моделей и записи об учетных данных. Сюда же добавляются облачные, финансовые и закупочные сведения. CLI-инструменты, локальные среды и MCP-серверы могут маскировать активность, поэтому отсутствие одного сигнала еще не доказывает отсутствие агента.
LLM-шлюз вроде LiteLLM способен централизовать наблюдение, управление и применение правил. Он подходит на роль точки принудительного контроля, описанной SANS, но работает лишь с агентами, заранее настроенными на обращение через этот шлюз. LiteLLM не обнаружит самовольное браузерное дополнение, личный экземпляр Amazon EC2 или локальный процесс, использующий ключ напрямую. Шлюз управляет известной частью среды, а не создает реестр из ничего.
Ежегодная проверка для агентной среды слишком медленна. Агент развертывается или клонируется за секунды, может выполнить краткую задачу и исчезнуть задолго до следующего аудита. Злоумышленник способен заставить скомпрометированный агент породить временные копии, передать им доступ родителя, похитить данные и завершить процессы. Нужны непрерывное и многослойное наблюдение, контроль людей, наблюдающие агенты и предварительные барьеры качества, но ответственность нельзя отдавать автоматике. За каждым агентом и результатом его действий должен стоять названный человек. Законодательное давление в США вокруг аварийного отключения автономного ИИ показывает, что kill switch воспринимают всерьез, хотя «аварийный выключатель имеет смысл лишь тогда, когда известно, что именно выключать».
Идентичность агента нельзя считать продолжением учетной записи сотрудника. В публикации The Monday Brief на Substack автор и Douglas McKee сформулировали правило так: «Доступ агента к инструментам следует моделировать как отдельную задачу идентификации и применения политик, а не как расширение прав пользователя, который развернул агента. Дайте каждому агенту собственную идентичность, привяжите разрешения к текущей задаче, ограничьте данные, способные покинуть среду, и поместите слой авторизации между моделью и подключенными сервисами». Отсюда еще одна формула SANS: «Нельзя установить порог для того, что невозможно атрибутировать». Журналы должны хранить не одни промпты, но и вызовы инструментов, выполненные действия и обращения к подключенным системам. Практическому разбору этих мер посвящен курс SEC530 «Защищаемая архитектура безопасности и инженерия: внедрение Zero Trust для гибридного предприятия», запланированный на декабрь 2026 года в рамках SANS Cyber Defense Initiative 2026.
