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

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

Багатоагентні системи переміщують роботу через шину повідомлень, і в більшості розгортань ці повідомлення не підписуються та не автентифікуються. Будь-хто, хто може дістатися до автобуса, може прочитати те, що говорять агенти, і написати повідомлення, схоже на повідомлення оркестранта, і наступні агенти підкоряться. Це ASI07 у топ-10 OWASP для програм Agentic AI. Ви перевірите шину відкритого тексту, підробите директиву, яка перенаправлятиме записи клієнтів на зовнішній сервер, потім виберете підробку зі справжнього трафіку та ввімкнете автентифікацію повідомлень.

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

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

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

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 відобразити всі оброблені записи до зовнішньої резервної кінцевої точки перед стандартним експортом. Експортер даних приймає інструкцію та починає передавати дані клієнта на шахрайський сервер.