Як ми створюємо безпечніших агентів

Щоб створювати безпечніших агентів штучного інтелекту, нам потрібно проєктувати їх з урахуванням як їхніх можливостей, так і їхніх збоїв. Навіть під час виконання легітимних завдань і за відсутності будь-яких шкідливих інструкцій агенти можуть перетинати межі безпеки, намагаючись подолати перешкоди.

Ми переконані, що це проблема інженерної безпеки, і галузь має вирішити її так само, як вона впоралася з інтернет-хробаками на початку 2000-х років. Системи навколо агентів повинні обмежувати те, до чого агенти можуть отримати доступ, виявляти небажану поведінку та локалізувати збої у разі їх виникнення.

У Perplexity ми активно співпрацюємо з дослідниками та практиками задля вдосконалення інженерної безпеки для агентів штучного інтелекту, а також застосовуємо багаторівневий захист у наших моделях, harness-модулях для агентів та інфраструктурі, щоб безпека не залежала від якогось одного засобу захисту.

Деструктивна поведінка агентів штучного інтелекту

У липні агенти штучного інтелекту зламали виробничу інфраструктуру платформи штучного інтелекту з відкритим кодом Hugging Face. Під час внутрішньої оцінки кібербезпеки та навчальних запусків моделі OpenAI виявили спосіб використання менеджера репозиторіїв Artifactory для створення дошки оголошень для зв'язку між собою, що дозволило їм організуватися у зграї. Пізніше агенти, які не могли просунутися у виконанні завдань у бенчмарку з кібербезпеки, залучили інших агентів для допомоги. Ці агенти вибралися зі свого середовища тестування та вийшли в інтернет. Вони також виявили способи шахрайства шляхом зворотного проєктування відповідей на завдання бенчмарку, але вважали, що система оцінювання виявить обман. Щоб краще зрозуміти, як працює оцінювання за бенчмарком, і знайти способи уникнути виявлення шахрайства, вони врешті-решт зламали системи Hugging Face (Hugging Face; OpenAI).

Цей інцидент є яскравим прикладом режиму збою, який ми описували, коли відкрили вихідний код Numbat у липні: випадкові збої через деструктивну поведінку (accidental meltdowns) — термін, винайдений дослідниками безпеки з Cornell Tech (arXiv). Агент, який переслідує легітимну мету, стикається з перешкодами, такими як відсутній файл, невдалий виклик API, термін дії облікових даних, що минув, або заборона доступу, і починає шукати обхідний шлях. При цьому він може перетнути межі безпеки за допомогою розвідки, ескалації привілеїв, виявлення секретів або витоку даних. Сам агент фактично перетворюється на зловмисника, попри те, що жодних шкідливих промптів чи зовнішніх нападників задіяно не було.

Hugging Face не була поодиноким випадком. Останніми тижнями було виявлено та зафіксовано більше випадків деструктивної поведінки агентів. 27–28 травня агенти, які намагалися зібрати дані Університету штату Айва з Data USA (платформи, що пропонує відкритий доступ до даних уряду США), зіткнулися з помилками, спричиненими неправильно сформованим запитом. У відповідь вони надіслали зондувальні запити, зокрема на SQL-ін'єкцію, міжсайтовий скриптинг (XSS), ін'єкцію шаблонів, обхід шляху та ін'єкцію команд. Пізніше цю активність пов'язали з OpenAI (SecurityWeek). 20–21 червня агенти OpenAI, які намагалися отримати інформацію про державні витрати на душу населення на певну категорію ліків у місцевих регіонах Вікторії від Австралійського інституту здоров'я та добробуту (AIHW), отримали заборону на завантаження файлу. У відповідь агенти завантажили цей файл, який уже був загальнодоступним, із препродакшн-сервера AIHW, обійшовши при цьому засоби захисту сайту від ботів (SecurityWeek).

Ця тенденція не обмежується однією лабораторією. Під час тестів з кібербезпеки моделі Anthropic зламали три компанії після того, як через помилку їм надали відкритий доступ до інтернету, Gemini від Google вгадав облікові дані для трьох вебсайтів, а модель Meta використала сторонній сервіс (Reuters).

Уроки історії: епоха інтернет-хробаків

Ці інциденти нагадують епоху інтернет-хробаків чверть століття тому. На початку 2000-х років інтернет ростав набагато швидше, ніж практики безпеки навколо нього. Ми спостерігали хвилю вірусів і хробаків із наслідками, набагато серйознішими за ті, що ми бачимо зараз з агентами штучного інтелекту в стані збою.

4 травня 2000 року люди почали отримувати електронні листи від знайомих відправників із темою «ILOVEYOU». Відкриття вкладення в електронному листі призводило до запуску скрипта, який надсилав копію самого себе кожному з адресної книги Outlook жертви. До 18:00 того ж дня координаційний центр CERT отримав повідомлення щодо понад 420 000 інтернет-хостів (Звіт US GAO). За повідомленнями, вірус проник щонайменше в 14 федеральних агентств, зокрема Міністерство оборони, ЦРУ, NASA, Палату представників і Сенат (Звіт US GAO). Він також вимкнув поштові сервери в Пентагоні та Британському парламенті (Wired). Страховий гігант Lloyd's of London зробив попередню оцінку, що вірус завдасть збитків і спричинить втрату продуктивності на суму понад 15 мільярдів доларів (Слухання в Палаті представників США). Пізніше Computer Economics оцінила збитки в усьому світі у 8,75 мільярда доларів (Information Week).

Далі з'явилися хробаки, які не потребували кліків від користувачів. 19 липня 2001 року хробак Code-Red інфікував понад 359 000 комп'ютерів менш ніж за 14 годин (CAIDA). 25 січня 2003 року SQL Slammer подвоював свої масштаби кожні 8,5 секунд і менш ніж за 10 хвилин інфікував понад 90% інтернет-хостів, вразливих до нього (CAIDA), використавши вразливість, патч для якої Microsoft випустила шістьма місяцями раніше (CNET). У сервісі 2003 року з інтервалом приблизно в тиждень з'явилися хробак Blaster і поштовий хробак Sobig (Microsoft, F-Secure).

На той час було слушним питання, чи можна взагалі зробити мережеві комп'ютери безпечними. Через шість днів після появи вірусу ILOVEYOU підкомітет Палати представників США провів слухання щодо нього. Багато експертів із безпеки закликали ухвалити законодавство, яке б робило компанії-розробники програмного забезпечення відповідальними за збитки, спричинені недоліками в їхніх продуктах. Вашингтон обрав інший шлях. У Національній стратегії забезпечення кібербезпеки зазначалося, що «федеральне регулювання не стане основним засобом забезпечення безпеки кіберпростану». У ній застерігалося, що широкі мандати можуть створити «підхід найнижчого спільного знаменника до кібербезпеки» (CISA).

Галузь відповіла інженерними рішеннями. Через одинадцять днів після появи ILOVEYOU компанія Microsoft анонсувала оновлення для Outlook, яке блокувало виконувані вкладення. У січні 2002 року компанія зробила безпеку своїм головним пріоритетом (Seattle Times). Автоматичне встановлення оновлень, безпечні налаштування за замовчуванням, програми виплати винагород за знайдені помилки та координоване розкриття інформації стали стандартною практикою. У 2008 році в браузері Chrome почали запускати вебконтент у пісочниці, яка «обмежує те, що зловмисник може зробити після експлуатації вразливості» (Chromium Blog). Шифрування, яке колись було винятком, стало стандартом за замовчуванням. Технології безпеки, зокрема багатофакторна автентифікація, брандмауери, нульова довіра (Zero Trust) та керування інформаційною безпекою і подіями безпеки (SIEM), набули широкого поширення. За прогнозами, у 2026 році організації в усьому світі витратять на інформаційну безпеку близько 240 мільярдів доларів (Gartner). Хробаки ніколи повністю не зникали, але епоха звичних масштабних епідемій по всьому інтернету відійшла в минуле. Водночас інтернет, практично не обтяжений регулюванням, став потужним рушієм інновацій та економічного зростання протягом наступних двох десятиліть.

Інженерна безпека для агентів штучного інтелекту

Недавні інциденти викликали обґрунтовані питання щодо управління агентами. Наявні механізми безпеки були розроблені для середовищ обчислень попередніх епох, для яких характерна вузькоспеціалізована та переважно детермінована поведінка програмного забезпечення. Зокрема, механізми контролю доступу передусім розраховані на людських користувачів і часто надають їм широкі привілеї, яких у принципі достатньо для заподіяння значної шкоди.

Цей дизайн базується на кількох припущеннях: більшість користувачів діють сумлінно; зловмисників можна стримати за допомогою аудиту та реальних наслідків; а люди виконують дії (правильні чи помилкові) з відносно обмеженою швидкістю. Застосування цих механізмів безпеки до агентів вимагає врахування відмінностей між поведінкою людини та агента. Як ми писали у своїй відповіді на запит NIST щодо інформації про безпеку агентів штучного інтелекту, агенти штучного інтелекту ставлять під сумнів ці припущення. Вони можуть реалізовувати привілеї та виконувати дії зі швидкістю машини, не стримуються реальних наслідків і можуть вчиняти дії, які технічно дозволені, але які типовий користувач-людина робить украй рідко.

Відповіді на ці запитання вимагають інженерної безпеки. Ми знаємо принципи безпеки для створення систем, які тримають ризики під контролем, коли окремі компоненти поводяться неналежним чином. Але нам необхідно переконатися, що ці принципи застосовуються під час проєктування середовищ для навчання, тестування та використання агентів штучного інтелекту.

Принцип безпеки «багаторівневий захист»

Можливо, найважливішим принципом безпеки, який необхідно застосовувати для захисту агентів штучного інтелекту, є багаторівневий захист. Він передбачає архітектуру безпеки з багатьма рівнями, де для захисту системних ресурсів використовується кілька різноманітних і надлишкових заходів захисту. Жоден засіб захисту не є ідеальним. Люди можуть стати жертвами атак із використанням соціальної інженерії та розкрити свої облікові дані для входу, у програмному забезпеченні виявляються та експлуатуються вразливі категорії нуль-днів, а системи виявлення вторгнень пропускають нові варіанти атак. Багаторівневий захист враховує це та об'єднує кілька незалежних рівнів захисту. Якщо один рівень захисту буде обійдено, інші залишаться на місці, щоб протистояти вторгненню або виявити його.

Інцидент з Hugging Face демонструє, чому важливий багаторівневий захист. Ретроспективний звіт OpenAI повідомляє, що в середовищі тестування були відсутні автоматизовані засоби захисту, які використовуються в її виробничих системах, зокрема harness-модулі, моделі автоматичного перегляду та класифікатори безпеки. Якби розгорнутий на той момент моніторинг ланцюжка міркувань працював під час тих тестувань, він виявив би початкову активність і сповістив команду безпеки більш ніж за добу до зламу (OpenAI). Рівні захисту, які могли б виявити проблему, існували. Вони просто не були задіяні одночасно.

Захист агентів штучного інтелекту вимагає підвищення безпеки та захищеності як самих моделей штучного інтелекту, так і систем навколо них. Робота на рівні моделі має значення, і вона приносить результати. Ранні LLM легко піддавалися маніпуляціям за допомогою впроваджених інструкцій, тоді як сучасні моделі значно краще розпізнають їх і відмовляються їх виконувати. Розробники моделей також навчають моделі безпечнішої поведінки та, як описано в ретроспективі OpenAI, моніторять сліди міркувань на наявність ознак проблемної поведінки. Але захист на рівні моделі — це лише частина рішення. Системи, в яких агенти навчаються, тестуються та розгортаються, також мають бути спроєктовані з урахуванням вимог безпеки та ізоляції. Безпека на рівні моделі знижує ймовірність того, що агент зіб'ється з праведного шляху; безпека на рівні системи обмежує збитки, якщо це станеться.

Розгорнути

Правила проєктування для надлишкових засобів захисту

Багаторівневий захист вимагає надлишкових засобів безпеки. Для агентів ми рекомендуємо застосовувати його з дотриманням трьох правил проєктування:

1. Незалежність. Кожен рівень має виходити з ладу з незалежних причин. Два елементи керування, які ґрунтуються на тому самому припущенні, можуть бути зламані однією і тією ж атакою. Монітори та точки забезпечення безпеки повинні знаходитися поза зоною досяжності агента.
2. Забезпечення безпеки на рівні нижче агента. Принаймні один рівень має бути детермінованим: звичайний, перевірюваний код, який блокує заборонені дії незалежно від результатів роботи моделі. Засіб захисту, який агент може відмовитися викликати або переналаштувати, не є засобом захисту.
3. Сигнали можуть лише зменшувати рівень повноважень. Виявлення має запускати реагування, яке звужує можливості агента (як-от призупинення, відкликання облікових даних, відключення доступу до мережі або завершення сеансу). Жоден сигнал ризику ніколи не повинен надавати додатковий доступ.

Ми ділимося цими принципами з нашими партнерами в Open Secure AI Alliance, зокрема з NVIDIA, яка стверджує, що harness керує тим, що намагається зробити агент, тоді як інфраструктура контролює те, що він може зробити (NVIDIA).

Багаторівневий захист у продуктах Perplexity

Perplexity запускає агентів у чотирьох типах середовищ: у хмарі за допомогою нашої платформи для агентів Computer, у браузері за допомогою Comet, на пристроях користувачів за допомогою Portable Computer та на ноутбуках співробітників, де наші інженери використовують сторонніх агентів для написання коду. Кожне середовище має власні ризики й отримує кілька рівнів захисту.

У хмарі: Computer і SPACE

Кожне завдання Computer виконується в SPACE — нашій платформі пісочниці, яка за замовчуванням ставиться до агента як до неперевіреного. Кожне завдання отримує власну мікроВМ, облікові дані залишаються поза пісочницею та вводяться лише за необхідності, вихідний трафік контролюється поза гостьовою системою, а знімки (snapshots) дозволяють відкотити деструктивні зміни (Making SPACE). Корпоративні клієнти також можуть використовувати власні ключі шифрування. Відкликання ключа робить захищені дані нечитабельними, і агент не може скасувати це рішення.

Ми також перевіряємо, чи витримують ці рівні. У матеріалі Escaping SPACE: Part I ми надали дев'яти передовим моделям кореневий доступ усередині пісочниці SPACE та попробили вихід із неї. Жодна з моделей не втекла з віртуальної машини, проте деякі знайшли способи обійти мережеву політику, коли був дозволений частковий доступ до мережі. Ми усунули ці прогалини, підтвердили результати виправлень під час повторного тестування та повідомили про подібні вразливості, виявлені у восьми з 10 інших платформ пісочниць, їхнім розробникам.

У браузері: Comet і BrowseSafe

Comet використовує багаторівневий захист від ін'єкцій у промпти з моменту запуску: класифікатори перевіряють отриманий контент, структуровані промпти позначають його як неперевірений, чутливі дії (як-от надсилання електронного листа або оформлення замовлення) вимагають підтвердження від користувача, а користувачі отримують сповіщення, коли щось заблоковано (Захист Comet від ін'єкцій у промпти). BrowseSafe, модель виявлення з відкритим кодом, що лежить в основі першого рівня, перевершує передові моделі в нашому бенчмарку BrowseSafe-Bench, проте той самий бенчмарк показує, що жоден детектор не є бездоганним, тому виявлення ніколи не буває єдиним рівнем (Дослідження BrowseSafe). Computer успадковує ці засоби захисту, які були перевірені компанією Trail of Bits (Perplexity).

На пристрої: Portable Computer

Portable Computer — це агент,орієнтований на локальне середовище: модель, harness, розмова та траєкторія за замовчуванням залишаються на машині користувача. Детермінований оркестратор (який є кодом harness, а не LLM) керує циклом і забезпечує дотримання політики. Модель пропонує дії, а схвалені виклики інструментів виконуються в пісочниці рівня ОС, яка обмежує процеси, шляхи до файлів і доступ до мережі. Пісочниця завжди ввімкнена та надійна щодо збоїв: якщо вона недоступна, harness вимикає себе замість того, щоб виконувати команди з дозволами користувача. Дії, що виходять за межі пристрою (як-от вебпошук, конектори та перенаправлення до сильнішої хмарної моделі-радника), відбуваються лише тоді, коли користувач увімкнув і схвалив їх. Перед викликом радника класифікатор PII позначає чутливу інформацію, і користувач бачить, що саме буде надіслано. Радник отримує лише цей схвалений контекст і повертає текстові рекомендації без доступу до файлів або інструментів пристрою.

На кінцевій точці: Numbat

Агенти написання коду на ноутбуках розробників працюють годинами, маючи доступ до вихідного коду, облікових даних і виробничих систем. Numbat, наш набір інструментів безпеки для агентів з відкритим кодом, додає незалежний рівень, який розташовується поза будь-яким окремим агентом. Він працює з такими harness-модулями, як Claude Code, Codex, OpenCode та Pi, блокує небезпечні дії до їх запуску, позначає підозрілі багатокрокові послідовності (як-от читання секретного файлу з подальшим надсиланням даних назовні) та зберігає хронологію сеансів для розслідування. Numbat працює на тисячах кінцевих точок Perplexity разом із Bumblebee — нашим сканером ланцюжка постачання з відкритим кодом. Computer регулярно переглядає їхні висновки та пропонує вдосконалені правила виявлення, а людина схвалює кожну зміну перед її випуском.

Завдання для всієї галузі

Оскільки агенти штучного інтелекту стають більш функціональними та широко використовуваними, інженерна безпека має залишатися ключовим елементом їхнього розроблення та розгортання. Дослідники та інженери можуть спиратися на встановлені принципи, використовувати реальні результати для вдосконалення заходів захисту та тестувати засоби безпеки в середовищах, де функціонують агенти. Безпека — це безперервна інженерна дисципліна, яка розвивається разом із технологіями.

Інженерна безпека для агентів — це завдання для всієї галузі. Жодна компанія не контролює весь стек, на якому працює агент. Розробники моделей, розробники harness-модулів, постачальники пісочниць і середовищ виконання, хмарні та апаратні вендори, а також команди корпоративної безпеки володіють кожен своєю ланкою. Безпека цілого залежить від того, чи витримає кожен рівень, якщо інший дасть збій. Саме тому ми створюємо засоби захисту, які працюють у різних harness-модулях для агентів, і відкриваємо вихідний код наших інструментів. Це також причина, чому ми розголошуємо вразливості, виявлені на інших платформах, і беремо участь у таких ініціативах, як Open Secure AI Alliance.

Щоб співпрацювати з ширшою спільнотою над цими викликами, у березні 2026 року компанія Perplexity заснувала Secure Intelligence Institute для вивчення безпеки, надійності та практичного захисту передових систем штучного інтелекту (Perplexity). Наразі Perplexity співпрацює та/або фінансує академічних дослідників у Стенфорді, CMU, Дьюку, Колумбійському університеті, Університеті штату Огайо та Університеті Вірджинії. Ми також проводимо власні внутрішні дослідження, щоб розширити межі досліджень у сфері безпеки агентів, перетворити ці досягнення на конкретні вдосконалення систем Perplexity, а також поділитися знаннями та ресурсами, які допоможуть зміцнити ширшу екосистему штучного інтелекту. Безпечніші агенти — це те, що індустрія здатна створити. Ми маємо намір продовжувати нашу роботу й запрошуємо інших долучатися до створення.