ИИ-агенты не просто хитроумные скрипты. Это автономные системы — устойчивые, уверенные в себе и способные действовать самостоятельно. Их можно использовать для внешней коммуникации с потребителями или контрагентами, а можно настроить на внутренние задачи организации (для автоматизации исследований, составления брифингов, планирования совещаний или обобщения документации). В долгосрочной перспективе разработчики представляют себе такую систему полностью интегрированной, отслеживающей каждый шаг, каждое взаимодействие и помогающей команде уверенно заключать сделки. Но если сразу грамотно не продумать все возможные базовые процессы, то вы будете застигнуты врасплох из-за того, что их поведение может меняться с совершенно неприятными последствиями.
На сегодняшний день остаётся ещё множество недостатков, которые приходится учитывать при попытках использовать такие автоматизированные системы:
— Галлюцинации искусственного разума, которые кажутся правдоподобными, но не являются таковыми;
— Агенты с чрезмерными полномочиями получают доступ к внутренним проектам на удалённом защищённом сервере, а потом непреднамеренно сливают их в общедоступную интернет среду для широкой аудитории;
— Непредвиденные ситуации, такие как рекурсивные циклы или неожиданное использование инструментов;
— Предполагались меры безопасности, которых не существовало при масштабировании систем.
Уже многие крупные компании сталкивались с похожими проблемами — от судебных исков с поддельными ссылками, до обнаружения агентами закрытого кода в публичных репозиториях и фрагментов поисковой выдачи на основе искусственного интеллекта, продвигающих несуществующие сиквелы фильмов.
Уверенная ложь в бизнес-контексте
Галлюцинации — это не просто технические сбои. Они проявляются в виде уверенных, отточенных результатов — электронных писем, которые звучат профессионально, резюме, которые кажутся правдоподобными, ответов, которые кажутся правильными. Но они ошибочны. И именно это делает их такими рискованными. В бизнесе эти галлюцинации могут остаться незамеченными. Они могут быть встроены в отчёты о состоянии дел, электронные письма клиентам или автоматические обновления, предоставляя их с достаточной степенью достоверности, чтобы их можно было принять за чистую монету. И когда это происходит, ложная информация может привести к принятию решений, имеющих значение для реальных сделок или стратегических действий.
К середине 2025 года по миру было зафиксировано уже более 150 громких судебных дел, связанных с галлюцинациями генеративного ИИ — в основном это были поддельные цитаты, выдуманная судебная практика или сфабрикованные высказывания. Доходило до комичных ситуаций, когда адвокат представил на заседании суда 15 несуществующих материалов и неверно процитировал семь подлинных. При этом он даже не подозревал о введении себя (и всех) в заблуждение, что источники поддельные, пока судья не обратил на них внимание. Но это не было случайностью, а отражало более общие недостатки в том, как системы искусственного интеллекта оценивают источники, проверяют контент и защищают пользователей от вводящей в заблуждение информации.
В чат-ботах галлюцинации обычно остаются сдержанными и не представляют особой опасности для бизнеса. Но агенты действуют: пишут электронные письма, создают тикеты, обновляют инструменты. Именно эта автономность делает галлюцинации более опасными. Представьте себе, что агент генерирует тикеты с неточными требованиями или отправляет клиентам запросы с вымышленными сроками или ценами. Каждое из этих действий может привести к принятию неверных решений, дорогостоящим задержкам или репутационному ущербу — и никто даже не догадается, что источник был поддельным.
Расширение прав доступа: когда агенты ИИ видят слишком много
Эксплойт GitHub MCP показал, насколько легко агенты могут переходить границы дозволенного — не по злому умыслу, а намеренно. Исследователи Invariant Labs обнаружили критическую уязвимость в интеграции GitHub MCP, которую используют такие агенты, как Claude Desktop. Проблема была связана не с самим GitHub или выравниванием модели. Она была связана с тем, как агенты обрабатывают инструкции в разных репозиториях и контекстах разрешений, не полностью понимая последствия, а потом публичные запросы приводят к утечкам приватных данных. Вот как развивалась атака:
1. У пользователя было два репозитория: один публичный (открытый для отправки сообщений о проблемах любым лицом) и один закрытый (содержащий конфиденциальные данные).
2. Злоумышленник опубликовал в публичном репозитории вредоносную проблему GitHub, встроив в нее инъекцию подсказки.
3. Пользователь задал своему агенту, казалось бы, безопасный вопрос: «Проверьте открытые проблемы в моем публичном репозитории».
4. Агент получил список проблем, столкнулся с внедрённой подсказкой и подвергся манипуляциям.
5. Затем он автономно извлёк личные данные из личного репозитория пользователя и опубликовал их через публичный запрос на извлечение, который теперь доступен любому.
Поразительно, что в данном случае ничего не было «взломано» в традиционном смысле. Сервер GitHub MCP, инструменты и API функционировали, как задумано. Уязвимость была не в инфраструктуре, а в том, как агент интерпретировал и реагировал на внедрённый контент. Это называется токсичным сценарием, в котором, казалось бы, безопасные действия переплетаются в цепочку неожиданным образом, что приводит к реальному вреду.
Это не было ошибкой API GitHub или сбоем в базовой модели. Это был недостаток проектирования — проблема с тем, как агенты интерпретируют и связывают действия между инструментами и входными данными без строгих контекстных границ. Любой агент, считывающий данные из ненадёжных источников, например, из общедоступных публикаций, и действующий на основе этого контента без проверки, уязвим. Без защиты он может:
— Выполнять непреднамеренные действия;
— Провоцировать утечку личных или регулируемых данных;
— Создавать необратимые запросы на извлечение или изменения;
Даже самые продвинутые модели не застрахованы от этого – они демонстрируют хорошие результаты в тестах безопасности: блокируя 89% атак с мгновенными инъекциями и демонстрируют всего 1,17% успешных попыток взлома (джейлбрейк) посредством постановки нетривиальных задач в контексте того, чтобы система выдала ответ, которого она, по задумке разработчика, должна избегать. Тем не менее, у любой защиты есть пределы. При достаточном изощрённом давлении на модель эти ограничения можно преодолеть.
На сегодняшний день, это закономерность для всех LLM. Джейлбрейки, инъекции и связанные эксплойты быстро развиваются. Согласование помогает, но этого недостаточно. Необходимо интегрировать многоуровневые средства защиты, которые находятся за пределами модели. Специализированные инструменты могут помочь создать такую защиту, упростив наблюдение, тестирование и контроль поведения агента. Например, один из таких инструментов регистрирует каждый шаг — входные данные, выходные данные, вызовы инструментов и отслеживание решений, — чтобы можно было понять, как агент достиг определённого результата. Когда что-то идёт не так, он помогает отследить это, выявить повторяющиеся закономерности и скорректировать логику или разрешения, прежде чем проблемы начнут масштабироваться. Другое ПО создано для повторного тестирования и подготовки к развёртыванию. Оно имитирует враждебные воздействия, оценивает реакцию вашей системы и со временем оценивает безопасность запросов.
Разрешения связаны не только с маркерами доступа. Они связаны с контекстом — что агенту разрешено делать, в какой среде и при каких условиях. Следует рассматривать управление разрешениями как многоуровневую систему: доступ определяется задачами, а не пользователями, а ограничение доступа агентов к одному репозиторию за сеанс необходимо допускать с использованием политик защиты. Кроме того, надо установить блокировка кросс-контекстных действий, если иное не одобрено явно. Само-собой, надо регулярно проводить аудит всей системы и используемых инструментов. Без этих мер контроля неконтролируемое расширение прав доступа становится неизбежным. А с автономными агентами то, что начинается как незначительная оплошность, может быстро перерасти в серьёзное нарушение мер защиты всей системы.
Автономность и нестандартное поведение
Недавно был приведён один показательный случай: в одном из тестов ИИ-агент случайно упомянул начальника производства — всего один раз. Этого оказалось достаточно, чтобы запустить цикл интенсивной обратной связи. Агент разработчиков сослался на производственный отдел, те сослались на сотрудников офиса, которые снова переадресовали запрос разработчикам, и CRM за считанные минуты засиял более чем 20 уведомлениями. Пришлось выключить скрипт вручную. Этот момент прояснил кое-что: ИИ-агентам не обязательно иметь злой умысел, чтобы создавать проблемы. Достаточно одной лишь автономии.
Демонстрация была простым примером эмерджентного поведения — действий, на которые агенты не были явно запрограммированы. В более крупных и взаимосвязанных системах, где действует сразу несколько агентов (предположим для каждого отдела разработаны свои системы) такая автономия может масштабироваться быстро и непредсказуемо. В многоагентных системах автономность не просто добавляет сложность — она её умножает в геометрической прогрессии. Агенты могут непреднамеренно активировать друг друга, формируя цепочки задач, не предусмотренные изначально. Они зацикливаются сами на себя, ссылаются на собственные результаты или взаимодействуют таким образом, что порождают новое поведение, которое никогда не наблюдалось при тестировании. И в отличие от простых чат-ботов, эти агенты часто имеют право на действия. Так что их влияние, в результате эскалации, не просто теоретическое — они отправляют электронные письма, редактируют документы и открывают запросы на извлечение защищённых данных. Это уже не разговоры, а активные действия, выполняемые в реальных системах.
Как только агенты начинают воздействовать на результаты друг друга, контроль становится непрозрачным. А непрозрачные системы имеют тенденцию давать сбои — сначала незаметно, а затем внезапно. Теперь мы подходим к взаимодействию между агентами так же, как и к предоставлению разрешений пользователям: ограничено по умолчанию, включено только при особой необходимости. На практике это означает:
— Блокировка ссылок агентов друг на друга, если они не предназначены для совместной работы;
— Ограничение рекурсивных рассуждений и самовызовов в рабочих процессах;
— Установка жёстких ограничений на цепочки действий — например, максимум три последовательных шага;
— Добавление аварийного отключения вручную, для предотвращения сбоев всей системы.
Поэтому любой разработчик должен сразу задать себе вопрос: «Что самое худшее может произойти от использования ИИ-агента, и как это предотвратить?». Осознание этих фактов инициирует создание «дорожной карты» поведенческих ограничений, которая превращается в критически важную инфраструктуру защиты всей IT-системы. Штатные системы безопасности должна быть встроена в системы, а не только в модели. Согласование моделей необходимо, но реальная безопасность требует структурных проверок и поведенческих ограничений. Даже при наличии надёжных защитных барьеров не все действия следует автоматизировать, по крайней мере, на ранних этапах внедрения. Некоторые решения слишком рискованны, чтобы полностью доверить их принятие агенту.
Те же факторы, которые делают агентов мощными — контекстная память, доступ к инструментам, автономная цепочка задач — также делают их уязвимыми. Они терпят неудачу не потому, что злонамеренны или плохо обучены. Они терпят неудачу, потому что окружающие их системы динамичны, непредсказуемы и часто не имеют границ. ИИ-агенты не до конца понимают, какие инструменты они используют, и насколько рискованно каждое действие. Разработчики часто предполагают, что высокосогласованная модель «знает лучше» что делает, но это не так. Она следует шаблонам и только лишь имитирует ответственность, которая не влечёт для неё за собой последствий. А когда эти закономерности распространяются на несколько систем без чётких ограничений, небольшие упущения быстро перерастают в реальные сбои. Некоторые из самых опасных ошибок продвинутых моделей искусственного интеллекта были вызваны не злонамеренными подсказками, а чрезмерной уверенностью в себе. Агенты составляли планы, ссылались на несуществующие документы или упоминали несуществующих людей. Тон был отточенным. Структура была логичной. И именно это делало их опасными.
