Вставка промптов и смертельная тройка: защита ИИ-агентов
Внедрение промптов и смертельный трио: почему ИИ-агенты не могут отличить ваши указания от указаний злоумышленника, как работали атаки EchoLeak и GitHub MCP.
Источники: Prompt Injection and Agent Security: The Unsolved Problem
В июне 2025 года исследователи обнаружили уязвимость в Microsoft 365 Copilot и назвали её EchoLeak. Атака происходила следующим образом: кто-то присылает вам письмо, выглядящее совершенно обычно. Вы не открываете его, ни на что не кликаете и даже не читаете. Однако Copilot всё равно его читает, поскольку он просматривает весь ваш почтовый ящик, чтобы ответить на ваши вопросы. В этом письме скрыты инструкции, приказывающие Copilot собирать конфиденциальные данные из ваших других документов и тихо отправлять их на внешний сервер через автоматически загружаемое изображение. Не требуется ни одного клика, и жертва не совершает ничего плохого. Агент выполняет приказ, просто не тот, кому следовало.
EchoLeak получил идентификатор CVE (CVE-2025-32711), был исправлен, но перестал функционировать — это стал первый известный случай использования инъекции промптов для кражи реальных данных в производственной ИИ-системе. Это не будет последним случаем. В течение следующего года аналогичные атаки были обнаружены в интеграции MCP от GitHub, сервисе Duo от GitLab, ИИ-функциях Slack, решении NotebookLM от Google, а также во всех выпущенных ИИ-браузерах. К концу 2025 года собственные специалисты по безопасности OpenAI публично заявили, что проблему инъекции промптов в браузерных агентах, возможно, никогда нельзя будет полностью решить, и Национальный центр кибербезопасности Великобритании согласился с этим мнением.
Основной принцип безопасности ИИ-агентов прост, но у нас до сих пор нет четкого ответа на него: модель получает ваши указания и указания злоумышленника через абсолютно один и тот же канал и не может надежно их различить. Ниже объясняется, почему это так, почему это наносит гораздо больший ущерб агентам, чем чат-ботам, и какие меры защиты действительно эффективны, в отличие от тех, что приводятся в презентациях поставщиков.
Один канал для всего
Сначала необходимо понять механизм, потому что именно неправильное его понимание лежит в основе слабых рекомендаций по безопасности.
Модель языка получает один входной элемент — длинную последовательность токенов. Просьба к системе является частью этой последовательности. Вопрос пользователя также представляет собой токены. Так же являются токенами веб-страница, загруженная агентом, прочитанное им письмо, результат работы инструмента, полученный им ответ, разобранный PDF и альт-текст изображения. Все это поступает в виде одной плоской последовательности, и модель предсказывает следующий элемент. Ничто не помечает некоторые токены как надежные команды от оператора, а другие — как ненадежные данные для обработки. Саймон Уиллисон, введший в 2022 году термин «вставка просьбы», описывает это следующим образом: модели с радостью выполняют любые указания, которые к ним поступают, независимо от того, исходят ли они от оператора или от кого-либо еще.
В этом-то и суть, и проблема кроется глубоко. Никакое обновление модели не сможет её исправить, поскольку слабость заложена в самой конструкции. Эти системы созданы для выполнения указаний, сформулированных простым языком. Затем мы передаём им тексты на простом языке, взятые с открытого интернета, и удивляемся, когда встроенные приказы выполняются. Инъекция — это просто выполнение указаний, но в пользу неправильного «начальника».
Сравните это с инъекцией SQL, от которой и произошло название этой атаки. Для решения проблемы инъекции SQL существует эффективное решение — параметризованные запросы, при которых базе данных однозначно указывается, что та или иная часть является командой, а та — данными, которые никогда не должны рассматриваться как команда. Три десятилетия безопасности веба основаны на проведении этой границы внутри самой машины. Внутри ЯИИ никто не знает, как это сделать: всё происходит в рамках одного канала связи, причем канал команд и канал данных сливаются в один. Именно поэтому обычный подход, заключающийся в указании модели в системном промпте игнорировать инструкции, содержащиеся в веб-контенте, не работает. Вы используете скомпрометированный канал для защиты того же скомпрометированного канала, и хорошо составленный контент всегда может обойти предупреждения, написанные на английском языке.
Два типа атак часто путают. При прямой инъекции пользователь сам вводит что-то вредоносное, например запрос на отображение системного сообщения. Это ближе к джейлбрейку: человек атакует агента, использование которого ему разрешено. Косвенная инъекция представляет угрозу для самих агентов. Вредоносная инструкция скрыта во внешнем материале, который агент обрабатывает в процессе работы — например, на веб-странице, в электронном письме, приглашении в календарь, в комментарии к коду или в задаче на GitHub. Атакующий никогда не обращается к агенту напрямую. Он оставляет ловушку в контенте, который, по его ожиданиям, агент когда-нибудь прочитает от имени жертвы, доверяющей ему. Все вышеупомянутые инциденты относятся именно к этому типу. Такой подход эффективен, поскольку атакующему не нужен доступ к вам, достаточно лишь определённого влияния на то, на что будет направлен ваш агент.
Смертельный триумвират
Самая полезная модель мышления в этом контексте — это «смертельный трио» Саймона Уиллисона, которая объясняет, почему некоторые агенты крайне уязвимы для эксплуатации, а другие просто вызывают раздражение при атаке.
Агент превращается в инструмент кражи данных, когда у него есть три определенных возможности.
- Доступ к частным данным. Он может читать вашу электронную почту, частные хранилища, записи клиентов или внутренние вики. Обычно именно по этой причине существует такой агент, поэтому его нельзя просто удалять.
- Возможность обращения с ненадежным контентом. Он обрабатывает текст, который он не создавал и который вы не проверяли: веб-страницы, входящую почту, документы, данные от систем сторонних поставщиков. Это тоже обычно является основной целью существования такого агента.
- Способ внешней связи. Он может отправить данные туда, где их сможет увидеть злоумышленник, сделав HTTP-запрос, отправив электронное письмо, вызвав API, отобразив изображение с URL злоумышленника или создав pull request.
Любой из этих вариантов подходит, а два из них обычно позволяют сохранить работоспособность. Однако наличие всех трех функций в одном агенте под одним набором учетных данных подобно оружию, нацеленному на ваши данные. Злоумышленник, контролирующий вторую функцию, может перехватить команды агента, использовать первую для сбора секретной информации и третью — для её отправки. Именно такая последовательность действий была использована в атаках EchoLeak и GitHub MCP.
Случай с GitHub достаточно понятен для детального рассмотрения. Компания Invariant Labs продемонстрировала его в мае 2025 года. Разработчик подключает агента для программирования к официальному серверу GitHub MCP с использованием личного токена доступа, который, как правило, предоставляет право на доступ ко всем его репозиториям — как публичным, так и приватным. Разработчик запрашивает что-то безвредное, например, просмотр открытых задач в публичном репозитории. Агент их читает. Одна из задач была создана злоумышленником и содержала скрытые инструкции: прочитать приватные репозитории этого пользователя и опубликовать найденное в публичном pull-реквесте. У агента есть вторая возможность (он просто читает содержимое от злоумышленника), первая (токен даёт доступ к приватным репозиториям) и третья (он может создавать публичные pull-реквесты). Агент выполняет всё это. Во время демонстрации приватный код, а также личная платежная информация становились видимыми для кого угодно. Каждое действие, совершённое токеном, соответствовало его полномочиям, и агент работал ровно так, как был запрограммирован. Таким образом, схема тройного контроля просто сработала.
Посмотрите на решение проблемы. Меры безопасности Docker не пытались выявить злонамеренные действия. Они нарушили принцип тройного контроля из-за правил: каждая сессия привязана к одному репозиторию, поэтому как только агент пытается обратиться к другому, его действия блокируются, независимо от указаний. Модель не стала умнее. Одна из функций была удалена на этапе их объединения, и именно так выглядит любая реальная защита.
Почему агенты гораздо хуже чат-ботов
Ранние опасения по поводу безопасности больших языковых моделей заставляли считать инъекции допустимыми. Чат-бот может сказать что-то грубое или утечь свой запрос — это раздражает, но не приводит к катастрофе. Агенты же усугубляют ситуацию во всех отношениях.
Чат-боты генерируют текст, в то время как агенты выполняют действия. Если захватить чат-бот, один человек увидит другой ответ. Если захватить агента, само устройство будет вести себя иначе, обладая реальной функциональностью: оно может отправлять людям электронные письма, переводить средства, удалять записи, объединять код или выполнять команды оболочки. Список десяти наиболее серьезных угроз проекта OWASP Agentic Security на 2026 год представляет собой именно перечень таких последствий: захват целей, неправильное использование инструментов, злоупотребление привилегиями, отравление памяти и сбои, распространяющиеся в многокомпонентных системах с участием агентов. Каждый из этих факторов представляет собой форму вставки данных, усиленную возможностями модели взаимодействовать с реальными системами.
Три фактора объясняют степень уязвимости.
Поверхность атаки — это всё, что читает агент. В реальном агенте команда оператора составляет лишь небольшую часть токенов, причем 70% и более контекста обычно представляют собой результаты работы инструментов и полученный контент. Такое несбалансированное соотношение также является проблемой с точки зрения безопасности. Большая часть информации, на основе которой модель принимает решения, поступает извне, и любой из токенов может быть инструкцией. Ваша надежная команда представляет собой лишь незначительную поправку на фоне потока ненадежных входных данных.
Автономность устраняет ограничения, связанные с скоростью действий человека. Ценность агента заключается в способности выполнять циклы без запроса разрешения на каждом шагу, однако каждый неконтролируемый шаг означает, что введенная инструкция может быть выполнена без возможности ее заблокировать. Чем более автономным и мощным является агент, тем шире становится это окно возможностей. Его функциональность и возможность внедрения инструкций растут вместе, что означает, что при прочих равных чем сильнее агент, тем дороже ему стоит потерять контроль перед атакующим.
Постоянство и цепочечная связь усугубляют ситуацию. У агентов есть память, и её можно «отравить»: злоумышленник в понедельник помещает ложный «факт» в долгосрочное хранилище, и это искажает принятие решений в течение недель. Агенты обращаются к другим агентам, поэтому внедрение в данные одного подагента приводит к каскадным последствиям во всей цепочке, которую никто не контролирует от начала до конца. Агентные браузеры вроде Atlas и Comet позволяют одновременно разместить вставляемого агента в вкладке с входом в банк, электронную почту и консоль управления компанией. Исследователи уже обманули Atlas с помощью вредоносного текста, маскирующегося под URL, а также контента, создающего ложные воспоминания. Ответ OpenAI заслуживает похвалы за честность: компания укрепила продукт с помощью адверсарного обучения и автоматизированных тестов на проникновение, а также четко сообщила пользователям, что проблема ещё не полностью решена.
Способы защиты
Честно говоря, никто не знает, как сделать так, чтобы модель всегда на 100% сопротивлялась инъекциям. Все приведённые ниже методы защиты снижают риск, но ни один из них не устраняет его полностью. Настоящая безопасность достигается путём комбинирования несовершенных механизмов защиты, а прежде всего путём проектирования системы таким образом, чтобы успешная инъекция не могла достичь чего-либо ценного. Вот реальные методы защиты, отделённые от обманчивых иллюзий.
Сначала решите проблему тройного сочетания. Это принесёт наибольшую пользу среди всего остального и не требует использования методов машинного обучения. Для каждого агента проверьте, обладает ли он одновременно всеми тремя необходимыми способностями, и, если да, можно ли в данном контексте отказаться от одной из них. Агент, который читает ненадёжные веб-страницы, не должен иметь у себя учётных данных к производственной базе данных. Агент, работающий с конфиденциальными данными, должен иметь ограниченную возможность внешней связи, ограниченную очень строгим списком разрешённых адресов, чтобы не оставалось возможности отправлять секретную информацию. Решение GitHub, предусматривающее работу с одним репозиторием за сессию, является способом решения проблемы тройного сочетания. Оно эффективно, поскольку основано на архитектурных принципах, а не на вероятностных расчётах.
Используйте такой дизайн, который защищает планировщик от вредоносных данных. Самые перспективные исследования рассматривают проблему внедрения вредоносного кода как вопрос потока данных, а не возможности их обнаружения. Модель Dual LLM и её более строгая версия CaMeL («Победа над внедрением вредоносного кода с помощью специального дизайна», 2025 г.) разделяют агента на две роли: привилегированная модель читает ваш запрос и планирует действия, но никогда не видит ненадежных данных; модель, находящаяся в карантине, читает ненадежные данные — письма или веб-страницы, — но у неё нет инструментов для действий. CaMeL идёт ещё дальше: план привилегированной модели преобразуется в ограниченную программу, а специальный интерпретатор отслеживает происхождение каждого значения. Всё, что берётся из ненадежного источника, получает соответствующую метку, и оно не может привести к опасным действиям, если только политика не разрешает это. Это ближе всего к параметризованным запросам для больших языковых моделей — к чёткому разделению между командами и данными, которое действительно соблюдается. Однако за это приходится платить: кто-то должен составлять правила, а бесконечные запросы на одобрение могут заставить пользователей инстинктивно нажимать «да». Тем не менее всё основано на принципах, и принципы выдерживают атаки решительного злоумышленника.
Ограничьте действия с помощью иерархии разрешений. Оцените каждое действие по степени возможного ущерба и пусть именно механизм контроля, а не промпт, определяет порядок выполнения действий. Чтение происходит бесшумно, всё, что можно отменить, фиксируется в логах; действия, трудные для отмены (отправка, удаление, оплата, слияние), требуют подтверждения человека с точным описанием того, что собирается произойти, а необратимые и дорогостоящие действия блокируются или направляются по процедуре утверждения, на которую модель не может влиять. Промпт — это предложение, с которым может поспорить злоумышленник, тогда как правило механизма контроля — это барьер, преодолеть который он не может. Требовать от модели всегда спрашивать разрешение перед отправкой денег имеет смысл, но само по себе это малоэффективно. Безопасность обеспечивается за счёт того, что для выполнения операции оплаты требуется токен, который модель никогда не хранит.
Используйте принцип минимальных привилегий с ограниченными учетными данными. Внедрение вредоносного кода может нанести ущерб только в той мере, в которой это разрешено агенту, поэтому предоставляйте каждому агенту самый узкий диапазон полномочий, токен с кратким сроком действия и минимальный набор инструментов, необходимых для выполнения задачи. Инцидент с GitHub произошел из-за токена с широкими полномочиями, который вел себя соответственно своим характеристикам, а ограничение OAuth по репозиторию смогло бы этого избежать. Это старый, но эффективный метод безопасности, который превосходит любые изощренные решения.
Добавьте механизм обнаружения, но не полагайтесь на него целиком. Команды сначала внедряют этот слой, хотя на самом деле он должен быть последним. Классификаторы инъекций — это модели, обученные распознавать фразу «игнорировать предыдущие инструкции» и её бесчисленные варианты формулировок, и они действительно помогают выявлять большое количество атак. В этой области работают классификаторы от Anthropic, фильтр XPIA от Microsoft и многие стартапы. Используйте их, поскольку они увеличивают затраты на атаки. Однако четко понимайте, что они предоставляют. Классификатор, блокирующий 99% попыток, кажется отличным решением, но с точки зрения безопасности это считается неудачей, ведь инъекции — это не случайный шум. Злоумышленник может бесконечно перепробовать подходы и адаптироваться к вашему фильтру. Первым шагом в проекте EchoLeak стало создание электронного письма, разработанного для обхода классификатора инъекций от Microsoft, и ему это удалось. При работе с атакующим, способным адаптироваться, уровень утечек в 1% уже представляет собой серьёзное препятствие. Сохраняйте механизм обнаружения как один из слоёв защиты, но никогда не делайте его основой вашей безопасности.
Записывайте всё. Каждый вызов инструмента, загруженный документ и совершённое действие должны фиксироваться и иметь привязку к конкретному источнику. С точки зрения безопасности это и есть слой обнаружения и криминалистики. Позже вам необходимо знать, что именно читал агент непосредственно перед проявлением необычного поведения и откуда поступили указания, а также нужны уведомления о аномалиях, когда он внезапно начинает использовать ресурсы, отличные от его обычного режима работы. Невозможно защититься или даже понять атаку, которую нельзя увидеть. Агент, который невозможно отследить, не только труден в отладке — это нарушение безопасности, о котором вы узнаете от кого-то другого.
Три инцидента для изучения
Шаблоны закрепляются, когда они связаны с реальными событиями. Эти три примера, относящиеся примерно к периоду в восемнадцать месяцев, демонстрируют разные аспекты этой проблемы.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Особенностью является отсутствие каких-либо действий со стороны пользователя, а не какие-то хитроумные уловки. Обнаружен в январе 2025 года, исправлен в мае и стал известен общественности в июне; это была первая атака типа вставки запроса, позволившая извлечь реальные данные из производственной ИИ-системы без каких-либо действий пользователя. Для её реализации были использованы четыре метода обхода защиты: электронное письмо, разработанное для прохождения классификатора XPIA, ссылки в формате Markdown, позволяющие обойти цензуру ссылок, тег изображения, который самостоятельно загружался и отправлял внешний запрос, а также API предварительного просмотра Teams из списка разрешённых инструментов, выполнявшее роль переадресатора, чтобы данные покинули систему через одобренный канал. Каждый из мер контроля, имевшихся у Microsoft, сам по себе был разумным. Однако злоумышленник нашёл промежутки между ними. Набор слоёв обнаружения также представляет собой набор промежутков, и терпеливый противник проверяет их все.
Кража через GitHub MCP (Invariant Labs, май 2025 г.). Об этом уже писали ранее, но стоит ещё раз подчеркнуть главное: ничего не вышло из строя. Ни один аутентификационный параметр не сработал некорректно, а модель осталась неповреждённой. Уязвимость возникла из-за широких полномочий токена доступа, агента, который читал проблемы, написанные злоумышленником, и возможности открывать публичные PR. Не требовалось исправления кода-эксплойта или ошибок памяти — достаточно было ограничить совместное использование сессии этими тремя функциями, которые вообще не должны были объединяться. Именно поэтому безопасность агентов представляет собой новую область исследований. Недостаток заключается в способе взаимодействия компонентов, а не в каком-либо конкретном из них.
Агентные браузеры (Atlas и Comet, конец 2025 года). Как только были выпущены ChatGPT Atlas и Perplexity Comet, исследователи немедленно продемонстрировали методы внедрения кода в поле ввода адресов, при которых текст, маскирующийся под веб-адрес, обрабатывался как команда, а также атаки на память, оставляющие ложный контекст между сессиями. Именно совместное размещение компонентов делает эту ситуацию особенно опасной. Агент, способный к внедрению кода, находится там, где одновременно осуществляется аутентификация в банковских системах, почте и административных консолях — эти три компонента по умолчанию собраны в самом критичном месте. Реакция OpenAI задала добропорядочный тон для всей индустрии: использование методов адверсарного обучения, автоматизированных тестов на проникновение и открытое признание того, что проблема ещё не решена. Следует верить их словам и проектировать решения с учётом возможности того, что агент браузера в конечном итоге будет обманут.
Что оценивать, по уровням
Думайте по уровням и выбирайте что-то для каждого из них.
- Методы защиты на основе шаблонов проектирования: CaMeL и шаблон Dual LLM. Они разделяют процесс планирования от ненадежных данных и отслеживают их происхождение, что обеспечивает наиболее надежные гарантии.
- Классификаторы инъекций: классификаторы от Anthropic, Microsoft XPIA, Lakera Guard, PromptArmor и protectai/rebuff. Они выявляют адверсарский контент в ненадежных данных, увеличивая затраты без создания полноценной защитной барьерной структуры.
- Шлюзы и механизмы обеспечения соблюдения политик: интерцепторы Docker MCP Gateway, Invariant Guardrails и списки разрешенного выходного трафика. Они нарушают совокупность угроз за счет применения политик ограничения сессий, блокировки доступа к разным ресурсам и контроля выходящего трафика.
- Инструменты и критерии оценки для красных команд: AgentDojo, AgentDyn, BIPIA, CyberSecEval и deepteam, которые позволяют делать тестирование на инъекции повторяемым и измеримым.
Правило, помогающее избежать проблем: не покупайте один продукт и считайте себя защищёнными. Каждый из перечисленных элементов представляет собой отдельный слой защиты, и суть в том, что ни один из них сам по себе недостаточен. Надёжная защита предполагает сочетание защиты на основе шаблонов проектирования, ограниченных прав доступа, иерархии разрешений, классификаторов и полного отслеживания действий, выбранных таким образом, чтобы даже преодоление одного из этих слоёв заставляло злоумышленника сталкиваться с следующим.
Варианты сбоев в реальных условиях
- Цепочка утечки данных. Ненадежный контент заставляет агента собирать конфиденциальные данные и отправлять их наружу, как в случаях EchoLeak и GitHub MCP. Для противодействия этому необходимо нарушить эту тройную связь, использовать списки разрешенного выхода данных, отслеживать потоки данных (CaMeL) и ограничивать полномочия агента.
- «Растерянный» агент. Внедренный контент побуждает агента совершать действия, изменяющие состояние системы, которые пользователь никогда не хотел, например отправлять электронные письма, удалять файлы или утверждать транзакции. Чтобы этого избежать, следует применять систему разрешений, требующую утверждения любых значимых действий со стороны человека, причем правила должны находиться в самом инструменте управления.
- Утечка без действий пользователя. Для утечки не требуется никакого вмешательства пользователя, поскольку триггером служит обычное фоновое считывание данных агентом, как в случае автоматической загрузки изображений в EchoLeak. Необходимо ограничить автоматическое получение данных и внешнюю обработку, контролировать их выход и считать всё, что потребляется пассивно, враждебным.
Годовой пропуск на безопасность
Это простой, конкретный метод, который можно применить к уже имеющемуся у вас агенту.
На первый день необходимо проанализировать все три механизма защиты. Возьмите каждого агента, который вы используете, и запишите, к каким частным данным он имеет доступ, какой недоверенный контент он принимает и как может отправлять информацию наружу. Агенты, обладающие всеми тремя механизмами, попадают в верхнюю часть списка. Такой список будет самым ценным документом по безопасности, который вы когда-либо составите, и на это хватит всего одного дня.
День 2: нарушите хотя бы одну из составляющих каждой тройки агентов. Для каждого рискованного агента уберите одну из его способностей в данном настроении. Разделите его на двух агентов с более узкими функциями, сократите их полномочия или ограничьте внешний трафик списком разрешенных адресов. Не всегда удастся устранить всех троих агентов, но устранение хотя бы одного избавит от необходимости недель работы над усилением защиты.
День 3: создайте иерархию разрешений. Составьте список всех действий, которые может выполнять агент, и разделите их на категории «без записи», «с записью», «под подтверждением» и «заблокированные». В коде обеспечьте соблюдение правил двух верхних уровней, недоступных для модели, и проверьте, что подтверждающие сообщения отображают то, что действительно произойдет.
День 4: атакуйте собственного агента. Подготовьте десять враждебных входных данных, включая страницу с подвохом, сообщение, проблему, приглашение, PDF с невидимым текстом и изображение, у которого в атрибуте alt содержатся указания. Запустите агента против каждого из этих данных в среде симуляции и посмотрите, что произойдет. Что-то обязательно сработает, и лучше найти это самостоятельно, чем позволить сделать это кому-то другому. Такие инструменты, как AgentDojo, позволяют повторять эти тесты.
День 5: добавьте механизмы обнаружения и не ставьте слишком высоких ожиданий. Разместите классификатор входных данных перед ненадежными данными и запишите, что он выявляет. Это своего рода сигнализация, которая увеличивает затраты атакующего, но не является полноценным барьером. Отправьте результаты его работы в систему отслеживания, которую вы включите на пятом дне.
6-й день: включите трейсинг в целях обеспечения безопасности. Убедитесь, что каждый вызов инструмента, операция по получению данных и любое действие записываются с указанием ответственного лица, а также настройте оповещения о доступе к ресурсам, выходящем за рамки нормальных паттернов. Если трейсинг уже существует, вы просто изменяете его конфигурацию, а не запускаете новый проект.
7-й день: записывайте все изменения и повторно тестируйте систему после каждого из них. Устойчивость к инъекциям — это не этап, который нужно пройти, а свойство, которое необходимо постоянно поддерживать. Каждый новый инструмент, источник данных или функционал может снова привести к возникновению проблем, которые вы ранее устранили, поэтому добавьте в список проверок вопрос «Не приведет ли это к снова возникновению этих проблем?» и повторите атаки, описанные на четвертый день, каждый раз, когда ответ может быть «да».
Нет четкого завершения
Проблема вставки промптов до сих пор не решена, и, возможно, её невозможно решить так же, как проблему вставки SQL, поскольку та самая особенность, которая делает эти модели полезными для выполнения инструкций на обычном языке, является и причиной их уязвимости, и никто не знает, как сохранить одно без другого. Разработчики современных браузеров начали открыто говорить об этом, что является самым обнадёживающим сдвигом: индустрия перестала притворяться, что более умная модель решит эту проблему.
Ожидание исправления — это не план. Настоящий план заключается в том, чтобы агенты оставались в безопасности даже после того, как модель будет обманута, поскольку это рано или поздно произойдёт. Это направляет усилия инженеров: от создания более умных системных указаний с просьбой о осторожности к разработке структуры, окружающей модель. Необходимо нарушить эту тройную зависимость, разделять планирование от ненадёжных данных, строго контролировать все учетные данные, обеспечивать, чтобы каждое важное действие происходило за барьером, через который модель не сможет пробраться, и внимательно наблюдать за всем. Всё это находится в системе управления, а не в самой модели.
Модель — это способный, доверчивый и подверженный вмешательству компонент, а система управления — это способ её безопасного использования. Если сделать модель своей защитной границей, произойдёт взлом. Если же разместить границу снаружи неё, под своим контролем, появляются шансы на безопасность.
Связанные материалы
- DS-STAR: объяснение — агент Data Science от Google и причины его успеха — Подробный обзор агента Data Science DS-STAR от Google: его семь модулей, цикл отчетности DS-STAR+, опубликованные промпты, результаты абляционных тестов и существующие ограничения.
- Практические заметки: я запускаю агента для программирования с ИИ локально, и его производительность почти в два раза выше — Подробное руководство по практическим заметкам «Я запускаю агента для программирования с ИИ локально, и его производительность почти в два раза выше»: контракты, проверки и готовые блоки кода для команд, использующих эту модель.