Авторизація протоколу A2A: чому специфікація є поверхневою та де криються вразливості
Протокол A2A (Agent2Agent) стає стандартом для взаємодії ШІ-агентів. Google анонсувала його у 2025 році, а зараз ним керує Linux Foundation.
Коли я переглянув розділ автентифікації у специфікації, я майже нічого там не знайшов. Вона не визначає новий механізм автентифікації. Вона просто пропонує використовувати існуючі стандарти, такі як OAuth2, OpenID Connect або mTLS.
Така поверхневість є навмисною. A2A визначає каркас, але делегує наповнення іншим стандартам. Це створює вразливості, якщо не бути обережним.
Як працює A2A A2A — це протокол, за допомогою якого один агент передає завдання іншому. Він використовує JSON-RPC через HTTP.
• Клієнтський агент: агент, який надсилає запит. • Віддалений агент: агент, який отримує завдання. • Картка агента (Agent Card): JSON-файл, у якому віддалений агент перелічує свої можливості та вимоги до автентифікації.
Картка агента є найважливішою частиною. Клієнт спочатку зчитує цю картку, щоб дізнатися, як пройти автентифікацію, перш ніж надсилати запит.
Вразливості A2A залишає кілька критично важливих завдань на розсуд розробника. Якщо ви не опрацюєте їх, ваші агенти будуть під загрозою.
- Підміна картки: Підписання картки агента є необов'язковим (MAY). Якщо ви не підпишете її, зловмисник зможе перенаправити вашого агента на шкідливий сервер.
- Replay-атаки: A2A не має способу прив'язки токенів до конкретного клієнта. Якщо хтось викраде bearer-токен, він зможе видати себе за вашого агента.
- Ескалація привілеїв: Авторизація залишена зовнішній інфраструктурі. Якщо ви не впровадите перевірку прав для кожного окремого навику (per-skill checks), агент із доступом «тільки для читання» може отримати доступ на «запис».
- Ланцюжок ідентичності (Identity Chaining): A2A не визначає, як ідентичність користувача передається через ланцюжок агентів.
Як побудувати це безпечно Не покладайтеся лише на специфікацію. Ви повинні перетворити необов'язкові правила на обов'язкові.
• Завжди підписуйте свої картки агентів. Використовуйте JWS та JCS. • Використовуйте mTLS для шляхів взаємодії агентів. Це гарантує, що викрадення токена не буде достатньо для компрометації вашої системи. • Впроваджуйте авторизацію на рівні окремих навичок (per-skill) на вашому API Gateway. • Використовуйте токени з обмеженням відправника (наприклад, DPoP), щоб запобігти replay-атакам.
A2A — це лише «сантехніка». Безпека залежить від «води», яку ви через неї пропускаєте. Використовуйте перевірені стандарти, такі як SPIFFE або Identity Chaining, щоб заповнити прогалини.
Optional learning community: https://t.me/GyaanSetuAi