Сегодня агентский ИИ уже работает в производственных средах многих организаций. Он выполняет задачи, обрабатывает данные и предпринимает действия — скорее всего, без значимого участия службы безопасности. В отраслевых дискуссиях этот вопрос в основном рассматривается как вопрос политики: разрешать, ограничивать или контролировать? Однако такая постановка вопроса упускает суть.
Более актуальным вопросом является то, действительно ли специалисты по безопасности понимают, с чем они имеют дело. В большинстве организаций на данный момент они этого не понимают. И этот разрыв увеличивается с каждой неделей.
Невозможно защитить то, чего не понимаешь
Основной принцип информационной безопасности не изменился: прежде чем можно будет эффективно защитить технологию, необходимо в ней действительно хорошо разбираться.
Вспомните брандмауэры. Невозможно правильно настроить брандмауэр, не понимая сетей. Когда появились облачные вычисления, организации, пропустившие этап базовой подготовки, оказались в среде, которую они не могли осмыслить — были приобретены инструменты, написаны политики, но реального контроля так и не было. Сегодня облачная безопасность является самостоятельной дисциплиной именно потому, что технология требовала от специалистов глубокого знакомства с ней, прежде чем можно было говорить о безопасности.
Та же динамика наблюдается и в сфере ИИ, только в более быстром темпе и с более высокими ставками.
Практические последствия отставания в области агентного ИИ выходят за рамки технической уязвимости. Команды безопасности, которые не владеют языком ИИ-инженерии — которые не могут оспаривать проектные решения, предлагать работоспособные меры контроля или задавать обоснованные вопросы — остаются в стороне. Бизнес-подразделения двигаются вперед без них не из-за недобросовестности, а потому, что команда безопасности, которая не может вступить в конструктивный диалог с технологией, не является полезным партнером при принятии решений, касающихся этой технологии. Так происходило при каждом крупном технологическом сдвиге за последние два-три десятилетия. С ИИ будет то же самое.
Отправной точкой является вовлеченность. Попробуйте создать агента. Поэкспериментируйте с инструментами, которые уже используют ваши разработчики. Именно с этого практического знакомства начинается настоящее понимание, а настоящее понимание — это то, что делает возможным все остальное.
Три категории агентов, три категории рисков
Сфера агентного ИИ обширна, и профиль рисков в ней значительно варьируется. Стоит четко различать три категории.
Первая — это универсальные агенты для кодирования и повышения производительности — такие инструменты, как Claude Code и GitHub Copilot. Они уже встроены в рабочие процессы разработчиков и инженеров по всей вашей организации. Независимо от того, были ли они официально одобрены или нет, они используются. Какие данные они могут получить, как они взаимодействуют с кодовыми базами и какие действия они могут предпринимать — это базовые знания по безопасности на данный момент.
Вторая — это агенты, созданные поставщиками на базе Model Context Protocol (MCP). MCP — это интеграционный уровень, позволяющий агентам подключаться к внешним сервисам и действовать от их имени. Практически каждый крупный поставщик либо уже использует сервер MCP в производственной среде, либо активно разрабатывает его. На практике это означает, что агент, управляющий календарем, электронной почтой или внутренней системой тикетов пользователя, может получать входные данные из этих каналов и действовать на их основе. Вредоносное приглашение в календарь, содержащее скрытые инструкции в описании события, является реальным вектором атаки — агент считывает его, интерпретирует встроенный запрос и выполняет его. Это реальная поверхность атаки, требующая тщательной настройки и проверки безопасности.
Третья категория — это пользовательские агенты, созданные отдельными пользователями, и именно здесь ситуация становится особенно интересной. На протяжении многих лет существовал реальный барьер между специалистами по безопасности, понимающими риски, и кодом, который работал в их средах. Большинство специалистов по безопасности не являются программистами. Создание пользовательских инструментов требовало навыков разработки, которые не были широко распространены в командах безопасности.
Благодаря агентному ИИ любой сотрудник организации может создавать функциональные инструменты — автоматизацию, рабочие процессы, агенты с реальным доступом к системе — без написания традиционного кода. Для команд безопасности это действительно ценно. Расследование инцидентов, криминалистическая сортировка, рабочие процессы по поиску угроз — все это можно ускорить, если специалисты смогут создавать инструменты, которые им действительно нужны. Но эта же возможность распространяется и на все остальные команды. Маркетинг, финансы, операционная деятельность — теперь каждый может создавать агентов. Многие будут это делать. Большинство этих агентов не пройдет проверку безопасности перед запуском. Это проблема цепочки поставок в другой форме.
Когда команды безопасности отстают от крупных технологических изменений, картина складывается всегда одинаково.
Во-первых, остальные подразделения организации двигаются вперед без учета мнений специалистов по безопасности. Разработчики развертывают решения, бизнес-подразделения внедряют их, а с отделом безопасности консультируются лишь для проформы — или вообще не консультируются. Во-вторых, уязвимость усугубляется. Чем мощнее агенты, развертываемые организацией, тем больше доступа они требуют. Широкие разрешения — это то, что делает агентов полезными: доступ к календарям, платформам связи, файловым системам, репозиториям кода, внутренним API. Именно этот доступ также значительно увеличивает зону поражения, когда что-то идет не так.
Агентом, имеющим доступ как к терминалу, так и к почтовому ящику, можно манипулировать через любой из этих каналов, чтобы он действовал в другом. Это путь латерального перемещения, который будет искать злоумышленник. Чтобы это понять, необходимо понимать, как был построен агент — такое понимание приходит только от подлинного взаимодействия с технологией.
Формирование компетенций в области безопасности агентного ИИ требует двух отдельных уровней знаний.
Первый — это понимание архитектуры приложений ИИ с точки зрения практикующего специалиста, а не специалиста по данным. Из чего состоит приложение ИИ? Как агенты обрабатывают входные данные, связывают инструменты между собой и генерируют выходные данные? Как на самом деле выглядит сеанс работы с агентом, подключенным к MCP, с точки зрения контроля доступа? Это основа, которая делает все остальное применимым на практике.
Второй уровень — актуальность. Инструментарий и ландшафт угроз, связанных с ИИ, быстро меняются. Поставщики разрабатывают средства контроля безопасности для систем ИИ, хотя большинство из них все еще находятся в стадии развития. Появляются фреймворки с открытым исходным кодом. OWASP и другие организации публикуют классификации угроз, которые меняются из недели в неделю. Как только базовый уровень заложен, оставаться в курсе событий становится постоянной задачей — знать, какие инструменты стоит оценивать, какие фреймворки набирают популярность и какие вопросы задавать, когда поставщики предлагают свои решения.
Этот второй момент имеет большее значение, чем может показаться. К командам по безопасности уже обращаются поставщики, продающие продукты для обеспечения безопасности ИИ. Без базовых знаний о том, как построены эти приложения, практически невозможно вести такие переговоры. Невозможно отличить хорошо продуманный механизм контроля от маркетинговой уловки, если не понимаешь, что именно пытаешься контролировать.
Конфигурация как средство контроля безопасности
Многие внедрения агентного ИИ сопряжены с риском, потому что они были запущены без конфигурации, учитывающей вопросы безопасности, а не потому, что базовые инструменты принципиально неработоспособны.
Возьмем, к примеру, самохостируемого ИИ-помощника, подключенного к каналу связи, такому как Telegram, что может быть распространенным явлением. Без надлежащих средств контроля агент может отвечать любому, кто ему пишет. Это широко открытая точка входа. Простое изменение конфигурации — привязка агента к одной доверенной учетной записи — устраняет большую часть этой уязвимости. Одно решение, принятое на раннем этапе, с значимым результатом для безопасности.
Более общий принцип — это ограничение сферы действия. Агент, созданный для управления вашим календарем, не должен иметь доступа к вашему терминалу. Агент, обрабатывающий входящие запросы, не должен иметь права записи в ваш репозиторий кода. Ограничение сферы действия агентов их предназначенными функциями ограничивает радиус воздействия и уменьшает площадь атаки, доступную для эксплуатации.
Противоречие реально: мощные агенты нуждаются в широком доступе, чтобы быть полезными. Это компромисс, против которого будут сопротивляться организации. Поиск правильного баланса требует вовлечения специалистов по безопасности на ранних этапах процесса проектирования — до того, как будет определена архитектура и установлены разрешения.
Опережая события на SANSFIRE 2026
Организации, которые сейчас приобретают настоящую компетентность в области безопасности ИИ, будут в состоянии определять, как эти системы будут развернуты. Те, кто опоздает, в очередной раз окажутся в ситуации, когда им придется применять меры контроля к архитектуре, которая уже была определена без их участия.
В июле этого года я буду вести курс SEC545: «Безопасность приложений GenAI и LLM» на конференции SANSFIRE 2026. Курс посвящен тому, как на самом деле создаются приложения ИИ, как агентные системы работают на практике, каким реальным уязвимостям должны уделять внимание команды безопасности, а также какими инструментами и средствами контроля можно их устранять — включая практическую работу с такими методами, как сканирование моделей для обнаружения скомпрометированных моделей до того, как они запустятся в вашей среде. Для практиков, которые хотят работать с системами ИИ, опираясь на глубокое понимание, это именно то место, с которого стоит начать.
Примечание: эта статья была написана и предоставлена Ахмедом Абугарбиа, сертифицированным инструктором SANS.