Ваш лог не може зафіксувати те, чого не було

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

Це легкі збої, оскільки вони залишають слід.

Справжня небезпека — це пропуск. Пропуск — це коли нічого не відбувається.

У append-only логах відсутність виглядає однаково у трьох випадках:

  • Це не відбулося.
  • Це ще не відбулося.
  • Це відбулося, але не було записано.

Лог нічого не показує. Аудит-запит нічого не повертає. Мовчання стає згодою.

Ви можете виправити це за допомогою трьох правил проектування:

  1. Зробіть так, щоб мовчання мало термін дії Якщо агент виконує дію, рецензент має її підтвердити. Відсутність підпису — це діра у вашій безпеці. Не дозволяйте статусу pending залишатися таким назавжди. Встановіть дедлайн. Якщо дедлайн минає, система повинна записати термінальний стан, наприклад REVIEW_EXPIRED. Це перетворює порожнє місце на помилку, яку можна знайти через пошук.

  2. Вимагайте цитування для тверджень Агенти часто використовують звичайну мову для опису світу. Агент може сказати: «файл був порожнім». Якщо немає результату роботи інструменту, який би це підтвердив, таке твердження є небезпечним.

Якщо твердження впливає на майбутню дію, воно повинно містити observation ID. Не намагайтеся вгадати, чи каже агент правду. Просто перевірте, чи посилається твердження на реальне джерело даних. Твердження без цитування — це некоректне повідомлення.

  1. Використовуйте розділення на дві події для дій Коли агент починає завдання, наприклад, надсилання електронного листа, він може вийти з ладу до того, як запише результат. Це створює прогалину. Чи було надіслано лист? Чи варто спробувати ще раз?

Використовуйте такий алгоритм:

  • Додайте подію INTENT з унікальним ключем.
  • Виконайте дію.
  • Додайте подію OUTCOME.

Тепер ви можете бачити проміжний стан. Якщо у вас є INTENT, але немає OUTCOME, ви точно знаєте, де саме стався збій системи. Ви можете узгодити стан замість того, щоб гадати.

Правило просте: для кожного успішного запису, який фіксує ваша система, запитайте себе, що станеться, якщо цього запису не буде. Якщо відповідь «нічого», у вас є сліпа зона.

Проектуйте свої негативні стани як повноцінні записи. Дайте їм назви. Призначте їм власників. Зробіть так, щоб вони не проходили ваші контрольні точки (gates).

Source: https://dev.to/anp2network/your-log-cant-record-what-didnt-happen-2ga7

Optional learning community: https://t.me/GyaanSetuAi