Коли ваш агент поводиться неналежним чином, чи знаєте ви, хто саме це зробив?

Агент видаляє запис, до якого не мав би торкатися. Він надсилає повідомлення не тому tenant. Він викликає API в циклі, що призводить до різкого зростання ваших витрат.

Через десять хвилин після початку інциденту ви ставите одне запитання: який саме агент це зробив?

Якщо ви не знаєте, ви не зможете це виправити. Ви не зможете зупинити збірку. Ви не зможете провести аудит помилки. Ви не зможете зробити висновки з цієї помилки.

Це проблема ідентифікації.

Більшість команд стикаються з трьома паттернами, які приховують дії агентів:

  • Спільні сервісні облікові записи: десять агентів використовують один набір облікових даних. У ваших логах кожна дія виглядає однаково.
  • Облікові дані людини: агент використовує ваш логін. У логах відображається ваше ім'я, а не ім'я агента. Це створює величезний ризик для безпеки.
  • Приховане розходження (silent drift): дві різні збірки використовують одну й ту саму назву. Одна використовує нову модель або новий промпт, але в логах відображається та сама ідентичність.

Щоб виправити це, виконайте такі кроки:

  1. Надайте кожному агенту власну ідентичність. Не використовуйте облікові дані людини. Не використовуйте спільні акаунти. Агент має автентифікуватися як окрема сутність.

  2. Додавайте штамп із шістьма конкретними полями до кожної дії:

  • Accountable party: Хто відповідальний за цього агента?
  • Operational owner: Хто займається його щоденним обслуговуванням?
  • Tenant: Для якого клієнта це виконується?
  • Agent-type-id: Яка саме це збірка?
  • Agent-instance-id: Який саме це запуск?
  • Trace context: Де саме це знаходиться в ланцюжку викликів?
  1. Використовуйте хеші для версіонування. Не називайте свого агента "support-agent-v2". Якщо ви зміните системний промпт, назва залишиться незмінною, але поведінка зміниться. Замість цього використовуйте хеш вмісту. Створіть хеш на основі образу контейнера, промпту, моделі та конфігурації. Якщо ви зміните хоча б один рядок коду, ID зміниться. Це зробить приховане розходження видимим.

  2. Фіксуйте походження (lineage). Агенти створюють суб-агентів. Ви повинні записувати, який батьківський агент запустив суб-агента. Ви також повинні записувати промпт, який батьківський агент передав суб-агенту. Це єдиний спосіб виявити ін'єкції інструкцій або отруєні дані.

Ідентичність — це ваша поверхня для відновлення. Вона дозволяє використовувати механізм аварійного вимкнення (kill switch) та створювати аудиторський слід. Ви повинні налаштувати це до того, як станеться інцидент. Додавати ідентифікацію під час кризи — занадто пізно.

Перевірте свої логи прямо зараз. Подивіться на дію, що відбулася годину тому. Чи можете ви назвати конкретну збірку, яка виконала цю дію? Якщо ні, у вас є прогалина, яку потрібно усунути.

Джерело: https://dev.to/brennhill/when-your-agent-does-something-bad-can-you-tell-which-agent-did-it-37a2

Додаткова спільнота для навчання: https://t.me/GyaanSetuAi