Guardrails для корпоративних ШІ-агентів
Більшість порад щодо guardrails для ШІ звучать як рекламні заклики. Вони зосереджені на вигадливих діаграмах та чек-листах.
Справжня безпека в продакшені менш гламурна. Вона базується на речах, які існували задовго до появи LLM.
Я провів два роки, розробляючи ШІ-агентів для компанії зі списку Fortune 100. Ці агенти обробляють збої CI/CD, інциденти Kubernetes та документацію з інфраструктури.
Ось багаторівневий стек, який ми використовуємо для їхньої безпеки.
Ідентифікація на межі агента. Кожен агент використовує workload identity. Він ніколи не використовує спільні облікові дані. Область дії IAM — це ваша верхня межа безпеки. Якщо агенту не потрібен доступ до бази даних, роль IAM не повинна його мати. Це ваш найважливіший засіб контролю.
Білі списки інструментів (Tool allow-lists). Платформа вирішує, які інструменти доступні агенту. Агент для пошуку коду не повинен мати інструмент для роботи з електронною поштою. Для цього ми використовуємо статичні конфігурації. Ми ніколи не використовуємо динамічну реєстрацію інструментів.
Контроль мережевого виходу (Network egress controls). Агенти звертаються лише до дозволених кінцевих точок. Ми використовуємо DNS-фільтрацію та egress-проксі. Це запобігає спробам галюцинацій моделі перейти за неправильними URL-адресами.
Ізоляція секретів. Агенти ніколи не бачать сирі секрети. Ми використовуємо короткострокові сесійні токени, що впроваджуються під час викликів інструментів. Ніколи не вставляйте секрети в промпт. Будь-що в промпті може бути залогуване або відтворене.
Повні аудиторські журнали. Ви повинні логувати кожен виклик моделі та кожен виклик інструменту. Це включає вхідні та вихідні дані, аргументи інструментів та ідентифікацію користувача. Це необхідно, щоб зрозуміти, що пішло не так під час інциденту.
Підтвердження людиною. Для будь-якої дії, що змінює систему обліку (system of record), платформа має зупинитися. Людина повинна схвалити дію. Це ваша страховка.
Уникайте цих поширених помилок:
Інструкції на рівні промптів. Наказ моделі «ніколи не роби X» — це не безпека. Користувач може обманути модель. Перенесіть контроль на рівень IAM або інструментів.
Загальні фільтри PII. Вони мають високий рівень помилок. Краще обмежити доступ до даних через IAM, щоб агент ніколи не бачив конфіденційної інформації.
Моделі-guardrails. Використання другої LLM для оцінки першої додає затримку (latency). Це не справжній засіб контролю безпеки. Це просто ансамбль моделей.
Уроки, які я засвоїв на власному гіркому досвіді:
Виправляйте IAM раніше, ніж промпти. Я витрачав час на налаштування промптів, хоча мав би зосередитися на посиленні ролей IAM. Переносьте засоби контролю якомога нижче по стеку.
Створюйте розширений аудиторський слід. Фіксації лише запиту (prompt) та відповіді недостатньо. Вам потрібні проміжні виклики інструментів та їхні аргументи. Логування на ранніх етапах коштує дешево, але виправлення помилок пізніше обійдеться дорого.
Обмежуйте взаємодію агентів. У мультиагентних системах встановлюйте жорстке обмеження на кількість викликів між агентами. Це запобігає каскадним збоям.
Безпека ШІ при масштабуванні — це не проблема моделі. Це проблема платформи. Ставтеся до своїх агентів з такою ж операційною дисципліною, як до будь-якої іншої продуктивної системи.
Додаткова спільнота для навчання: https://t.me/GyaanSetuAi