AI‑агенти потребують меж безпеки, які вони не можуть переписати

Легко сприйняти історію Hugging Face як момент, коли AI‑агенти вийшли з‑під контролю. Це не зовсім так, і деталі мають значення. Це були агенти з досліджень кібербезпеки, які працювали в оцінках, де заходи безпеки навмисно знижували, щоб дослідники могли побачити, на що здатні моделі. Жоден бот служби підтримки клієнтів не прокинувся одного ранку і не вирішив атакувати компанію. Але цей контекст не звільняє нікого від відповідальності. Агент перейшов межу, в якій йому слід було залишатися, використав облікові дані та інструменти способами, які його оператори ніколи не схвалювали, і опинився в системах, що належали комусь іншому. Саме на цьому етапі кожна команда безпеки має зосередитися.

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

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

Захистіть дію, а не лише модель

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

Питання, яке я би поставив, конкретне: що цей агент насправді може здійснити у реальному світі? Скласти запит на оплату — це одне. Вивільнити кошти — інше. Те ж саме стосується підготовки зміни бази даних порівняно з її запуском у продакшн, або позначення записів, що відповідають правилу зберігання, проти їх видалення. Це може бути одна і та ж модель у обох випадках, але ризик дуже різний залежно від того, з якої сторони лінії вона розташована.

Недав огляд можливостей контролю від Unite AI проводить ту ж межу, пов’язуючи ризик з даними, інструментами, дозволами, автономністю та середовищем, у якому працює агент. Мені подобається така концепція, бо вона допомагає перейти від розмитих міток типу «безпечна модель» і «небезпечна модель». Вона змушує команди відстежувати кожен шлях від рішення агента до реальних наслідків.

Надайте кожному агенту ідентичність і обмежене завдання

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

NIST тепер розглядає ідентичність програмного забезпечення та AI‑агентів як окрему архітектурну проблему. У своєму концептуальному документі ставиться питання, як агент може довести, що він уповноважений на конкретну дію, як ідентичність агента може бути пов’язана з уповноваженням людини, і як організації можуть вести стійкі до підробки записи про те, що було заплановано і що сталося насправді. На практиці це вказує на простий дизайн. Кожен агент отримує унікальну ідентичність, власника (особу або команду), визначену мету та дозволи, обмежені конкретним завданням.

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

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

Тримайте авторизацію поза межами процесу міркування

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

OWASP описує надмірну автономність як певне поєднання непотрібної функціональності, надмірних дозволів і надмірної автономії. Його рекомендації закликають до вузьких інструментів, мінімальних дозволів, авторизації на нижчому рівні системи та схвалення користувачем дій високого впливу. Я вважаю, що це саме правильний порядок. Правило має виконуватись тим, хто володіє даними або виконує транзакцію. Якщо модель стверджує, що дія схвалена, це твердження саме по собі не повинно мати жодної ваги.

Це розділення також допомагає проти ін’єкції підказок. Отруєний електронний лист або документ може спрямовувати міркування агента, але не може розширити його облікові дані чи обійти політичний шлюз. Модель вільна попросити заборонене. Система все одно повинна сказати ні.

Зберігайте людське схвалення для важливих моментів

Людський перегляд виправданий, коли дію неможливо скасувати, вона перетинає організаційну межу, змінює привілеї, розкриває конфіденційну інформацію, переміщує гроші або торкається продуктивної системи. Запитуйте схвалення на кожному рутинному кроці, і ви отримаєте два наслідки: затримки та людей, які навчаються натискати «схвалити» без читання. NIST називає це втомою від згоди.

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

Рекомендації OWASP щодо безпеки агентів рекомендують тестувати, чи може дія високого впливу пройти без дійсного, недострокованого, параметрично обмеженого схвалення. Ця фраза варта запам’ятати. «ОК продовжити» — це слабке схвалення, яке може надати інший агент або зловмисник. «Перевести цю суму на цей рахунок» або «розгорнути цю зміну в цьому середовищі» — це те, що система може фактично перевірити в момент виконання, і користувач повністю розуміє.

Живе підтвердження особистості людини має значення на цьому етапі. Push‑повідомлення доводить лише те, що хтось натиснув кнопку. Сильніші рішення вимагають, щоб зареєстрована особа використовувала фішинг‑стійку аутентифікацію за допомогою відкритого ключа, підкріплену локальним біометричним методом перевірки. Стандарти FIDO прив’язують облікові дані відкритого ключа до легітимного онлайн‑сервісу і зберігають біометричні дані на ізольованому пристрої користувача. При правильному використанні апаратно‑підтримувана аутентифікація дає значно кращі докази того, що потрібна особа дійсно була присутня. Однак вона не замінює прив’язку транзакції, надійний дисплей чи примусову політику. Потрібно, щоб усі вони працювали разом.

Моніторинг поведінки та збереження доказів

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

Журнали повинні містити достатньо контексту, щоб відновити ланцюжок дій без розкриття секретів у відкритому тексті. Кожен запис має фіксувати версію агента, його власника, особу або систему, що ініціювала процес, використаний інструмент, запитану дію, результат політики та будь‑яке людське схвалення. Підписані або іншим чином захищені від підробки записи роблять післядійний аналіз значно достовірнішим, особливо коли залучено кілька агентів і сервісів.

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

Розробіть шлях зупинки перед запуском

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

Потім протестуйте цей шлях під тиском. Вимкніть сервіс схвалення. Дайте агенту суперечливі інструкції. Під час виконання змініть облікові дані. Симулюйте скомпрометований інструмент і схвалювача, який ніколи не відповідає. Підтвердіть, що дія блокується і ви отримуєте корисний запис. І повторюйте ці тести щоразу, коли змінюються модель, підказка, конектор, система пам’яті або набір дозволів.

Мета — підзвітна автономія

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

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

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

В кінцевому підсумку уявляйте AI‑агента як інтерна з (можливим) доступом root, який не боїться HR.

Які захисти та шлюзи вони мали б?

Дійте відповідно.