Швидке впровадження ІІ-агентів у бізнес-процеси оголює критичний недолік: відсутність точної системи для управління їх ідентифікацією та правами доступу. У міру того як ці агенти отримують можливість входити в системи, отримувати дані і виконувати дії від імені компаній, питання про те, хто несе відповідальність – і як.
Це не теоретична проблема. Експерти, такі як Алекс Стамос (Corridor) та Ненсі Ван (1Password), попереджають, що розробники вже роблять небезпечні помилки, наприклад, безпосередньо вставляють облікові дані у запити до ІІ. Це обходить протоколи безпеки та створює величезну вразливість.
Проблема: У Агентів Теж Є Секрети
Йдеться не лише про запобігання несанкціонованому доступу; мова йде про відповідальність. На відміну від користувачів-людей, ІІ-агенти за своєю суттю не належать жодній організації чи конкретній особі. Вони діють під авторитетом, який визначає, що їм дозволено робити, але відстеження цього авторитету виявляється скрутним. Як пояснює Ван, компанії спостерігають знайому закономірність: співробітники впроваджують такі інструменти як ІІ-помічники для кодування (Claude Code, Cursor), а потім приносять їх до корпорації, повторюючи раннє впровадження менеджерів паролів, таких як 1Password.
Проблема у тому, що з агентів є облікові дані; проблема в тому, що існуюча безпекова інфраструктура не призначена для них.
Чому Існуючі Рішення Не Працюють
Традиційні моделі безпеки фокусуються на аутентифікації (перевірці особи), але мають труднощі з авторизацією (наданням відповідних прав доступу). Надання ІІ-агенту повного доступу до системи еквівалентно передачі людині ключа від усієї будівлі – набагато більше, ніж необхідно для виконання будь-якого окремого завдання.
Ця невідповідність особливо небезпечна, тому що LLM схильні до помилкових спрацьовувань. Виявлення легітимного коду як шкідливого сканером безпеки може зірвати всю сесію розробки, роблячи точність вирішальною. Традиційні інструменти статичного аналізу не оптимізовані такого рівня точності.
Шлях Вперед: Стандарти Ідентифікації Робочих Навантажень
Галузь вивчає рішення, такі як SPIFFE та SPIRE, стандарти, спочатку розроблені для контейнерних середовищ, але їхня адаптація недосконала. Основний принцип полягає в наданні обмежених, перевіряних, обмежених за часом ідентифікаторів. Як людині слід мати доступ тільки до певних приміщень у будівлі, так і ІІ-агенту слід надавати облікові дані тільки для поточного завдання, яке закінчується після її завершення.
Компаніям доведеться відстежувати, який агент діяв, під яким авторитетом і з якими обліковими даними. Це потребує створення нової інфраструктури з нуля, а не переобладнання орієнтованих на людину моделей безпеки.
Проблема Масштабу: Мільярди Користувачів Змінюють Все
У великих масштабах навіть винятки стають реальними загрозами. Стамос, спираючись на свій досвід як директор з інформаційної безпеки Facebook, зазначає, що боротьба з 700 000 зламів облікових записів на день змінює уявлення про ризик. Управління ідентифікацією як для людей, так і для ІІ-агентів буде «величезною проблемою», яка потребує консолідації навколо довірених постачальників.
Зрештою, нинішній поспіх із впровадженням ІІ-агентів випереджає розробку належних механізмів управління. Рішення полягає не в пропрієтарних запатентованих інструментах (Стамос відкидає їх прямо), а скоріше у відкритих стандартах, таких як розширення OIDC, які надають пріоритет безпеки без шкоди для зручності використання. Майбутнє корпоративного ІІ залежить від вирішення цієї кризи ідентичності до того, як вона призведе до широкомасштабних порушень та незворотних збитків.
