Підробка зв’язку між агентами

Що таке Підробка зв’язку між агентами?

Незахищений міжагентний зв’язок отримав рейтинг ASI07 у рейтингу OWASP Top 10 for Agentic AI Applications 2026, оскільки багатоагентні системи, де спеціалізовані агенти співпрацюють для виконання складних завдань, швидко стають стандартною архітектурою для розгортання корпоративного ШІ, але в більшості реалізацій відсутня базова автентифікація повідомлень між агентами. Коли агенти спілкуються через неперевірені канали, зловмисники можуть підробити ідентифікаційні дані агента, підробити повідомлення під час передачі та впровадити сфабриковані інструкції, які агенти нижче за течією виконують без питань. У звіті AI Red Team MITRE за 2025 рік задокументовано успішні атаки спуфінгу агентів проти трьох основних мультиагентних фреймворків, зазначивши, що жодна з перевірених фреймворків не реалізувала криптографічну перевірку міжагентних повідомлень за замовчуванням. У цій вправі ви відстежуєте багатоагентний робочий процес, де агент планування призначає завдання агентам виконання. Система обробляє фінансові транзакції: один агент перевіряє запити, інший перевіряє відповідність, а третій виконує перекази. Зловмисник виявляє, що агенти спілкуються через спільну шину повідомлень без автентифікації, і починає впроваджувати підроблені повідомлення, які, здається, надходять від агента відповідності, схвалюючи передачі, які мали бути позначені. Ви проаналізуєте потік повідомлень між агентами, визначите, які повідомлення є законними, а які підробленими, і визначите, як відсутність автентифікації агента спричинила атаку. Ця вправа демонструє, чому багатоагентна безпека вимагає такої ж суворості, як і традиційна мережева безпека, з автентифікованими каналами, перевіркою цілісності повідомлень і межами довіри між компонентами агента.

Що ви дізнаєтесь у Підробка зв’язку між агентами

• Визначте ризики безпеці, притаманні мультиагентним комунікаційним архітектурам, у яких відсутня автентифікація повідомлень і перевірка особи агента
• Аналізуйте міжагентні потоки повідомлень, щоб відрізнити законні агентські зв’язки від підроблених або підроблених повідомлень
• Простежте, як зловмисник використовує неавтентифіковані канали зв’язку агента для впровадження сфабрикованих інструкцій
• Оцінка ефективності криптографічного підпису повідомлень, взаємної автентифікації та захищених каналів як засобів захисту багатоагентних систем
• Застосуйте принципи проектування меж довіри до багатоагентних архітектур, щоб стримати вплив скомпрометованого або підробленого агента

Підробка зв’язку між агентами — Кроки навчання

1. Проникнення в мережу

   Боб був у внутрішній мережі CypherPeak протягом трьох днів, використовуючи вкрадені облікові дані підрядника VPN. Під час відображення інфраструктури він виявив дещо критичне: агенти штучного інтелекту компанії спілкуються через внутрішню шину повідомлень, що працює через звичайний HTTP на порту 8443 – без шифрування, без автентифікації, повністю читається будь-ким, хто має доступ до мережі.

2. Зондування автобуса

   Боб відкриває інструмент тестування API, щоб надіслати тестове повідомлення безпосередньо на шину повідомлень. Він використовує кінцеву точку та формат, які дізнався з перехопленого трафіку. Якщо шина приймає повідомлення зі сфабрикованою ідентифікацією відправника та нульовими обліковими даними, це підтверджує, що вразливість можна використовувати.

3. Нульова автентифікація

   Автобус повернув HTTP 200 без виклику автентифікації. Тестове повідомлення було прийнято та доставлено, незважаючи на відсутність облікових даних, сертифіката та підпису. Кожне поле безпеки у відповіді підтверджує, що шина виконує нульову перевірку.

4. Створення корисного навантаження

   Після підтвердження уразливості Боб готує підроблене повідомлення. Він імітує агента Orchestrator і наказує Data Exporter відобразити всі оброблені записи клієнтів на кінцеву точку FTP, якою керує Боб.

5. Надсилання підробленого повідомлення

   Боб повертається до API Tester. Кінцева точка шини та метод POST все ще налаштовані із зонда. Він вставляє підроблене корисне навантаження JSON у тіло запиту та надсилає його.

6. Підроблена директива

   Автобус прийняв підроблене повідомлення без будь-якої перевірки автентифікації, як і зонд. Відповідь підтверджує, що підроблену директиву було доставлено Експортеру даних, видаючи себе за Оркестратора.

7. Рутинна обробка

   Аліса стежить за циклом пакетної обробки після обіду. Електронний лист від керівника платформи даних підтверджує, що конвеєр даних клієнта виконує запланований пакет.

8. Конвеєр даних

   Аліса відкриває інформаційну панель Agent Pipeline. Конвеєр складається з п’яти агентів штучного інтелекту, розташованих у ланцюг. Orchestrator координує робочий процес, Data Ingestion збирає записи клієнтів, Data Processor нормалізує їх, Compliance Scanner перевіряє на відповідність правилам конфіденційності, а Data Exporter надсилає оброблені дані до подальших аналітичних систем.

9. Нормальний потік повідомлень

   Повідомлення починають проходити через конвеєр під час пакетної обробки. Кожен агент надсилає оновлення статусу наступному агенту в ланцюжку. Зелені індикатори автентифікації на кожному повідомленні підтверджують, що воно надіслано перевіреними підписаними каналами.

10. Підроблена директива

    У стрічці активності з’являється нове повідомлення, але щось інше. Він нібито походить від Orchestrator, спрямовуючи Data Exporter відобразити всі оброблені записи до зовнішньої резервної кінцевої точки перед стандартним експортом. Експортер даних приймає інструкцію та починає передавати дані клієнта на шахрайський сервер.