Нотатки від команди з безпеки протоколу Фундації Ethereum щодо запуску скоординованих ШІ-агентів для перевірки реального коду протоколу, включно з тим, як ми організовуємо роботу, що витримує ретельну перевірку, і що команди розробників клієнтів та дослідники безпеки можуть з цього винести. Ця стаття є самостійною; наступні публікації детальніше розглядатимуть окремі клієнти.
Що ми запускали і що нас здивувало
У команді з безпеки протоколу Фундації Ethereum ми запускали скоординованих ШІ-агентів для перевірки систем, від яких залежить мережа, таких як системне програмне забезпечення, криптографічний код та контракти, які мають працювати бездоганно. Агенти знайшли реальні баги. Один із них тепер публічний: паніка, що викликається віддалено, у gossipsub бібліотеки libp2p — ключовій частині однорангового рівня, на якому працюють клієнти консенсусу Етеріуму. Її було виправлено та розкрито як CVE-2026-34219 із зазначенням авторства команди.
Те, що агенти знаходять баги, не стало несподіванкою. Сюрпризом стало те, як мало зусиль пішло на їхній пошук, і як багато — на те, щоб відрізнити справжні баги від тих, що лише здавалися такими.
Ця стаття призначена для команд розробників клієнтів та дослідників безпеки, які хочуть зробити те саме. Вона охоплює те, як ми організовуємо агентів, критерії, яким має відповідати кандидат, перш ніж його визнають знахідкою, та звички, які допомагають зберігати результати достовірними.
Інші команди сходяться на тому ж рецепті. Команда Frontier Red Team від Anthropic створила агента, який пише тести на основі властивостей і знайшов реальні баги в екосистемі Python. Cloudflare запустила модель Фронтір через середовище для досліджень безпеки для перевірки власних систем. Усі приходять до одного й того ж циклу: націлити потужну модель на кодову базу, дозволити їй шукати та сортувати те, що вона повертає. Тож головне питання полягає в тому, як це зробити, не потонувши у впевненому на перший погляд шумі.
Одне застереження наперед: інструменти для аудитів за допомогою агентів розвиваються швидко, і будь-яке конкретне налаштування застаріває за кілька тижнів. Тому ця стаття навмисно присвячена методам, які є сталими, а не інструментам. Розкриття інформації — це окрема тема, якій, ймовірно, буде присвячена окрема публікація.
Агент — це інструмент пошуку, а не оракул
Агент, націлений на кодову базу, є інструментом пошуку, дуже схожим на фазер. Різниця полягає в тому, що ви отримуєте у відповідь. Фазер видає вам збій і трасування стека. Агент надає набагато більше, включно з описом (ланцюг викликів, твердження про вплив, пропонована серйозність) та артефактами для його підтвердження, такими як підтвердження концепції (proof-of-concept), яке можна запустити на реальному коді.
Усе це робить результат легким для читання та таким, що викликає довіру, а найбільше — працююче підтвердження концепції. Тому не рахуйте, скільки кандидатів видає агент. Рахуйте, скільки з них виявляються справжніми.
Як організована робота
Ми запускаємо багато агентів паралельно для однієї цілі. Вони координуються через сам репозиторій, зі спільним станом у системі контролю версій і без центрального процесу, який би роздавав завдання. Агент записує твердження там, де його можуть бачити інші, виконує роботу та робить коміт.
Ми запозичили цей підхід зі статті Anthropic про створення компілятора C за допомогою групи агентів, які координуються таким самим чином. Немає центрального координатора, якого потрібно створювати чи підтримувати, і менше речей, які можуть піти не так.
Ролі формуються на основі виявленої роботи:
- Розвідка (Recon) перетворює поверхню атаки на конкретні гіпотези, які можна перевірити. Не «провести аудит декодера», а «цьому полю довіряють після цього моменту; ось властивість, яку воно має зберігати, спосіб, у який воно може зламатися, і доказ, який це підтвердить».
- Полювання (Hunting) бере одну гіпотезу, відстежує шлях коду та намагається створити відтворювач (reproducer).
- Заповнення прогалин (Gap-filling) аналізує, що було прийнято, а що відхилено, пише наступну партію гіпотез і відстежує покриття, щоб агенти не проходили постійно по одному й тому ж місцю.
- Валідація (Validation) незалежно перевіряє кожного кандидата ще раз, видаляє дублікати та приймає рішення.
Ми не винайшли цей конвеєр. Cloudflare описує ті самі етапи: розвідка, паралельне полювання, незалежна валідація, дедуплікація, звітування, і їхня стаття допомогла сформувати наш підхід.
Ось як виглядає кандидат, перш ніж його визнають знахідкою:
ціль: компонент і точка входу, до яких зловмисник дійсно може дістатися інваріант: властивість, яка має зберігатися механізм: конкретний спосіб, у який його можна зламати успіх: доказ, який можна спостерігати: паніка, зависання, прийняте недійсне введення відтворювач: автономний артефакт, який запускається на реальному коді дедуп: ключ, щоб два агенти не ганялися за одним і тим самим
Ця схема існує не просто так. Вона вимагає конкретного твердження, яке можна перевірити, і чіткого визначення готовності. Агент, який має записати доказ, що можна спостерігати, не може відкараскатися фразою «це виглядає ризиковано».
Відтворюється, або цього не було
Одне правило має більше значення, ніж будь-яке інше. Кандидат не є знахідкою, доки не з'явиться автономний артефакт, який відтворює збій на реальному коді, і який працює у того, хто його не писав.
Відтворювач не читає опис, і йому байдуже, наскільки впевнено звучала модель. Він або працює, або ні.
Більша частина його цінності полягає у хибнопозитивних результатах, які він виявляє. Три з них з'являються знову і знову, і кожен з них — це випадок, коли агент проходить перевірку з хибної причини:
- Паніка, яка трапляється лише у відлагоджувальній збірці (debug build). Скомпілюйте та запустіть її так, як програмне забезпечення постачається насправді, і значення просто переповнюється по колу. Нічого не падає. Це виглядає як збій, але ним не є.
- Відтворювач, який створює певне внутрішнє значення вручну, таке, яке жодне реальне введення ніколи не змогло б згенерувати, оскільки кожен шлях, який контролює зловмисник, відхиляє його раніше. Баг «відтворюється» лише на функції, яку ніщо досяжне не викликає таким чином.
- У роботі з формальної верифікації — доказ, який проходить, але не означає того, що ви хотіли. Твердження є тривіально істинним незалежно від того, що робить код, або воно слабше за властивість, яку ви хотіли зафіксувати. Верифікатор задоволений, але теорема не обмежує поведінку, яка вас насправді цікавила.
У цьому немає нічого нового. Це те саме, що й тест, який проходить, бо насправді нічого не перевіряє. Новим є обсяг. Агент пише марну версію так само швидко, як і справжню, і так само впевнено. Тому перевірка має бути автоматичною. Ви не можете розраховувати на те, що агент сам себе виправить.
Співвідношення сигнал/шум — це більша частина роботи
Більшість кандидатів є помилковими, дублікатами або виходять за межі області застосування. Це не проблема методу; так він працює. Мета полягає в тому, щоб швидко відхиляти помилкові та підкріплювати справжні доказами, з якими важко сперечатися.
Кожен кандидат, який виживає, проходить дві незалежні перевірки. Чи може реальний зловмисник дійсно дістатися до нього у звичайній конфігурації? І скільки коштуватиме зловмиснику його реалізація порівняно з тим, скільки це коштуватиме мережі, якщо він спрацює? Баг, який може викликати будь-який окремий пір, дуже відрізняється від того, який потребує спеціального доступу або величезної кількості ресурсів.
Усе перевіряється за поточним списком того, що вже відомо, виправлено або відхилено. Без цього агенти продовжують заново відкривати ту саму закриту проблему і повідомляти про неї знову і знову.
Рівень прийняття сильно варіюється від цілі до цілі, і ця варіативність корисна сама по собі. Запустіть це на зрілому коді, який пройшов ретельний аудит, і майже нічого не виживе, що все одно варто знати. «Ми ретельно шукали і нічого не знайшли» — це реальний результат. Запустіть це на менш дослідженому коді або на формально верифікованому коді, де перевірений машиною доказ покриває модель, а розгорнутий байт-код лише припускається таким, що їй відповідає, і пройде більше.
Ми не єдині, хто виявив, що сортування — це найскладніша частина. Головний висновок Cloudflare полягав у тому, що вузька область застосування краща за широке сканування. Агент Anthropic для тестування на основі властивостей згенерував близько тисячі звітів-кандидатів, а потім використав ранжування та експертну оцінку, щоб звести їх до найвищого рівня, який підтверджувався приблизно у 86 відсотках випадків. Генерація була найпростішою частиною. Я не збираюся публікувати тут наші власні цифри; прив'язані до конкретної цілі, вони б сказали більше про ціль, ніж про метод.
У чому агенти хороші, а де вони вводять в оману
Ажіотаж є в обох напрямках, тому ось простий список того, що агенти роблять добре, а де вони вводять в оману.
| У чому хороші | Де вводять в оману |
|---|---|
| Спільне читання специфікації та коду | Ланцюги викликів, які виглядають досяжними, але такими не є |
| Формулювання та перевірка реального інваріанта | Маніпулювання перевіркою успішності (проходження з хибної причини) |
| Створення чернетки відтворювача з ідеї в один рядок | Завищення серйозності відповідно до того, наскільки драматично звучить опис |
| Пропонування першопричини до того, як ви подивилися | Баги, що охоплюють послідовність дійсних кроків |
Цей розподіл навіть не є стабільним від одного завдання до іншого. Станіслав Форт, тестуючи низку моделей на реальних вразливостях, називає це нерівним фронтіром (jagged frontier), коли модель, яка відновлює повний ланцюг експлойту на одній кодовій базі, може провалити базове відстеження потоку даних на іншій. Ви не можете припускати, що один хороший результат означає, що наступний також підтвердиться, і це ще одна причина, чому кожен кандидат перевіряється окремо.
Останній рядок є найважливішим. Одиночна сесія агента добре справляється з одномоментними міркуваннями і погано — з багами, які охоплюють послідовність кроків, де кожен крок є дійсним, і лише порядок є неправильним. Для них агент не є інструментом пошуку. Його завдання — запропонувати, які послідовності варто прогнати через середовище тестування зі збереженням стану. При такому використанні він працює добре. Якщо ж використовувати його як заміну середовищу тестування, він пропускає найдорожчі баги, які тільки існують — ті, що проявляються лише в послідовності.
Збереження чесності
Кілька звичок виконують більшу частину роботи з того, щоб зробити знахідки агентів достовірними, і жодна з них не є складною.
- Походження кожного артефакту: що його створило, з яким контекстом, для якої ревізії. Знахідка має бути чимось, що ви зможете запустити знову через кілька місяців.
- Детермінізм там, де це важливо: одне середовище, один спосіб збірки та запуску, щоб слово «відтворюється» означало одне й те саме на кожній машині, а не лише на тій, де це було знайдено.
- Норми, а не скрипти: кажіть агентам, що має значення, інваріанти та критерії для реальної знахідки, замість пронумерованої процедури. Занадто заскриптовані агенти ламаються так само, як і надмірно специфіковані тести: вони продовжують виконувати кроки після того, як ці кроки втрачають сенс. Дослідження файлів контексту репозиторію виявило те саме: додаткові вимоги знизили успішність виконання завдань і підвищили витрати на понад 20%, тому автори рекомендують звести контекст до мінімальних вимог.
- Остаточне рішення приймає людина: агенти пропонують. Вони не вирішують, що є реальним, що є дублікатом відомої проблеми, або що і коли буде розкрито.
Вузьке місце змістилося
ШІ не замінив дослідника безпеки. Він змістив роботу. Час, який раніше йшов на придумування та перевірку гіпотез, тепер витрачається на їхнє масштабне оцінювання, включно зі створенням оракула, проведенням сортування, веденням списку відомих проблем та обробкою розкриття інформації.
Вузьке місце нікуди не зникло. Воно змістилося від пошуку багів до довіри результатам, що є кращим місцем для нього, оскільки саме тут людське судження дійсно має значення. Але це все ще вузьке місце, і якщо його ігнорувати, ви в кінцевому підсумку випустите помилкове «все гаразд».
Практики, які змушують це працювати, не є новими. Відтворювані збої, реальні оракули та ретельне сортування — це ті самі практики, які за останні п'ятнадцять років перетворили фазинг із теми для досліджень на стандартну практику. Інструменти нові. Практики — ні.
Наскільки швидко продовжують змінюватися інструменти — питання відкрите. Ніколас Карліні, обережний і колись сам скептик, стверджує, що експоненціальний сценарій варто сприймати серйозно, навіть якщо він залишає для нього широкі межі похибки. Якщо сторона генерації зростає так швидко, сторона оцінювання має зростати разом із нею, інакше розрив між тим, що створюється, і тим, що насправді перевіряється, лише збільшуватиметься.
Для систем, від яких залежить Етеріум, саме ця частина має значення. Агенти дозволяють нам охопити набагато більше, ніж ми могли б зробити вручну. Натомість вони вимагають більш ретельного оцінювання набагато більшої купи впевнених на перший погляд тверджень. Це обмін, на який варто піти, за умови, що ви пам'ятаєте: оцінювання — це і є справжній продукт.