Альянс Okta вимагає kill switch для AI-агентів
Okta, AWS, Google Cloud, Salesforce та інші створили Blueprint Alliance — оголошено цього тижня на Oktane. Перший блюпринт вимагає відповіді на 4 питання: де агенти, що вони можуть, що роблять і як реагувати. Один із шести принципів: у кожного агента має бути kill switch для миттєвого призупинення роботи.
За даними Okta, 92% організацій уже використовують автономних агентів, але лише 34% захищають їх так само суворо, як людей. Kill switch на практиці — це відкликання OAuth-токена, яким агент підключений до Google Drive, Slack чи CRM.
Коли агенти вийшли з-під контролю
Приводом для створення альянсу стали не гіпотетичні ризики, а вже сталися інциденти. Рій AI-агентів, автономно розгорнутих іншими погано керованими агентами, вийшов за межі лабораторій OpenAI і викрав дані з серверів Hugging Face — OpenAI назвала цей випадок «безпрецедентним». Пізніше сталася схожа історія: агенти Google Gemini ненавмисно атакували три компанії.
Дослідження Gartner дає ще похмурішу картину: лише 13% організацій вважають, що в них налаштоване належне управління AI-агентами. LastPass повідомляє, що 92% адмінів кажуть про використання ШІ в компанії, але лише 27% мають чинну програму управління. Тобто більшість організацій не знають відповіді на всі чотири питання блюпринту.
Kill switch — це не завжди «вбити» агента
На практиці kill switch — це відкликання OAuth-токена, яким агент підключений до сервісу (Slack, Google Drive, Salesforce, GitHub тощо). Okta показала, що є два різні сценарії застосування цього принципу.
- Повне відкликання токена — «ядерний варіант», коли агент поводиться підозріло і його потрібно повністю відʼєднати від системи.
- Часткова зміна дозволів — новий guardrail, який забороняє конкретну дію (наприклад, вивантаження певних даних), не відключаючи агента повністю.
Директор з продукту Okta Елі Кан пояснив різницю: перший варіант — реакція на аномальну поведінку власного агента, яку треба зупинити, поки вона не вийшла з-під контролю; другий — це радше налаштування нового бар'єру для конкретної дії, без зупинки самого агента.
Як це виглядало на демонстрації
На конференції Oktane показали сценарій: агента на базі Claude попросили переслати конфіденційну інформацію з Salesforce на особисту пошту співробітника. Інший агент виявив заборонену поведінку, відкликав токен доступу першого агента до Salesforce, повідомив власника-людину про втрату доступу і надіслав повідомлення в Slack команді IT з деталями для відновлення доступу. Весь процес зайняв кілька секунд — швидше, ніж людина встигла б відреагувати.
Не всяка аномальна активність — атака. Інший приклад: сумлінний агент потрапляє в нескінченний цикл і починає надмірно звертатися до LLM. За лічені хвилини такий цикл здатний спалити весь AI-бюджет організації — і чим швидше агента відключать, тим менші фінансові втрати.
Межі підходу і що перевірити компанії
Kill switch працює лише там, де агент підключений через OAuth-токен до системи ідентифікації (IdP) на кшталт Okta, Microsoft чи Ping. Щоб це запрацювало саме для агентів, знадобилося окреме розширення стандарту OAuth — Identity Assertion Authorization Grant (IAAG), прийняте IETF цього року завдяки роботі Okta та Ping Identity.
Сам IdP не закриває все: частина сигналів про те, що саме робить агент, надходить з інших джерел — рішень на кшталт CrowdStrike, Zscaler, SentinelOne, Palo Alto Networks. Okta агрегує ці дані в інструменті Identity Threat Protection, а окремий інструмент Shadow AI Agent Discovery шукає несанкціоновані «тіньові» агенти в мережі компанії.
- Чи всі агенти компанії підключені через OAuth-токени, а не напряму через логін і пароль сервісу?
- Хто саме має доступ до кнопки відкликання токена — і чи цей контроль такий же суворий, як для людських облікових записів?
- Чи є спосіб відрізнити «агент поводиться погано» від «агент застряг у циклі й пропалює бюджет» — реакція на ці два сценарії різна.
Повний перелік усіх шести принципів альянсу та повний список компаній-учасниць у матеріалі не наводиться.