Abnormal AI бореться з фішингом за допомогою агентів-кодерів

Три рівні перевірки: агент бачить лише найскладніші випадки

Abnormal AI не пускає всі листи через важку перевірку — це і дорого, і не потрібно. Система працює каскадом. На першому рівні мільярди листів на день проходять через легкі моделі й прості правила (зокрема логістичну регресію) — цього достатньо для очевидних випадків. Ті, у яких перший рівень «не впевнений», переходять на другий рівень: мільйони листів на день аналізують складніші моделі, що оцінюють поведінкові сигнали.

Лише десятки тисяч найважчих випадків на день — раніше вони вимагали б аналітика-людини — потрапляють на третій рівень. Саме тут працює агент із доступом до код-пісочниці: він отримує дані про потенційну загрозу, сам пише скрипт для аналізу, виконує його в пісочниці, звіряє результат із поведінковою моделлю компанії та ухвалює рішення. Помилкові класифікації на цьому етапі не ігноруються — вони йдуть в окрему систему, яка на них навчається, а окремі моніторингові системи постійно перевіряють роботу всього конвеєра.

Другий агент: не детектор, а аналітик, що сам пише правила

Окремо від детекції в реальному часі в Abnormal AI працює «агент-аналітик» у пакетному режимі — близько 100 пакетних завдань на тиждень. Його робота інша: він забирає помилкові класифікації та сигнали для донавчання з основного конвеєра, шукає в них закономірності на великих масивах повідомлень і сам пише чернетки нових правил для першого рівня, а також покращує моделі для другого рівня.

Такі завдання можуть тривати понад 30 хвилин з безперервною сесією пісочниці або розтягуватися на цілий день з періодичними викликами. Практичний прийом тут — використовувати файлову систему як контрольну точку: агент рахує щось у пісочниці, зберігає проміжний результат у файл, запускає довге зовнішнє тренування моделі, а потім знову звертається до пісочниці, щоб обробити готовий результат. Це дозволяє обходити обмеження на тривалість однієї сесії без втрати проміжних даних.

Чому пісочниця навмисно відрізана від інтернету

Abnormal AI свідомо обрала режим пісочниці без виходу в мережу — і робить це з двох причин. Перша — відтворюваність: без зовнішнього доступу нічого, що не контролює компанія, не може вплинути на поведінку агента під час сесії, тож середовище лишається повністю детермінованим. Друга — запобігання витоку даних: у пісочницю потрапляють чутливі дані про загрози, і навіть якщо агент «зіпсується» через промпт-ін’єкцію чи випадкову поведінку, у нього фізично немає каналу відправити ці дані назовні.

До цього додаються ще дві практики: контроль того, які типи даних узагалі потрапляють у пісочницю і які дії запису дозволені, а також те, що постачальник пісочниці працює в межах уже існуючих договірних відносин компанії з хмарним провайдером — це знижує навантаження на комплаєнс-перевірку нового постачальника. Шар ізоляції пісочниці накладається на вже наявну мережеву ізоляцію — тобто захист дублюється, а не замінюється.

Що варто перевірити, перш ніж довіряти результату агента

З досвіду Abnormal AI випливає кілька практичних правил. Перше — агенту краще давати загальний принцип вирішення задачі, а не жорсткий покроковий сценарій: за словами VP AI Strategy компанії Шріву Шанкара, «майже будь-якому агенту, пише він код чи ні, потрібна пісочниця для обчислень, яка дозволяє реально прораховувати дані й доходити до відповідей». Жорсткі інструкції обмежують якість результату сильніше, ніж загальний напрямок.

• Пісочниця потрібна не лише агентам, що пишуть код, — будь-якому агенту, який агрегує дані, шукає закономірності або щось перевіряє
• Якість результату суттєво зростає, коли агент може сам себе перевірити всередині пісочниці — юніт-тестами, лінтингом, інтеграційними тестами — перед тим, як віддати фінальну відповідь
• Для задач, довших за одну сесію пісочниці, використовуйте файлову систему як точку відновлення, а не намагайтеся вкластися в один безперервний запуск

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