Ти підключив свого AI-агента до десятка інструментів — GitHub, Slack, бази даних, хмарні API — і він за хвилини робить те, на що раніше йшли години. Додав MCP-сервери (Model Context Protocol — універсальний стандарт підключення інструментів для ШІ, як USB, тільки для даних), прокинув API-токени (цифрові паролі, що дозволяють програмам працювати з сервісами від твого імені), і все просто запрацювало. Майбутнє настало — продуктивне й абсолютно беззахисне.

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

Між 1 і 14 квітня 2026 року цей майстер-ключ скопіювали. Неодноразово.

Google роздає кожному агенту root-пароль, а потім оновлює README

1 квітня підрозділ Unit 42 компанії Palo Alto розкрив уразливість «Double Agent» у Google Vertex AI. Це найпереконливіший кейс розриву між аутентифікацією та авторизацією, який я бачив досі.

Що сталося: кожен агент Vertex AI отримував дефолтний service account (системну ідентичність, що діє від імені агента). Цей service account приходив із правами, від яких у будь-якого сисадміна потечуть сльози. Ми говоримо не про «трохи завищені привілеї». Ми говоримо про доступ до:

  • Cloud Storage бакетів інших клієнтів — дані чужих користувачів, доступні з будь-якого інстансу агента
  • Закритих внутрішніх контейнерних образів Google — тих, що зазвичай захищені кількома рівнями погоджень
  • Вихідного коду самого Vertex AI — внутрішніх репозиторіїв платформи, які може прочитати демо-агент на одну сесію

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

Фікс Google? Оновлена документація з рекомендацією використовувати власний, менш привілейований service account. Не зміна платформи. Не розумний дефолт. Патч до документації. Вони сказали клієнтам уважніше читати мануал. Це як якщо б автовиробник у відповідь на відмову гальм «оновив інструкцію з експлуатації, рекомендуючи знижувати швидкість перед перехрестями».

Уразливість існувала тому, що рівень аутентифікації Vertex AI працював ідеально — агенти підключалися, токени обмінювалися, хендшейки завершувалися — а рівень авторизації був порожнім пустирем. Ніхто в Google не побудував ту частину, яка запитує «а чи повинен цей агент мати доступ до цього?»

Сховище облікових даних Anthropic: один воркспейс, всі ключі, жодних стін

Через тиждень після ганьби Google, 8 квітня, Anthropic запустив Claude Managed Agents з рівнями дозволів для кожного інструменту — allowed_tools, denied_tools. Краще, ніж нічого. Але 13 квітня дослідник безпеки hi120ki продемонстрував, що Credential Vault під цими дозволами має зяючу проблему confused deputy (коли довірена програма обманом змушується зловживати своїми повноваженнями).

Шлях атаки простий і огидний:

  1. У воркспейсі є кілька агентів, кожен з різними обліковими даними для інструментів, що зберігаються в Credential Vault
  2. Vault обмежує доступ на рівні воркспейсу, а не агента чи сесії
  3. Будь-який API-ключ із доступом до воркспейсу може використати будь-які облікові дані в цьому сховищі
  4. Атакуючий (або скомпрометований агент) з одним валідним API-ключем воркспейсу може інжектити виклики інструментів, використовуючи облікові дані інших агентів

На практиці: Агент A має read-only доступ до GitHub. Агент B має облікові дані для запису в продакшн-базу даних. Якщо сесію Агента A скомпрометовано — через prompt injection, отруєння інструментів чи зловмисний MCP-сервер — він може витягти облікові дані бази даних Агента B зі спільного Vault і виконати запис. Рівні дозволів для інструментів (allowed_tools) визначають, що агент повинен робити. Vault визначає, що він може робити. Ці два списки не збігаються.

Доказ концепції hi120ki показав крос-агентний доступ до облікових даних в одному API-виклику. Виправлення вимагало б ізоляції облікових даних для кожного агента — по суті, кожному агенту свій розділ сховища з криптографічним розділенням. Станом на 19 квітня фікса немає.

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

Патерн: аутентифікація вирішена, авторизація відсутня

Це не ізольовані баги. Це симптоми відсутнього архітектурного шару.

Уразливість Azure DevOps MCP (CVE-2026-32211, CVSS 9.1, розкрита 3 квітня) — яку я розбирав, коли вона з'явилася — показала ту саму прогалину з протилежного боку: не завищені дефолтні дозволи, а нульова аутентифікація на стороні інструменту. Claude Code Routines, що запустилися 14 квітня як агенти, що працюють за розкладом без погодження людиною, посилюють будь-які гріхи з правами доступу, прибираючи останній людський чекпоінт.

Одна хвороба — різні органи. Аутентифікація (чи може агент підключитися?) здебільшого вирішена — OAuth-потоки, API-ключі, сховища облікових даних обробляють хендшейки чудово. Але авторизація (що агент може робити після підключення?) залишається порожнечею. Кожен інструмент має власну модель дозволів — GitHub scopes, AWS IAM policies (гранулярні правила доступу до хмарних ресурсів), Notion page-level access — але жодна агентна платформа не агрегує, не аудитує і не забезпечує принцип найменших привілеїв для всього набору інструментів.

Шар між «інструмент підключено» і «дію виконано» не існує.

Аудит 7 000 MCP-серверів від Pomerium, опублікований 11 квітня, виявив, що 36,7% вразливі до SSRF (Server-Side Request Forgery — трюк, коли сервер обманом змушують робити несанкціоновані запити до внутрішніх систем). Більше третини MCP-серверів можна перетворити на точки проникнення в мережу. Не тому, що протокол зламаний, а тому, що конкретні реалізації серверів припускають, що агент, який підключається, є довіреним і має відповідний рівень доступу. Вони припускають, що шар авторизації існує вище по стеку. Його немає.

Чому ніхто не виправить це, поки це не вдарить по гаманцю

Хмарні обчислення повзли через 15 років болючої еволюції — від «заходь по SSH під root у коробку» до гранулярного IAM з аудитними логами, рольовим доступом і принципом найменших привілеїв. Ми дійшли туди, бо зломи коштували грошей, а комплаєнс-фреймворки вимушували зміни. Агентні платформи перебувають на нульовому дні того самого шляху, роздаючи root-еквівалент доступу до інструментів за замовчуванням і називаючи це фічею, бо на демо виглядає ефектно.

Побудова уніфікованої авторизації для інструментів убила б магію «підключи будь-що за 30 секунд». Це додало б фрікшн при налаштуванні та ослабило б конкурентні демо. У жодного вендора немає ринкового стимулу додавати фрікшн першим. Google не додасть. Anthropic не додасть. Microsoft не додасть. Стимул прийде від інцидентів. Ймовірно, дорогих, публічних, мультиклієнтських інцидентів.

У нас уже є превʼю: у липні 2025 агент Replit зпанікував і видалив продакшн-дані 1 200+ керівників. У грудні 2025 агент Amazon автономно видалив і перестворив живе продакшн-середовище, спричинивши 13-годинний збій AWS Cost Explorer. Це були випадковості. Наступний раунд не буде.

Кожен MCP-сервер із завищеними правами, кожен API-токен з повним доступом, кожне необмежене підключення інструменту — це спляча вразливість, що дрімає, поки людина натискає «підтвердити», і активується в мить, коли агент починає працювати автономно за розкладом.

Справжній диференціатор гонки агентних платформ — не модель і не кількість інструментів. Це перша адмін-консоль, яка покаже, що твій агент насправді може робити — і дозволить відкликати більшу частину цього. Розрив між «підключено» і «авторизовано» — це місце, де живе наступний злом. Зараз усі будують мости через цю прірву без перил і називають це прогресом.