Как применять принцип «безопасности по проектированию» при развертывании ИИ-агентов?
- Команда Kaspersky
Команда Kaspersky
- 12 ноября 2026 г.
12 ноября 2026 г.
Системы ИИ гораздо сложнее защищать, чем традиционные ИТ-системы, будь то от ошибок операторов, злонамеренного вмешательства или просто от нестабильного поведения. Для этого есть две основные причины. Во-первых, ответы ИИ носят вероятностный характер: один и тот же запрос может приводить к разным результатам при каждом выполнении. Во-вторых, современные LLM-модели не умеют надежно отличать команды от данных. Несмотря на доказанные проблемы безопасности систем ИИ, о которых мы неоднократно говорили, игнорировать потенциальные экономические выгоды от их внедрения невозможно. Именно поэтому многие компании больше не ограничиваются простыми ИИ-помощниками и переходят к использованию ИИ-агентов. Эти агенты выполняют задачи автономно и имеют прямой доступ к тем же инструментам, что и люди — от работы с базами данных до изменения параметров производственных процессов. В своем новом исследовании наши эксперты рассматривают, как четко определить и минимизировать возникающие риски, чтобы ограничить потенциальные проблемы. Этот подход заимствует и адаптирует принципы кибериммунитета и «безопасности по проектированию».
Фундаментальные принципы «безопасности по проектированию»
Все принципы этой дисциплины универсально применимы к проектированию любой ИТ-системы, включая ИИ-агентов. Разница заключается лишь в степени адаптации и переработки, необходимой для применения каждого принципа к сценариям ИИ.
- Безопасность является неотъемлемым и важным фактором уже на этапе проектирования. Цели и допущения в области безопасности определяются с самого начала и соблюдаются на каждом этапе разработки. Для ИИ-агентов эти допущения должны включать три ключевых пункта: (i) языковая модель считается ненадежной, (ii) внешние данные, независимо от их характера, считаются потенциально вредоносными, и (iii) необратимые действия не могут выполняться автономно без обязательного одобрения человеком.
- Система проектируется исходя из предположения, что она будет атакована.
- Вычислительная база доверия и поверхность атаки сведены к минимуму. Агенты имеют доступ только к тем инструментам, которые им действительно нужны, ограниченные права доступа и минимум контекстной информации. Применение политики безопасности полностью управляется детерминированными модулями, а именно монитором политики, средой выполнения агента и механизмами изоляции (песочницами).
- Применяется принцип наименьших привилегий. Каждый агент имеет свои собственные учетные данные и права доступа (идентификацию), ограниченные строгим минимумом, необходимым для выполнения задачи. Если агенту временно требуются расширенные права доступа, он получает их только после внешнего одобрения и только на время, необходимое для выполнения конкретной задачи.
- Модули изолированы. В агентных системах это одна из самых сложных архитектурных проблем, возникающая на нескольких уровнях. Среда выполнения агента должна работать в изолированной среде (песочнице или виртуальной машине), а агенты должны быть максимально изолированы друг от друга. Обработка данных в доверенных контекстах также отделена от обработки в недоверенных контекстах. Например, один агент читает запрос на извлечение и пишет черновик кода, в то время как другой агент проверяет эту работу, не видя потенциально вредоносного текста запроса.
- Отказ по умолчанию — это правило. Политики безопасности следуют правилу: все, что не разрешено явно, запрещено. Это включает вызовы инструментов, взаимодействия между агентами и сетевой трафик.
- Реализована глубоко эшелонированная защита. Различные меры должны работать одновременно и усиливать друг друга. Вероятностные средства защиты, такие как «защитные барьеры» ИИ (своего рода «файрвол» для языковых моделей) или согласование (способность модели отличать приемлемое от неприемлемого), не могут дать формальных гарантий безопасности. Тем не менее, они повышают общую безопасность системы и являются ценным источником телеметрических данных.
- Цепочка поставок защищена. Некоторые агенты могут автономно устанавливать навыки, библиотеки и другие программные модули, поэтому эти возможности должны быть строго регламентированы. Полностью заблокируйте эти возможности или ограничьте их закрытым и предварительно утвержденным списком конкретных версий определенных модулей. Системы, основанные на LLM в облаке, подвержены дополнительному риску — обновлению моделей. В один прекрасный день один и тот же API-запрос может быть обработан другой языковой моделью с другими свойствами безопасности.
Ловушки безопасности в ИИ
Общие принципы «безопасности по проектированию» хорошо известны и кажутся простыми на бумаге. Однако их применение к системам ИИ затруднительно, поскольку агенты невероятно гибкие. Например, команда безопасности может подумать, что агент, установленный на компьютере разработчика, работает в песочнице и не может ничего изменить за ее пределами. Однако хакер или даже сам агент может найти десятки способов обойти эту, казалось бы, надежную защиту, например, выполняя команды через локальный MCP-сервер, не подпадающий под ограничения песочницы, или путем перенастройки другого ИИ-агента, установленного в системе. Чтобы еще больше усложнить ситуацию, спектр векторов атак огромен — от произвольных полей в конфигурации агента до инъекций промптов.
Усталость пользователя также является серьезной проблемой, которую проектировщики часто недооценивают. Очень активный агент может генерировать десятки запросов в минуту, предлагая пользователю подтвердить потенциально опасные действия. Менее чем через час человек начинает нажимать «Одобрить» машинально, даже не читая, что именно он одобряет. Именно поэтому важно тщательно регулировать частоту появления этих запросов, а также способ их формулировки. Никто не будет читать слишком длинное описание запроса. И наоборот, слишком короткое описание может упустить важные детали, необходимые пользователю для принятия правильного решения.
Уязвимости агентов и связанных с ними инструментов представляют собой насущную проблему, усугубляемую скоростью, с которой развиваются и обновляются эти категории программного обеспечения. В эталонных отраслевых платформах и приложениях (таких как LangGraph, MS Semantic Kernel и Claude Code) критические уязвимости устранялись неоднократно. Архитекторам всегда следует рассматривать возможность замены громоздкого универсального фреймворка компактной и оптимизированной системой, обладающей только теми функциями, которые действительно нужны конкретному агенту.
Кроме того, строгое внедрение стандартных и проверенных мер безопасности в доступных инструментах позволяет значительно сократить ущерб в случае атаки на агента или его неожиданного поведения. Примером может служить строгий список разрешенных доменов, к которым инструмент веб-поиска может обращаться по запросу агента. Однако проектировщики редко учитывают скрытые проблемы и дополнительную нагрузку, связанные с управлением этим списком. В результате он постепенно устаревает и создает бреши, которыми могут воспользоваться хакеры. Самым ярким примером является атака EchoLeak. В Microsoft 365 Copilot был реализован относительно эффективный список разрешенных доменов для доступа к внешним сайтам, но хакеры смогли обойти его, используя функциональность вспомогательного инструмента, а также домен MS Teams.
Практические советы для архитекторов и команд безопасности
Архитекторы систем ИИ и руководители инженерных групп и отделов безопасности должны внедрять безопасность агентов еще на этапе проектирования. Им следует опираться преимущественно на проверяемые и детерминированные механизмы, изолируя модули, контролируя взаимодействия и минимизируя доверенную вычислительную базу.
Ключевые архитектурные решения включают определение степени допустимой автономности агентов, ограничение доступа к конфиденциальным данным и опасным комбинациям возможностей, а также использование «песочниц», разделение ролей для различных моделей и шлюзов контроля доступа. Ограничения, добавленные постфактум, снижают риски, но не заменяют собой безопасную архитектуру.
На организационном и операционном уровнях компании должны вести учет своих агентов, координировать усилия команд по безопасности и развертыванию, защищать контейнерные среды, управлять цепочкой поставок (AIBOM) и внедрять многоуровневую защиту.
Особого внимания заслуживает наблюдаемость. Для систем ИИ она должна включать логирование запросов, ответов и процесса рассуждения LLM, а также подробные телеметрические данные с хостов и облачных сред, в которых выполняется агент.
Самое сложное в проектировании агентов — найти правильный баланс между безопасностью, производительностью и полезностью. Чтобы узнать, как найти этот баланс с помощью моделирования угроз и четко определенных целей безопасности, ознакомьтесь с
Советы
Девять причин настроить VPN на вашем роутере
Получите максимум от вашего VPN в плане скорости, надежности и удобства использования, настроив его на своем роутере. Вот обзор конкретных преимуществ, которые могут предложить различные сценарии настройки VPN для всей вашей домашней сети.
