Коли ШІ-агенту необхідно увійти до вашої CRM-системи, витягти записи з вашої бази даних і відправити електронний лист від вашого імені, чию ідентичність він використовує? І що станеться, коли ніхто не знатиме відповіді? Алекс Стемос, головний продукт-директор Corridor, та Ненсі Ванг, технічний директор 1Password, долучилися до серії VB AI Impact Salon, щоб заглибитися в нові виклики фреймворків ідентифікації, які супроводжують переваги агентного ШІ.
"На високому рівні, питання не лише в тому, кому належить цей агент або яка організація ним володіє, а й під якою юрисдикцією цей агент діє, що потім трансформується в авторизацію та доступ", – зазначила Ванг.
Як 1Password опинився в центрі проблеми ідентифікації агентів
Ванг розповіла про шлях 1Password до цієї сфери через історію власного продукту. Компанія починалася як менеджер паролів для споживачів, а її корпоративний сегмент зростав органічно, оскільки співробітники приносили на робочі місця інструменти, яким вони вже довіряли.
"Як тільки ці люди звикли до інтерфейсу та справді оцінили стандарти безпеки та конфіденційності, які ми гарантуємо нашим клієнтам, вони почали використовувати його в корпоративному середовищі", – сказала вона. Аналогічна динаміка відбувається зараз і з ШІ. "Агенти також мають секрети, або паролі, як і люди".
Всередині компанії 1Password долає ту саму напругу, яку допомагає керувати своїм клієнтам: як дозволити інженерам швидко працювати, не створюючи при цьому безладу в безпеці. Ванг зазначила, що компанія активно відстежує співвідношення інцидентів до коду, згенерованого ШІ, коли інженери використовують такі інструменти, як Claude Code та Cursor. "Це показник, який ми уважно відстежуємо, щоб переконатися, що ми генеруємо якісний код".
Як розробники наражаються на серйозні ризики безпеки
Стемос зазначив, що однією з найпоширеніших практик, які спостерігає Corridor, є вставлення розробниками облікових даних безпосередньо в запити (prompts), що становить величезний ризик безпеки. Corridor позначає це і повертає розробника до належного керування секретними даними.
"Стандартна практика – це просто взяти API-ключ або ім’я користувача та пароль і вставити їх у запит", – сказав він. "Ми знаходимо це постійно, тому що ми інтегровані та отримуємо доступ до запитів".
Ванг описала підхід 1Password як роботу на виході: сканування коду під час його написання та збереження будь-яких облікових даних у відкритому вигляді перед їх персистентним зберіганням. Тенденція до використання методу копіювання-вставки для доступу до систем безпосередньо впливає на вибір дизайну 1Password, який полягає в уникненні інструментів безпеки, що створюють перешкоди.
"Якщо ним занадто важко користуватися, запустити, почати роботу, він не буде безпечним, тому що, відверто кажучи, люди просто обійдуть його і не будуть використовувати", – сказала вона.
Чому ви не можете ставитися до кодувального агента як до традиційного сканера безпеки
Ще однією проблемою при створенні зворотного зв’язку між агентами безпеки та моделями кодування є хибні спрацьовування (false positives), до яких схильні дуже дружні та поступливі великі мовні моделі. На жаль, ці хибні спрацьовування від сканерів безпеки можуть зірвати всю сесію кодування.
"Якщо ви скажете йому, що це недолік, він відповість: Так, сер, це повний недолік!" – сказав Стемос. Але, додав він, "Ви не можете помилитися з хибним спрацьовуванням, тому що якщо ви скажете йому це, а ви помилилися, ви повністю зруйнуєте його здатність писати правильний код".
Цей компроміс між точністю та повнотою структурно відрізняється від того, що оптимізують традиційні інструменти статичного аналізу, і вимагав значних інженерних зусиль для досягнення необхідної затримки, яка становить кілька сотень мілісекунд на одне сканування.
Автентифікація – це просто, але авторизація – ось де виникають труднощі
"Агент, як правило, має значно більше доступу, ніж будь-яке інше програмне забезпечення у вашому середовищі", – зазначив Спірос Ксантос, засновник і генеральний директор Resolve AI, на попередній сесії заходу. "Тому зрозуміло, чому команди з безпеки дуже стурбовані цим. Тому що, якщо цей вектор атаки буде використаний, він може призвести як до витоку даних, так і, що ще гірше, можливо, у вас є щось, що може діяти від імені зловмисника".
Отже, як надати автономним агентам обмежені, аудитовані, часові ідентичності? Ванг вказала на SPIFFE та SPIRE, стандарти ідентифікації робочих навантажень, розроблені для контейнеризованих середовищ, як на кандидатів, що тестуються в агентних контекстах. Але вона визнала, що вони не ідеально підходять.
"Ми ніби намагаємося вставити квадратний кілок у круглий отвір", – сказала вона.
Але автентифікація – це лише половина справи. Після того, як агент отримає облікові дані, що йому насправді дозволено робити? Тут слід застосовувати принцип найменших привілеїв до завдань, а не до ролей.
"Ви б не хотіли давати людині картку-ключ до всього будівлі, яка дає доступ до кожної кімнати", – пояснила вона. "Ви також не хочете давати агенту ключі від королівства, API-ключ для виконання всього, що йому потрібно, назавжди. Це має бути обмежено в часі, а також прив’язано до завдання, яке ви хочете, щоб цей агент виконав".
У корпоративних середовищах буде недостатньо просто надати обмежений доступ; організації повинні будуть знати, який агент діяв, під якою юрисдикцією та які облікові дані використовувалися.
Стемос вказав на розширення OIDC як на поточного лідера в обговореннях стандартів, відкидаючи при цьому безліч пропрієтарних рішень.
"Існує 50 стартапів, які вірять, що їхнє пропрієтарне запатентоване рішення буде переможцем", – сказав він. "Жодне з них, до речі, не переможе, тому я б не рекомендував".
При мільярді користувачів граничні випадки – це вже не граничні випадки
На стороні споживачів Стемос прогнозує, що проблема ідентифікації консолідується навколо невеликої кількості довірених постачальників, найімовірніше, платформ, які вже забезпечують автентифікацію споживачів. Спираючись на свій досвід роботи головним фахівцем з безпеки (CISO) у Facebook, де команда щодня боролася приблизно з 700 000 випадками захоплення облікових записів, він переосмислив, що таке масштаб для концепції граничного випадку.
"Коли ви є CISO компанії з мільярдом користувачів, граничний випадок – це те, що означає реальну людську шкоду", – пояснив він. "І тому ідентифікація, для звичайних людей, для агентів, надалі буде величезною проблемою".
Зрештою, виклики, з якими стикаються технічні директори на стороні агентів, виникають через неповні стандарти ідентифікації агентів, імпровізовані інструменти та розгортання агентів підприємствами швидше, ніж фреймворки, призначені для їхнього управління, можуть бути написані. Шлях вперед вимагає побудови інфраструктури ідентифікації з нуля, що базується на реальній суті агентів, а не на ретрофіті того, що було створено для людей, які їх створили.
Як захиститися (Порада ІТ-Блогу): Ніколи не вставляйте облікові дані (паролі, API-ключі, токени) безпосередньо в запити до ШІ-моделей. Використовуйте спеціалізовані сервіси керування секретами або безпечні сховища для доступу до конфіденційної інформації.
Дізнатися більше на: venturebeat.com