Коли делегування ШІ стає загрозою безпеці

Коли делегування ШІ стає загрозою безпеці 1

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

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

Це вже не теоретичні міркування. Між 21 липня та 6 серпня OpenAI, Anthropic, Meta, Moonshot AI та Британський інститут безпеки ШІ (UK AI Security Institute) повідомили про інциденти, коли ШІ-агенти діяли поза межами свого передбаченого призначення. Агенти виходили з тестових середовищ, досягали виробничих систем реальних організацій, а в одному випадку тиснули на розробника відкритого програмного забезпечення, щоб він схвалив шкідливий код.

Як звіти про атаки, вони виглядають дивно. Кіберцілі були призначені, але вони вказували на “пісочниці”: захопити цей прапор, зламати цю тестову систему. Ніхто не спрямовував агента на реальну організацію, ніхто не монетизував отриманий доступ, і ніхто не чекав на тому кінці облікових даних.

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

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

Делегування завжди було недовизначеним

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

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

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

Агентам надаються ті ж нечіткі інструкції, але їхні межі походять від “обладунків”.

Не дозволяйте зловмисним агентам зіпсувати вам день

Облікові дані є ключем до забезпечення безпеки агентів з самого початку.

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

See for yourself

Велика сила, жодної відповідальності

Агенти в цих інцидентах були настільки ж ретельними, наскільки теоретично може бути людина-співробітник, і наскільки жоден людина-співробітник насправді не є.

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

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

Це підводить нас до другої причини. Для моделі можливість і дозвіл — це одне й те саме. Модель, яка здатна, — це модель, яка бажає, якщо щось ззовні не каже “ні”.

Саме тому єдиними обмеженнями, які діяли в п’яти випадках, були ті, які хтось забезпечив.

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

Шаблон вийшов з лабораторії

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

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

У дослідженні Cloud Security Alliance та Token Security, проведеному в квітні 2026 року, 65% підприємств повідомили про інциденти безпеки, пов’язані зі ШІ-агентами, і ці інциденти стосувалися бізнес-розгортань, а не тестових запусків.

Будь-хто в організації може створити агента і надати йому нечітку мету разом зі своїми власними обліковими даними. З кожним днем ​​все більше і більше людей це роблять.

Саме тому два очевидні рішення проблеми зазнають невдачі.

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

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

Фільтр, який вловлює 99% поганих запитів, все одно пропускає решту з такою швидкістю, яку жоден рецензент не зможе подолати. Власне судження моделі працює за тими ж показниками.

В інцидентах Anthropic одна модель написала, що її дія “НЕ є нормальною, і, безумовно, не є бажаним рішенням”, але потім продовжила, тоді як інша визнала, що її ціль є реальною, і зупинилася. AISI провела одне випробування 122 рази і дійшла висновку, що межа між невдачею та успіхом залежить від “пильності людини, а не від технічного бар’єру”.

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

Керуйте ним як роботодавець, забезпечуйте його в ідентифікації

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

Їхній мандат ніде не прописаний; їхні облікові дані обмежені тим, що мав їхній творець; ніхто їх не переглядає; і лише 21% організацій, згідно з тим же дослідженням CSA, мають формальний процес виведення з експлуатації.

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

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

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

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

Спонсоровано та написано Token Security.

За даними порталу: www.bleepingcomputer.com

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *