Вставка запитів та смертельна трійка: забезпечення безпеки AI-агентів
Ін’єкція запитів та смертельна тріада: чому штучні інтелектуальні агенти не можуть розрізнити ваші інструкції від інструкцій атакувача, як працювали атаки 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-ін’єкції існує справжнє рішення — параметризовані запити, за допомогою яких базі даних чітко повідомляється, що ця частина — це команда, а ця — дані, які ніколи не слід розглядати як команду. Три десятиліття безпеки вебу залежать від правильного розмежування цих елементів всередині системи. У системах на основі ШІ ніхто не знає, як це зробити: усе відбувається через один канал, причому канал команд та канал даних є єдиним. Саме тому звичайний підхід, коли у системному запиті пропонується моделі ігнорувати інструкції з веб-контенту, не спрацьовує. Ви використовуєте скомпрометований канал для захисту того самого скомпрометованого каналу, і добре складений фрагмент контенту завжди може проігнорувати попередження, навіть якщо воно написане англійською мовою.
Два типи атак часто плутають між собою. При прямій ін’єкції користувач сам вводить щось шкідливе, наприклад, вимогу розкрити системний запит. Це більше схоже на jailbreak: людина атакує агента, якого їй дозволено використовувати. Індиректна ін’єкція — це та, що становить загрозу для агентів. Шкідлива інструкція ховається у зовнішньому матеріалі, який агент обробляє під час роботи, наприклад, у веб-сторінці, електронному листі, запрошенні до календаря, коментарі до коду чи проблемі в GitHub. Атакувальник ніколи не звертається безпосередньо до агента. Він залишає пастку у контенті, який очікує, що агент колись прочитає від імені жертви, яка йому довіряє. Усі вищезгадані інциденти були саме такими. Цей тип атак є ефективним, тому що атакувальникові не потрібен доступ до вас, достатньо лише певного впливу на те, на що буде спрямований ваш агент.
Смертельна трійка
Найкориснішою ментальною моделлю тут є концепція „смертельної трійки“ Саймона Віллісона, яка пояснює, чому деякі агенти є надзвичайно вразливими до експлуатації, а інші — лише дратівливими для атаки.
Агент перетворюється на засіб крадіжки даних, коли поєднує в собі три функції.
- Доступ до приватних даних. Він може читати вашу електронну пошту, приватні репозиторії, записи клієнтів чи внутрішній вікі. Це зазвичай причина існування агента, тому його не можна просто видалити.
- Доступ до ненадійного контенту. Він обробляє текст, який не був написаний ним та який ви не перевірили: веб-сторінки, вхідну пошту, документи, дані з систем третіх сторін. Це також зазвичай основна мета його існування.
- Можливість зовнішнього зв’язку. Він може надіслати дані туди, де їх зможе побачити зловмисник, здійснивши HTTP-запит, надіславши електронний лист, викликавши API, відтворивши зображення з URL зловмисника чи створивши запит на зміни.
Будь-який з цих варіантів підходить, а два з них зазвичай дозволяють залишитися живими. Усі три функції в одному агенті під одним набором облікових даних — це наче заряджена зброя, спрямована на ваші дані. Зловмисник, який контролює другу з цих функцій, може перехопити інструкції агента, використати першу для збору конфіденційної інформації та третю — для її надсилання. Саме така послідовність була використана під час атак EchoLeak та атаки GitHub MCP.
Справа з GitHub є настільки зрозумілою, що її можна детально проаналізувати. Invariant Labs продемонстрував це у травні 2025 року. Розробник під’єднує агента для програмування до офіційного сервера GitHub MCP за допомогою особистого токена доступу, який, як це зазвичай налаштовується, дає право на доступ до всіх його репозиторіїв — як публічних, так і приватних. Розробник просить про щось нешкідливе, наприклад, переглянути відкриті проблеми у публічному репозиторії. Агент їх читає. Одна з проблем була створена зловмисником та містила приховані інструкції: прочитати приватні репозиторії цього користувача та опублікувати знайдене у публічному запиті на з’єднання. У агента є друга можливість (він просто читає контент зловмисника), перша (токен дає доступ до приватних репозиторіїв) та третя (він може створювати публічні запити на з’єднання). Він виконує все це. Під час демонстрації приватний код та навіть особисті фінансові дані стали видимими для будь-кого. Кожна дія, яку виконував токен, була в межах його дозволів, і агент працював саме так, як було запроєктовано. Трифекта просто не була можлива.
Подивіться на рішення. Механізми захисту Docker не намагалися виявити зловмисну проблему. Вони порушили принцип трифекти через правила: кожна сесія прив’язана до одного репозиторію, тож як тільки агент намагається звернутися до іншого, це блокується, незалежно від інструкцій. Модель не стала розумнішою. Функціональність була видалена саме на етапі їх поєднання, і саме так виглядає кожен справжній захист.
Чому агенти набагато гірші за чат-ботів
Ранні побоювання щодо безпеки ШІ призвели до того, що ін’єкції вважалися терпимими. Чат-бот може сказати щось грубе або витекти його запит. Це дратує, але не є катастрофою. Агенти ж змінюють ситуацію у всіх напрямках.
Чат-боти створюють текст, тоді як агенти виконують дії. Якщо захопити чат-бота, одна людина отримує іншу відповідь. Якщо захопити агента, сам об’єкт починає поводитися інакше, маючи реальну потужність: він може надсилати електронні листи, переказувати кошти, видаляти дані, об’єднувати код чи виконувати команди шеллу. Топ-10 проекту OWASP Agentic Security за 2026 рік схожий на список саме таких наслідків: захоплення цілей, неправильне використання інструментів, зловживання привілеями, отруєння пам’яті та збої, які поширюються в багатоагентних системах. Кожен з цих факторів є проявом ін’єкційних атак, посиленого зв’язком моделі з реальними можливостями.
Три фактори пояснюють рівень вразливості.
Поверхня атак — це все, що читає агент. У справжньому агенті запит оператора є лише невеликою частиною токенів, а 70% або більше контексту часто складають результати роботи інструментів та отриманий контент. Таке нерівномірне співвідношення також є проблемою з безпекою. Більша частина інформації, яка знаходиться в „голові“ моделі під час прийняття рішення, походить ззовні, і кожен з цих токенів може бути інструкцією. Ваш надійний запит є лише незначною похибкою порівняно з потоком ненадійних вхідних даних.
Автономність усуває людські перешкоди. Цінність агента полягає у можливості виконувати цикли без отримання дозволу на кожному кроці, але кожен некерований крок — це момент, коли введена інструкція виконується без можливості її зупинити. Чим автономнішим та потужнішим є агент, тим ширшими є ці можливості. Здатності та можливості введення інструкцій розвиваються разом, що означає, що за інших рівних умов чим сильніший агент, тим дорожче його втрата для зловмисника.
Стійкість та ланцюгові зв’язки лише погіршують ситуацію. Агенти мають пам’ять, а цю пам’ять можна підточити: зловмисник у понеділок записує фальшивий „факт“ у довгострокове зберігання, і це спотворює рішення протягом тижнів. Агенти викликають один одного, тож введення даних у систему одного підагента поширюється по всьому ланцюгу, який ніхто не контролює від початку до кінця. Крім того, браузери на основі агентів, такі як Atlas та Comet, можуть одночасно розмістити агента, здатного до введення даних, у вкладці, де ви увійшли до свого банку, електронної пошти чи консолі керування компанії. Дослідники вже обманули Atlas за допомогою шкідливого тексту, прикиданого під URL, та контенту, який створює фальшиві спогади. Відповідь OpenAI заслуговує на похвалу за чесність: компанія посилила продукт за допомогою адверсарного навчання та автоматизованих тестів на вразливості, а також чітко повідомила користувачам, що проблема ще не повністю вирішена.
Заходи захисту, які допомагають
Відверто кажучи, ніхто не знає, як зробити так, щоб модель завжди на 100% протистояла втручанню. Кожен з наведених нижче захистів знижує ризик, але жоден не усуває його повністю. Справжня безпека досягається шляхом поєднання недосконалих захисних шарів, а насамперед шляхом проектування системи так, щоб успішне втручання не могло дістатися до чогось цінного. Ось справжні захисти, відокремлені від обманливих ілюзій.
Спочатку подолайте цю „трійку“ проблем. Це принесе найбільшу користь серед усього іншого тут, і для цього не потрібен машинний навчання. Для кожного агента перевірте, чи має він усі три можливості одночасно, а якщо так, чи можна якусь з них відкинути в цьому контексті. Агент, який читає ненадійні веб-сторінки, не повинен також мати облікові дані до продакшн-бази даних. Агент, який має доступ до приватних даних, повинен мати обмежений зовнішній зв’язок лише переліком дозволених адрес, настільки жорстким, щоб не залишилося можливості надіслати секрети. Виправлення в GitHub про один репозиторій на сеанс є способом подолання цієї „трійки“ проблем. Воно ефективне, тому що ґрунтується на архітектурних принципах, а не на ймовірностях.
Використовуйте дизайн, який захищає планувальник від отруйних даних. Найбільш перспективні дослідження розглядають проблему вставки даних як питання потоку інформації, а не можливості її виявлення. Модель Dual LLM та її більш сувора версія CaMeL („Defeating Prompt Injections by Design“, 2025) розділяють агента на дві ролі. Привілейована модель читає ваш запит та планує кроки, але ніколи не бачить ненадійних даних. Модель у карантині читає ненадійні матеріали – електронні листи чи веб-сторінки – проте не має інструментів для дії. CaMeL йде ще далі: план привілейованої моделі перетворюється на програму з обмеженими правами, а спеціальний інтерпретатор відстежує походження кожної значення. Усе, що береться з ненадійного джерела, позначається відповідним чином, і воно не може призвести до небезпечних дій, якщо тільки це не передбачено правилами. Це найбільш близько до параметризованих запитів для ШІ, де існує чіткий розділ між командою та даними, який дійсно дотримується. Але є своя ціна: хтось мусить писати правила, а безкінечні запити на схвалення можуть змусити користувачів інстинктивно натискати «так». Проте все це ґрунтується на принципах, а принципи витримують навіть атаки рішучого зловмисника.
Обмежуйте дії за допомогою ієрархії дозволів. Ранжуйте кожну дію залежно від можливої шкоди, яку вона може завдати, і нехай сам механізм контролю, а не запит користувача, забезпечує дотримання цього ранжування. Читання відбувається безшумно, все, що можна скасувати, фіксується; дії, які важко скасувати (надсилання, видалення, оплата, об’єднання), потребують підтвердження людини з точним описом того, що ось-ось станеться, а незворотні та дорогі дії блокуються або направляються через процес схвалення, на який модель не може вплинути. Запит користувача — це пропозиція, з якою може посперечатися зловмисник, тоді як правило механізму контролю — це бар’єр, який він подолати не може. Прохати модель завжди запитувати перед надсиланням грошей варто, але це саме по собі мало що дає. Безпека досягається тоді, коли код оплати вимагає токена, якого модель ніколи не має.
Застосовуйте принцип мінімальних привілеїв із обмеженими обліковими даними. Втручання може завдати шкоди лише в міру того, що дозволено агенту, тому надавайте кожному агенту найвужчі обмеження, токени з найкоротшим терміном дії та мінімум інструментів, які все одно дозволяють виконати завдання. Інцидент у GitHub стався через широкі токени, які поводились як зазвичай, а обмеження OAuth для кожного репозиторію могли б це запобігти. Це стара, але ефективна практика безпеки, яка краща за будь-які хитромудрі рішення.
Додайте механізм виявлення, але не покладайтеся на нього повністю. Команди спочатку використовують цей рівень захисту, хоча насправді він має бути останнім. Класифікатори ін’єкцій — це моделі, навчені розпізнавати команди типу „ігнорувати попередні інструкції“ та їхні численні варіації, і вони дійсно ефективно фіксують багато спроб атак. У цій галузі працюють класифікатори від Anthropic, фільтр XPIA від Microsoft та багато стартапів. Використовуйте їх, адже вони підвищують вартість атак. Проте майте чітке уявлення про те, що вони можуть зробити. Класифікатор, який блокує 99% спроб, здається чудовим, але з точки зору безпеки це вважається невдачею, адже ін’єкції — це не випадковий шум. Зловмисник може безкінечно перепробовувати та пристосовуватися до вашого фільтра. Першим кроком у проекті EchoLeak був електронний лист, створений для обходу класифікатора ін’єкцій від Microsoft, і він це зробив. Проти атакувальника, який здатний адаптуватися, рівень витоків у 1% є серйозною перешкодою. Зберігайте механізм виявлення як один із рівнів захисту, але ніколи не робіть його основою вашої безпеки.
Записуйте все. Кожен виклик інструменту, отриманий документ та виконана дія мають бути задокументовані та прив’язані до конкретних дій. З точки зору безпеки це є вашим рівнем виявлення та криміналістичного аналізу. Пізніше ви хочете знати, що саме прочитав агент безпосередньо перед дивною поведінкою та звідки надійшли інструкції, а також хочете отримувати сповіщення про аномалії, коли він раптово починає використовувати ресурси, що виходять за межі його звичайної моделі. Ви не зможете захиститися чи навіть зрозуміти атаку, яку не можете бачити. Агент, якого неможливо спостерігати, не лише складний у діагностиці – це ще й порушення безпеки про яке ви дізнаєтесь від когось іншого.
Три інциденти для вивчення
Шаблони залишаються стабільними, коли вони пов’язані з реальними подіями. Ці три інциденти, що сталися протягом приблизно вісімнадцяти місяців, демонструють різні рівні цієї проблеми.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Найбільш примітним є відсутність будь-яких дій з боку користувача, а не якісь складні трюки. Він був виявлений у січні 2025 року, виправлений у травні та оприлюднений у червні; це була перша атака типу prompt injection, яка дозволила отримати справжні дані з промислової системи штучного інтелекту без жодних дій з боку користувача. Для цього було використано чотири методи обхіду: електронний лист, розроблений для проходження класифікатора XPIA, посилання у форматі Markdown, які ухилялися від цензури посилань, тег зображення, який самостійно завантажувався та надсилав зовнішні запити, а також API для попереднього перегляду в Teams, включене до списку дозволених, яке виступало посередником, щоб дані виходили через схвалений канал. Кожен з механізмів контролю, які мала Microsoft, був розумним окремо. Однак зловмисник знайшов прогалини між ними. Низка шарів виявлення також є низкою прогалин, і уважний атакувальник перевіряє їх усі.
Крадіжка через GitHub MCP (Invariant Labs, травень 2025 року). Про це вже писали раніше, проте варто ще раз наголосити: нічого не зламалося. Жодні облікові дані не виявилися недійсними, а модель залишилася недоторканою. Вразливість виникла через широкий токен доступу, агента, який читав проблеми, написані зловмисником, та можливість створювати публічні PR. Не було коду для експлуатації чи помилок пам’яті, які потрібно було б виправити — лише три функції, які ніколи не повинні були використовувати спільну сесію. Саме тому безпека агентів є новою галуззю. Недолік полягає у способі поєднання цих елементів, а не в будь-якому з них окремо.
Агентні браузери (Atlas та Comet, кінець 2025 року). Як тільки були оприлюднені ChatGPT Atlas та Comet від Perplexity, дослідники негайно продемонстрували методи вставки коду в поле пошуку, коли текст, прикиданий під веб-адресу, виконувався як команда, а також атаки на пам’ять, які залишали фальшивий контекст з однієї сесії в іншу. Саме спільне розташування робить цю ситуацію особливо небезпечною. Агент, який може вставляти код, знаходиться там, де ви одночасно автентифікуєтесь у своєму банку, електронній пошті та адміністративних консолях – ці три сервіси за замовчуванням знаходяться у найбільш критичних місцях. Реакція 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. Потрібно обмежити автоматичне отримання та зовнішнє відтворення даних, контролювати їх вихід та вважати все, що отримується пасивно, загрозливим.
Тижневий пас безпеки
Це простий, конкретний підхід, який можна застосувати до агента, який вже у вас є.
День 1: визначте склад набору захистів. Візьміть кожного агента, який ви використовуєте, та зафіксуйте, до яких приватних даних він може отримати доступ, який ненадійний контент він обробляє та як може надсилати інформацію назовні. Усі агенти, які мають усі три елементи захисту, потрапляють у верхню частину списку. Цей огляд стане найціннішим документом з питань безпеки, який ви коли-небудь напишете, і на це вистачить одного дня.
День 2: порушіть принаймні одну з умов кожної тріфекти. Для кожного ризикованого агента відмініть одну з його можливостей у цьому налаштуванні. Розділіть його на двох агентів із вужчими обов’язками, зменшіть його повноваження або обмежте вихідний трафік лише списком дозволених адрес. Не завжди вдасться видалити всі трьох, але видалення лише одного допоможе уникнути тижнів постійної налаштування захисту.
День 3: створіть ієрархію дозволів. Випишіть усі дії, які може виконувати агент, та розсортуйте їх за рівнем активності – без звукового сигналу, із записом, після підтвердження та заблоковані. Забезпечте дотримання двох верхніх рівнів у коді, поза досяжністю моделі, та перевірте, чи інформація про підтвердження відображає те, що насправді станеться.
День 4: атакуйте власного агента. Підготуйте десять ворожих вхідних даних, включаючи сторінку з підступкою, повідомлення, проблему, запрошення, PDF із невидимим текстом та зображення, у якого текст опису містить вказівки. Запустіть агента проти кожного з цих варіантів у сандбоксі та подивіться, що станеться. Щось спрацює, і знаходження цього самостійно краще, ніж коли його знайде хтось інший. Такі інструменти, як AgentDojo, дозволяють повторювати ці випробування.
День 5: додайте механізми виявлення та тримайте очікування помірними. Розмістіть класифікатор введених даних перед ненадійними вхідними даними та записуйте те, що він виявляє. Це своєрідна сигналізація, яка підвищує витрати атакувача, але не є повноцінною перешкодою. Надсилайте результати його роботи у систему відстеження, яку ви активуєте на дні 6.
День 6: увімкніть відстеження заради безпеки. Переконайтеся, що кожен виклик інструменту, отримання даних та виконання дії записуються з чітким вказанням власника, а також налаштуйте сповіщення про доступ до ресурсів, який виходить за межі звичайних патернів. Якщо відстеження вже існує, ви змінюєте конфігурацію, а не запускаєте проект.
День 7: запишіть це та перевіряйте ще раз після кожної зміни. Стійкість до втручань — це не етап, який потрібно пройти, а властивість, яку потрібно підтримувати. Кожен новий інструмент, джерело даних чи функція може знову створити ситуацію, яку ви раніше усунули, тому додайте до списку перевірки питання «Чи це знову створює таку ситуацію?» та знову проводьте атаки з четвертого дня, коли відповідь може бути «так».
Без чіткого завершення
Проблема вставки запитів не вирішена, і, можливо, її неможливо вирішити так само, як проблему вставки SQL, оскільки саме та властивість, яка робить ці моделі корисними для виконання інструкцій звичайною мовою, є й тією, що дозволяє їх експлуатувати, і ніхто не знає, як зберегти одне без іншого. Розробники сучасних браузерів почали відкрито про це говорити, що є найбільш обнадійуючим розвитком ситуації: індустрія припинила вдавати, ніби розумніша модель зробить цю проблему непомітною.
Чекання на виправлення — це не план. Справжній план полягає у тому, щоб агенти залишалися в безпеці навіть після того, як модель буде обдурена, адже це колись трапиться. Це спрямовує зусилля інженерів не на створення більш розумних системних запитів, які закликають до обережності, а на структуру, що оточує модель. Подолайте цю тріаду проблем: плануйте окремо від ненадійних даних, суворо контролюйте кожні облікові дані, робіть кожну важливу дію за «стіною», яку модель не зможе подолати словами, та постійно спостерігайте за всім. Усе це знаходиться у системі керування, а не в самій моделі.
Модель — це здатний, довірливий та схильний до впливу ззовні компонент, а система керування — це спосіб її безпечного використання. Якщо зробите модель своєю безпековою межею, вона буде проникнута. Якщо розмістите межу поза нею, під своїм контролем, у вас буде шанс.
Пов’язана література
- DS-STAR: пояснення, агент з науки про дані від Google та причини його успіху — детальний огляд агента з науки про дані DS-STAR від Google: його сім модулів, цикл звітності DS-STAR+, опубліковані запити, результати тестів та існуючі обмеження.
- Практичні нотатки: я запускаю агента для програмування з ШІ локально, і його продуктивність майже вдвічі вища — поетапний огляд практичних нотаток «Я запускаю агента для програмування з ШІ локально, і його продуктивність майже вдвічі вища»: контракти, перевірки та шаблони коду для команд, які використовують цю модель.