AI
ИИ-системы гораздо сложнее защитить от ошибок оператора, злонамеренных воздействий и просто нестабильной работы, чем традиционные ИТ. Две основных причины — вероятностная природа генерации нейросетей (при каждом запуске один и тот же запрос может давать разные ответы) и неспособность современных LLM надежно отличать команды от данных. Несмотря на доказанные проблемы безопасности ИИ-систем, о которых мы неоднократно писали, потенциальный экономический эффект от их внедрения игнорировать невозможно. Поэтому многие компании внедряют уже не просто ИИ-ассистентов, а ИИ-агентов, самостоятельно выполняющих те или иные задачи, имея прямой доступ к тем же инструментам, что и люди — от чтения баз данных до изменения параметров производственных процессов. Чтобы свести возможные проблемы к минимуму, наши эксперты в свежем исследовании подробно разобрали, как четко очертить и минимизировать возникающие риски, заимствуя и адаптируя принципы кибериммунитета и конструктивной безопасности (Secure by Design).
Базовые принципы конструктивной безопасности
Все принципы этой дисциплины универсальны и применимы к проектированию любой компьютерной системы, включая ИИ-агентов. Отличается глубина адаптации и переработки каждого принципа под сценарии с ИИ.
- Безопасность является самостоятельным и весомым фактором на этапе проектирования. Цели и предположения безопасности фиксируются с самого начала создания системы и соблюдаются на всех этапах разработки. Для ИИ-агентов в число таких предположений должны войти три: языковая модель считается недоверенным элементом; внешние данные любого вида расцениваются как потенциально вредоносные; необратимые действия не могут быть выполнены автономно, без обязательного подтверждения человеком.
- Система проектируется с учетом того, что ее обязательно атакуют.
- Доверенная вычислительная база и «поверхность атаки» минимизируются. Агентам выдаются необходимый базовый набор инструментов, ограниченные права и минимальный нужный объем контекста. Соблюдение политик безопасности (enforcement) целиком возлагается на детерминированные компоненты: монитор политик, обвязку агента (harness), механизмы изоляции (sandbox).
- Соблюдается принцип наименьших привилегий. Каждый агент работает с собственным набором учетных данных и доступов (identity), который минимально необходим для выполнения его работы. Если возникает нужда временного повышения привилегий, то они выдаются только после внешнего одобрения и работают ровно столько времени, сколько занимает выполнение задачи, требующей таких привилегий.
- Компоненты изолируются. В агентских системах это один из наиболее сложных и многоуровневых архитектурных вопросов. Агентская обвязка должна работать в изолированной среде («песочнице» или виртуальной машине), агенты должны быть максимально изолированы друг от друга; также разделяется обработка данных в доверенном и недоверенном контексте. Например, один агент пишет черновик кода после прочтения pull request, а результаты его работы оценивает другой агент, не имеющий доступа к потенциально вредоносному тексту запроса.
- Работает режим «запрет по умолчанию». Политики безопасности настраиваются по правилу «запрещено все, что не разрешено явным образом». Это касается в том числе вызовов инструментов, межагентских взаимодействий и сетевого трафика.
- Применяется многоуровневая защита (defense in depth). Различные меры должны применяться одновременно и усиливать друг друга. Защита, имеющая вероятностный характер (такая как «файрвол» для языковой модели — AI guardrails; собственные знания модели о допустимом и недопустимом — alignment), не может предоставить каких-либо формальных гарантий безопасности, но вносит вклад в повышение общей защищенности и служит важным источником телеметрии.
- Организована защита цепочки поставок. Поскольку некоторые виды агентов способны самостоятельно устанавливать навыки (skills), библиотеки и другие программные компоненты, эти возможности должны быть строго регламентированы: либо вообще заблокированы, либо иметь доступ исключительно к закрытому, заранее одобренному списку конкретных версий определенных компонентов. В системах, основанных на облачных LLM, стоит учитывать отдельный риск обновления модели, когда есть вероятность, что по тому же API-запросу начинает отвечать иная языковая модель с другими свойствами безопасности.
Подводные камни безопасности ИИ
Хотя общие принципы конструктивной безопасности хорошо знакомы и просты на бумаге, их применение конкретно к ИИ-системам затруднено из-за невероятной гибкости агентов. Например, ИБ-команда может считать, что агент на компьютере разработчика работает в «песочнице» и не может изменить что-либо за ее пределами, но атакующий или даже сам агент способны изобрести десятки способов обхода внешне надежной защиты: от запуска команд через не ограниченный «песочницей» локальный MCP-сервер до изменения конфигурации другого ИИ-агента, установленного в системе. Усложняет ситуацию и широкое разнообразие векторов атаки: от произвольных полей в конфигурации агента до внешне невинных текстовых строк в файле навыка.
Серьезной проблемой, которую часто недооценивают проектировщики, является усталость пользователя. Активно работающий агент может ежеминутно выводить десятки просьб подтвердить потенциально опасные действия, в результате уже через час человек механически нажимает approve, не вчитываясь в текст запроса. Большое внимание нужно уделять как калибровке частоты этих запросов, так и тому, как они сформулированы. Слишком длинное описание запроса никто не будет дочитывать. Слишком короткое может скрывать самые важные нюансы запроса, позволяющие принять верное решение.
Уязвимости в агентах и сопутствующих инструментах являются острой проблемой, которая осложняется очень быстрым развитием и обновлением этих классов ПО. Неоднократно устранялись критические уязвимости в стандартных для всей индустрии платформах и приложениях: LangGraph, MS Semantic Kernel, Claude Code и других. Архитекторам нужно всегда рассматривать возможность замены крупного многофункционального фреймворка на компактную урезанную систему, имеющую только возможности, востребованные в конкретном агенте.
Кроме того, скрупулезная реализация стандартных, давно известных мер защиты в доступных инструментах значительно сокращает ущерб при атаке или незапланированном поведении агента. Примером может быть строгий список разрешенных доменов (allowlist), которые инструмент «Прочитай веб-сайт» (WebFetch) разрешает открыть по запросу агента. Но при проектировании редко удается учесть скрытые проблемы и накладные расходы по сопровождению этого списка, в результате он постепенно устаревает и открывает лазейки атакующим. Наиболее яркий пример — атака EchoLeak, в которой успешно внедренный и довольно эффективный allowlist на доступ к внешним сайтам в агенте Copilot 365 атакующие обошли через функциональность одного из вторичных инструментов и домен MS Teams.
Практические рекомендации архитекторам и ИБ-командам
Архитекторам ИИ-систем и руководителям инженерных и ИБ-команд следует закладывать безопасность агентов на этапе проектирования, опираясь в первую очередь на проверяемые, детерминированные механизмы: изоляцию компонентов, контроль взаимодействий и минимизацию доверенной вычислительной базы.
Ключевые архитектурные решения предусматривают определение допустимой автономности агентов, ограничение доступа к конфиденциальным данным и опасных сочетаний возможностей, а также применение «песочниц», разделения ролей между моделями и шлюзов контроля доступа. Ограничения, добавленные в систему постфактум, снижают риски, но не заменяют безопасную архитектуру.
На организационном и эксплуатационном уровнях необходимы инвентаризация агентов, совместная работа ИБ и команд внедрения, защита контейнерных сред, управление цепочкой поставок (AIBOM) и интегрированная многослойная защита.
Особое внимание требуется уделять вопросам наблюдаемости (observability). Для ИИ-систем она должна включать журналирование обращений, ответов и размышлений LLM, а также подробную телеметрию с хостов и облачных сред, где запущена агентская обвязка.
Наиболее сложная задача — найти при проектировании баланс между безопасностью, производительностью и полезностью агентов. О том, как его определять на основе моделирования угроз и явно сформулированных целей безопасности, можно прочитать в полной версии исследования.
