Як Figma прискорила розслідування інцидентів агентами

Як розкласти розслідування сповіщення на кроки

Агент тріажу отримує не окремий сигнал, а повну історію обговорення у Slack, власну пам’ять із настановами й набір інструментів, обмежений потребами чергового фахівця з безпеки. Далі він перевіряє журнали та шукає пов’язані відомості в історичних сповіщеннях. Для цього у Figma поєднали AWS Bedrock Knowledge Bases, Amazon Kendra, Tines та інструмент на базі Snowflake з даними Panther.

• Передати агенту весь контекст поточного обговорення, а не лише текст сповіщення.
• Зіставити подію з минулими сповіщеннями та їхніми розслідуваннями.
• Перевірити потрібні корпоративні системи через окремі, заздалегідь обмежені інструменти.
• Застосувати настанови, накопичені під час попередніх перевірок.
• Якщо потрібна зміна коду, створити PR лише як чернетку для перегляду людиною.

Пам’ять варто ділити на три незалежні частини: минулі сповіщення, поведінкові настанови та вивчені структури баз даних. У Figma саме пам’ять найбільше вплинула на корисність системи з часом. Робоче формулювання для агента може відтворювати цю логіку: Проаналізуй повну історію сповіщення, знайди подібні минулі випадки, перевір доступні журнали через дозволені інструменти та підготуй висновок. Зміни коду оформи лише як чернетку PR.

Інша задача: пошук вразливостей і перевірка коду

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

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

Де підхід дає збій

Немає універсальної конфігурації агента. Порядок інструментів, рівень автономності та критерії перевірки залежать від розміру компанії, її ризиків і вже наявних циклів зворотного зв’язку. Тому механічно переносити налаштування Figma в іншу компанію не варто.

Сам запит на схвалення теж не гарантує безпеки. Wiz показала, що шість асистентів для програмування можна було ввести в оману шкідливим репозиторієм, тоді як користувач бачив нешкідливий на вигляд запит. Окремий ризик — вихід із пісочниці. Тому контроль має бути вбудований в інструменти: PR створюються чернетками, а промпти не дозволяють передавати чутливі дані у публічні канали Slack. Формулювання обмеження: Не публікуй чутливі дані у відкритих каналах Slack. Не виконуй зміну самостійно; підготуй чернетку для людського схвалення.

Що перевіряє людина перед рішенням

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

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