Anthropic представила Fable як публічнішу й обмеженішу версію своєї кібербезпекової моделі Mythos. Ідея зрозуміла: дати ширшому колу користувачів інструмент для аналізу коду, захисту систем і пошуку слабких місць, але не перетворити його на помічника для створення шкідливого ПЗ.
Проблема в тому, що частина фахівців із кібербезпеки швидко зіткнулася з надто жорсткими обмеженнями. За їхніми скаргами, Fable може зупиняти навіть нейтральні або оборонні запити: прочитати технічний текст, перевірити код на безпечні практики, пояснити помилку в конфігурації. Для звичайного користувача це виглядає як дрібна незручність. Для security-команди — як інструмент, який обіцяє допомогти, але мовчить саме тоді, коли потрібен найбільше.
Що таке guardrails у AI-моделях
Guardrails — це набір правил і технічних фільтрів, які обмежують поведінку моделі. Вони можуть блокувати певні теми, змінювати відповідь, просити переформулювати запит або переводити користувача на іншу модель із нижчим рівнем доступу.
У випадку кібербезпеки причина очевидна. Один і той самий інструмент може допомогти як захиснику, так і зловмиснику. Пояснення вразливості, приклад експлуатації, автоматизований аналіз коду чи генерація скриптів можуть бути корисними для аудиту власної системи. Але ті самі знання можна використати для атаки на чужу інфраструктуру.
Тому AI-компанії намагаються відрізнити дозволені запити від небезпечних. Наприклад, допомогти написати безпечний код — так. Допомогти створити malware або обійти захист — ні. На папері межа виглядає простою. У реальному діалозі вона часто розмита.
Чому Fable викликала невдоволення дослідників
За повідомленнями користувачів, Fable іноді реагує не на реальний намір запиту, а на сам факт, що в ньому є слова з поля кібербезпеки. Якщо модель бачить згадки про vulnerability, exploit, malware, code review або security, вона може зупинити відповідь ще до аналізу контексту.
Це створює кілька практичних проблем.
По-перше, захисні задачі часто використовують ту саму лексику, що й атакувальні. Фахівець не може якісно описати XSS, SSRF, privilege escalation або небезпечну залежність, не називаючи ці речі прямо.
По-друге, багато безпечних запитів виглядають «підозріло» для простого фільтра. Наприклад: «перевір цей фрагмент на SQL injection», «поясни, чому цей код небезпечний», «допоможи написати unit-тест для валідації введення». Це не атака, а нормальна інженерна робота.
По-третє, користувач втрачає довіру до інструмента. Якщо модель непередбачувано блокує частину робочих сценаріїв, команді складно планувати процеси навколо неї.
Чому Anthropic могла обрати суворі правила
Суворі обмеження не обов’язково означають поганий дизайн. Для нової моделі, особливо в чутливій сфері, компанія може навмисно почати з консервативного режиму: краще заблокувати частину легітимних запитів, ніж випадково допомогти з реальною атакою.
Цей підхід має логіку. Кібербезпекові моделі можуть масштабувати знання швидше, ніж традиційні інструменти. Якщо модель добре пояснює ланцюжки атак, генерує код і адаптується до помилок, ризик зловживання зростає. Тому розробники AI-сервісів часто запускають такі функції через обмежені програми доступу, перевірку організацій або спеціальні режими для професіоналів.
Але у суворого старту є ціна: реальні дослідники й розробники відчувають, що їх карають за коректну професійну мову.
Де проходить складна межа між захистом і шкодою
Найважче питання — не «блокувати чи не блокувати», а «як саме розрізняти контекст».
Запит «поясни, як працює буферне переповнення» може бути навчальним. Запит «напиши експлойт для конкретної версії сервера» може бути небезпечним. Але між ними є багато сірих зон: аналіз власного proof of concept, підготовка звіту bug bounty, перевірка внутрішнього сервісу компанії, навчальна лабораторія, курс для студентів.
Якщо модель оцінює лише ключові слова, вона буде помилятися. Кращий підхід — враховувати намір, рівень деталізації, наявність дозволеного середовища, тип результату й потенційну шкоду. Наприклад, можна дозволити пояснення ризику, рекомендації з виправлення, безпечний code review і defensive checklist, але обмежити інструкції для прихованого доступу, крадіжки даних або обходу захисту.
Що це означає для розробників
Для розробників головний висновок простий: AI-помічник не має бути єдиним інструментом безпекового review. Якщо модель блокує запит або дає надто загальну відповідь, це не означає, що проблеми немає.
Практичний підхід:
- формулюйте задачу як захисну: «перевір мій код на безпечні практики», «поясни ризики», «запропонуй виправлення»;
- додавайте контекст: це власний проєкт, тестове середовище або навчальна лабораторія;
- просіть не експлуатацію, а remediation: як виправити, як перевірити конфігурацію, які тести додати;
- не вставляйте секрети, токени, приватні ключі та внутрішні дані;
- дублюйте важливі висновки статичними аналізаторами, dependency scanners і ручним review.
Якщо AI-сервіс постійно блокує безпечні задачі, краще не намагатися «обходити» фільтр, а змінити процес: використовувати спеціалізовані інструменти, внутрішні моделі або корпоративні програми доступу.
Що це означає для security-команд
Security-командам варто сприймати Fable-подібні моделі не як заміну експерта, а як потенційний шар допомоги. Вони можуть бути корисними для чернеток звітів, пояснення ризиків бізнесу, перевірки патернів у коді, підготовки навчальних матеріалів і швидкого пошуку очевидних помилок.
Але для повноцінної роботи потрібні три умови:
- прозорі правила: що модель дозволяє, що блокує і чому;
- контроль доступу: хто в компанії може використовувати AI для security-задач;
- аудит: які дані передаються в модель і чи не потрапляє туди чутлива інформація.
Без цього AI або буде занадто небезпечним, або занадто обмеженим, щоб приносити користь.
Чого бракує таким моделям зараз
Найбільший виклик — пояснюваність відмов. Якщо модель просто каже, що запит зачіпає кібербезпеку, користувач не розуміє, як переформулювати задачу без втрати сенсу. Набагато корисніше було б відповідати так: «Я не можу допомогти з експлуатацією, але можу пояснити ризик, показати безпечний варіант коду або скласти checklist перевірки».
Також важлива градація доступу. Студент, незалежний дослідник, корпоративний blue team і випадковий користувач мають різні ризики й потреби. Однаковий фільтр для всіх майже неминуче буде або надто м’яким, або надто суворим.
Підсумок
Ситуація з Fable показує головну дилему AI в кібербезпеці: моделі вже достатньо корисні, щоб їх хотіли використовувати професіонали, але достатньо потужні, щоб компанії боялися зловживань. Суворі guardrails можуть бути виправданими на старті, проте якщо вони блокують навіть безпечний code review, користь інструмента різко падає.
Для користувачів це сигнал не покладатися на один AI-сервіс і чітко відокремлювати захисні задачі від потенційно шкідливих. Для AI-компаній — нагадування, що безпека має бути не лише жорсткою, а й розумною: з контекстом, поясненнями, професійними режимами доступу й можливістю працювати там, де кібербезпека справді захищає, а не атакує.
