Коли Anthropic запустила Project Glasswing і відкрила доступ до свого спеціалізованого моделя Mythos лише обмеженому колу партнерів, обіцянка була чіткою: навіть якщо сам інструмент залишиться закритим, уроки мають стати публічними. Тепер ці уроки починають вимальовуватися. В епізоді подкасту Security Intelligence від IBM Technology панель експертів — Кіммі Фаррінгтон, Дастін “EvilMog” Гейвуд та Кертіс Піттс — обговорюють перші висновки Cloudflare з роботи з Mythos і те, як організаціям варто мислити про довіру, швидкість і управління при впровадженні таких фронтирних AI-моделей у процеси кіберзахисту.
За лаштунками гучних заголовків про “революційний” AI для пошуку вразливостей проступає значно прозаїчніша, але важливіша картина: Mythos — це не магічний оракул, а надзвичайно швидкий “людина-подібний” оператор усередині вашої мережі. Він потребує постановки задач, контролю, перевірки результатів і вбудовування в уже існуючі процеси. І саме тут починається справжня робота.
AI як дуже швидка людина в мережі, а не всезнаючий оракул
Один із ключових мотивів дискусії — тверезе переосмислення ролі фронтирних моделей у безпеці. Панель порівнює Mythos з “дуже швидкою людиною всередині мережі”: інструментом, який може робити те саме, що досвідчений дослідник вразливостей, але в рази швидше й масштабніше.
Це порівняння має важливі наслідки. Якщо сприймати Mythos як ще одного, просто надзвичайно продуктивного оператора, стає очевидно, що до нього потрібно застосовувати ті самі принципи управління, що й до людей з розширеними правами доступу. Йдеться не лише про технічні обмеження, а й про процеси:
доступ має бути чітко визначеним і мінімально необхідним;
дії — логованими й підзвітними;
результати — перевіреними, перш ніж на їх основі ухвалюються рішення.
Панель прямо підкреслює: більшість AI-орієнтованого пошуку вразливостей, навіть із такими моделями, як Mythos, усе ще потребує кваліфікованого оператора. Потрібна людина, яка правильно сформулює завдання, обере ціль, розіб’є роботу на етапи, інтерпретує знайдені “знахідки” й інтегрує їх у реальні процеси усунення вразливостей.
Це різко контрастує з популярною фантазією про те, що достатньо “направити AI на репозиторій” і отримати вичерпний список реальних проблем. Cloudflare прямо показала, що такий підхід не працює: без додаткової оркестрації модель починає “блукати”, контекстне вікно швидко забивається, а вихід перетворюється на шум.
У підсумку Mythos і подібні системи логічно вписуються не в роль “центрального мозку безпеки”, а в роль ще одного, хай і дуже потужного, сканера в арсеналі. Як сформулював Кертіс Піттс, для IBM це “ще один скан-інструмент” поряд з іншими, а не самодостатнє рішення.
Чому без кастомного “harness” навіть найкращий AI дає шум
Cloudflare стала одним із перших гравців, хто детально описав свій досвід із Mythos. Компанія прогнала модель більш ніж по 50 репозиторіях коду й виявила, що “просто запустити агента на репо й попросити знайти вразливості” — майже гарантований шлях до розчарування. Модель або тоне в контексті, або відхиляється від теми, або генерує надто багато сумнівних “знахідок”.
Виходом став так званий harness — кастомна обв’язка, яка розбиває процес пошуку вразливостей на окремі кроки й координує роботу кількох спеціалізованих агентів. Кіммі Фаррінгтон порівнює цей підхід із класичною філософією Unix та Linux: багато маленьких утиліт, кожна з яких робить одну річ, але робить її добре, і передає результат далі по ланцюжку.
У випадку з Mythos це означає не один “всевидючий” агент, а низку вузько орієнтованих:
один агент аналізує структуру репозиторію;
інший фокусується на певному класі вразливостей;
третій будує потенційні ланцюжки експлуатації;
четвертий генерує proof-of-concept.
Кожен із них працює в чітко окресленому контексті, а harness виступає диспетчером, який керує послідовністю кроків і обміном даними між агентами.
Панель наголошує: саме ця обв’язка, а не сама модель, є “найважливішою частиною Mythos”. Без неї навіть найпотужніший LLM перетворюється на джерело шуму. З нею — на інструмент, який набагато ближчий до того, як працюють живі дослідники: поетапно, цілеспрямовано, з чітким розподілом задач.
Цікаво, що цей висновок перегукується з ширшою тенденцією в AI: відмовою від ідеї “однієї моделі, що править усім” на користь набору спеціалізованих агентів і невеликих, цільових моделей. IBM, як зазначає Піттс, давно просуває саме концепцію purpose-built моделей — і досвід Cloudflare з Mythos лише підкріплює цю лінію.
Експеримент з curl: чому AI-знахідки потрібно жорстко валідувати
Одним із найяскравіших прикладів того, чому AI у безпеці потрібно сприймати як “шумний, але корисний сигнал”, а не як істину в останній інстанції, став експеримент автора curl Даніеля Стенберга. Він прогнав Mythos по коду curl — одному з найбільш досліджених і перевірених проєктів з відкритим кодом.
Результат на перший погляд вражав: Mythos “знайшов” п’ять потенційних вразливостей. Проте детальний аналіз показав, що реальним виявився лише один баг — і той відносно незначний. Чотири інші виявилися хибними спрацюваннями.
Цей кейс став для панелі ілюстрацією одразу кількох моментів.
По-перше, навіть дуже сильна модель, здатна будувати складні ланцюжки експлуатації й генерувати переконливі PoC, не застрахована від помилок. Вона може “пояснити” неіснуючу вразливість так, що це виглядатиме правдоподібно для нефахівця.
По-друге, без системної валідації AI-знахідок організація ризикує витрачати ресурси на “примари” — перевірку й виправлення проблем, яких насправді немає. У масштабі великої кодової бази це може означати сотні людино-годин, спалених на хибні спрацювання.
По-третє, цей приклад підкреслює важливість підходу “довіряй, але перевіряй” до фронтирних моделей. Панель прямо говорить: організації не повинні сліпо довіряти виводу таких систем, а мають сприймати їх як джерело сигналів, які потребують подальшої перевірки.
Кіммі Фаррінгтон особливо виділяє ідею крос-модельної перевірки. Навіть якщо Mythos знайшов вразливість і згенерував proof-of-concept, це ще не означає, що проблема реальна. Вона радить проганяти знайдені кейси через іншу модельну базу — інший LLM чи інший інструмент — як додатковий рівень QA. Це не скасовує потреби в людській експертизі, але дозволяє відсіяти частину очевидних помилок ще до того, як до справи долучаються інженери.
У підсумку експеримент із curl стає не стільки критикою Mythos, скільки нагадуванням: навіть найпросунутіший AI у безпеці — це не “оракул ризиків”, а ще один датчик у складній системі. Його показники потрібно калібрувати, порівнювати з іншими джерелами й перевіряти руками.
Швидкість — не панацея: чому архітектура важливіша за миттєві патчі
Одне з найцікавіших спостережень Cloudflare, яке обговорює панель, стосується одержимості індустрії “швидкістю”. Реакція багатьох безпекових лідерів на Mythos, за цитатою з блогу Cloudflare, зводилася до мантри: “сканувати швидше, патчити швидше, стискати цикл реагування”.
Після реальної роботи з Mythos Cloudflare дійшла іншого висновку: значно важливіше не те, наскільки швидко ви можете закрити баг, а те, наскільки важко його експлуатувати в поточній архітектурі. Компанія формулює це так: принцип полягає в тому, щоб зробити експлуатацію складнішою навіть тоді, коли вразливість існує, аби проміжок між розкриттям і патчем мав менше значення.
Кертіс Піттс пов’язує це з базовими принципами сучасної безпеки: жодна архітектура не буде ідеальною, вразливості завжди існуватимуть, а люди залишатимуться внутрішньою загрозою. Тому ключове питання — не “чи зможе хтось зайти?”, а “що станеться, коли він зайде?”.
У цьому контексті AI-інструменти на кшталт Mythos — лише ще один шар у багаторівневому захисті. Вони можуть допомогти швидше знаходити слабкі місця, але не замінять:
сегментацію мережі;
мінімізацію прав доступу;
контроль над lateral movement;
обмеження “blast radius” при компрометації окремого компонента.
Панель підкреслює: якщо архітектура побудована так, що навіть успішна експлуатація однієї вразливості дає зловмиснику мінімальні можливості, залежність від “ультрашвидкого патчингу” зменшується. І навпаки, якщо внутрішні контролі слабкі, жодна швидкість не врятує: “відкрийте поверхню атаки — і ми зайдемо”, як формулює це Гейвуд.
Це зміщення фокусу — від гонитви за мілісекундами до системного зміцнення архітектури — може стати одним із найважливіших наслідків появи таких інструментів, як Mythos. Вони оголюють реальність: проблема не лише в тому, як швидко ми знаходимо й латаємо діри, а в тому, як виглядає система, коли ці діри неминуче існують.
Модель у шарі, а не замість шару: як правильно вбудовувати фронтирний AI
Ще один наскрізний мотив розмови — ідея шарового підходу до безпеки, який не зникає навіть із появою фронтирних моделей. Панель неодноразово наголошує: “layered approach is still king”, і Mythos не змінює цього принципу, а лише додає новий інструмент у вже знайому схему.
У практичному вимірі це означає кілька речей.
По-перше, Mythos та інші подібні моделі мають інтегруватися в існуючі пайплайни безпеки, а не замінювати їх. Вони можуть доповнювати статичний і динамічний аналіз, ручний пентестинг, code review, але не скасовують потреби в жодному з цих елементів.
По-друге, управління AI стає ще одним аспектом “кібергігієни”. Як зауважує Піттс, управління AI — це просто ще один шар гігієни: потрібно контролювати, що саме модель може робити, до чого має доступ, як логуються її дії, хто переглядає результати. Якщо ці контролі слабкі, AI стає ще одним шляхом до ескалації проблем, а не до їх вирішення.
По-третє, важливим елементом шарового підходу стає крос-модельна перевірка. Рекомендація панелі — використовувати іншу модельну базу для QA знайдених Mythos вразливостей і PoC — по суті додає ще один “шар фільтрації” між AI-виходом і діями інженерів. Це знижує ризик того, що хибні спрацювання чи помилки моделі автоматично перетворяться на витрати часу й ресурсів.
І, нарешті, по-четверте, шаровість стосується й людей. Дискусія неодноразово повертається до думки, що “нам знову потрібні кваліфіковані оператори”. Парадоксально, але поява потужних AI-інструментів не скасовує потреби в людській експертизі, а підвищує її цінність: тепер потрібні фахівці, здатні керувати “зграєю” агентів, будувати harness-и, інтерпретувати неоднозначні результати й приймати рішення в умовах невизначеності.
У цьому сенсі Mythos і подібні моделі не стільки автоматизують безпеку, скільки змінюють профіль роботи: від ручного “копання” в коді до управління складними AI-процесами.
Glasswing як полігон: чому варто брати участь, але з холодною головою
Попри всю обережність у формулюваннях, панель не закликає триматися подалі від фронтирних моделей. Навпаки, Кіммі Фаррінгтон висловлюється максимально прямо: будь-яке підприємство, яке будує софт, має брати участь у Project Glasswing й “кидати свій код” на Mythos.
Аргумент простий: це унікальний шанс протестувати власні розробки на інструменті, який уже показав здатність будувати складні ланцюжки експлуатації й генерувати якісні PoC. Навіть якщо частина знахідок виявиться хибною, сам факт того, що модель дивиться на ваш код “очима” потенційного зловмисника, може виявити класи проблем, які раніше залишалися поза фокусом.
Водночас Фаррінгтон робить важливе застереження: робити це потрібно лише в рамках дисциплінованого процесу. Такий процес має включати:
кастомний harness, який розбиває завдання на кроки й координує агентів;
крос-модельну перевірку знайдених вразливостей і PoC;
людський review перед тим, як результати потрапляють у беклог розробки чи план реагування.
Без цих елементів участь у Glasswing ризикує перетворитися на експеримент заради експерименту: багато шуму, мало практичної користі й потенційно — плутанина в командах розробки та безпеки.
Той факт, що Anthropic послабила NDA для учасників Glasswing, а IBM нещодавно приєдналася до проєкту, означає, що подібних публічних кейсів, як у Cloudflare, ставатиме більше. Це створює рідкісну можливість для галузі: колективно відпрацювати нові підходи до інтеграції AI в безпеку, не повторюючи одні й ті самі помилки в ізоляції.
Висновок: довіряти, перевіряти й будувати так, ніби баги неминучі
Перші уроки з Project Glasswing і досвіду Cloudflare з Mythos малюють картину, далеку від магічного мислення. Фронтирні моделі в безпеці виявляються не “чарівною паличкою”, а ще одним потужним, але примхливим інструментом, який:
потребує кастомної обв’язки й спеціалізованих агентів;
генерує як цінні інсайти, так і хибні спрацювання;
вимагає крос-модельної й людської валідації;
має працювати в рамках шарової архітектури, а не замість неї.
Головний зсув мислення, який пропонує ця дискусія, полягає в тому, щоб перестати сприймати AI як шлях до “ідеальної, безбагової” системи. Вразливості залишаться. Людські помилки залишаться. Інсайдерські загрози залишаться. Питання в тому, наскільки важко буде ці вразливості експлуатувати й наскільки обмеженим буде збиток, коли це станеться.
У такому світі Mythos та інші моделі стають не центром, а ще одним шаром — дуже швидким “людиною в мережі”, якій можна довіряти рівно настільки, наскільки ви готові її перевіряти. І саме від того, наскільки дисципліновано організації будуть інтегрувати ці інструменти, залежить, чи стануть вони реальним підсиленням безпеки, чи лише черговим джерелом шуму.