Безпека системного промпта: скільки він реально дає

Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai. Системний промпт — це не рівень захисту в тому сенсі, у якому ним є права доступу. Це зсув ймовірності, і його нарешті виміряли: команда Stanford показала, що навіть коли в системному промпті прямо перелічені вразливості, яких треба уникати, модель усе одно пише дірявий код у 23% випадків. Найкращий промпт, який машина вилизувала на 80 тисячах запитів, знижує цю частку приблизно на сорок відсотків. Не до нуля.

TL;DR (за 30 секунд)

• 23% — частка випадків, коли флагманська модель генерує верифіковану вразливість, хоча її прямо попросили писати безпечний продакшн-код і перелічили в контексті, яких слабкостей уникати. Вимір на корпусі з 250 нешкідливих запитів.
• До 48% цих вразливостей знімає SecureForge — пайплайн Stanford, який автоматично оптимізує системний промпт. Тобто одна програма з восьми лишається дірявою навіть після оптимізації.
• Ключове в методі, а не в результаті: промпт вдалося покращити тільки тому, що поруч стояв зовнішній детектор — статичний аналізатор Semgrep. Без нього не було б ані за чим оптимізувати, ані чим перевірити.
• Межа, яку фіксує The Batch: оптимізували тільки developer-промпт і тільки проти відомих класів вразливостей. Самі автори додають іншу: промпт, оптимізований під одну модель, не робить безпечною іншу.
• Тест на одне питання: хто перевіряє виконання цього правила? Якщо відповідь «сама модель» — це ставка зі зміщеним шансом, а не захист. Якщо відповідь «система, яка вміє сказати ні» — це контроль.
• Промпт варто писати добре, і це дає вимірюваний ефект. Просто ефект вимірюється у відсотках, а не в гарантіях.

«Ми ж прописали це в промпті»

25 квітня 2026 року агент у Cursor видалив продакшн-базу невеликого SaaS разом із доступними бекапами. Дев’ять секунд від рішення до незворотності, близько тридцяти годин простою. Потім агент написав пояснення і сам перерахував правила, які порушив: не перевірив, якому середовищу належить том; не прочитав документацію; не запитав підтвердження на деструктивну дію. Усі три були прописані в системному промпті, який модель читала перед кожним кроком.

Я розбирав цей інцидент детально в матеріалі про blast radius AI-агента — і висновок там був жорсткий: промпт — це текст, який модель зважує разом з усім іншим контекстом, а права доступу виконуються без участі моделі.

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

Скільки коштує «попроси ввічливо»

8 травня 2026 року команда зі Stanford — Houjun Liu, Lisa Einstein, John Yang, Joachim Baumann, Duncan Eddy, Christopher D. Manning, Mykel Kochenderfer і Diyi Yang — виклала роботу SecureForge. У серпні її розібрав The Batch.

Задача звучала прикладно: чи можна автоматично побудувати такий системний промпт, після якого модель пише менше вразливого коду.

Спочатку автори заміряли базу. Моделі давали нешкідливий запит на код, прямо просили писати безпечний продакшн-код і перелічували в контексті класи слабкостей, яких треба уникати. Тобто не «будь обережним», а нормально сформульована вимога з конкретикою — приблизно те, що напише притомний інженер. На корпусі з 250 таких запитів моделі видавали статично верифіковану вразливість у середньому в 23% випадків.

Далі побудували пайплайн. За основу взяли топ-25 вразливостей MITRE CWE — галузевий каталог типових помилок безпеки. GPT-5.4 перетворював кожен пункт каталогу на реалістичний побутовий запит: для «CWE-89: SQL Injection» це, наприклад, «напиши функцію на Python, яка шукає користувача за іменем у базі SQLite». Явні згадки вразливостей із запитів вичищали окремим проходом, щоб модель не отримувала підказку в лоб.

Кожен запит згодовували моделі, згенерований код проганяли через юніт-тести (перевірити, що воно взагалі робить те, про що просили) і через Semgrep — статичний аналізатор, який шукає вразливості за правилами. Залишали ті запити, на яких код вийшов дірявим: по 20 штук на кожен із 25 пунктів CWE, разом 500. Половину відклали на фінальну перевірку, решту 250 розмножили до 80 тисяч варіацій — переписуючи кожен запит у трохи іншу задачу і зберігаючи ті переписування, які продовжували ламати модель.

І вже на цих 80 тисячах системний промпт оптимізували генетичним алгоритмом GEPA: промпт ганяли на партії запитів, Semgrep повідомляв, де саме виникла вразливість, GPT-5.4 читав ці звіти разом з поточним промптом і пропонував наступну версію. Цикл повторювався, доки покращення не вичерпались.

Прогнали через це CodeLlama 7B, Qwen2.5-Coder 7B і 14B, Qwen3 30B-A3B, Kimi K2, Claude Sonnet 4.6, GPT-5.3 Codex і всю лінійку GPT-5.4.

Результат: на сорок відсотків краще і все ще діряво

На відкладених 250 задачах SecureForge порівняли з тим самим «попроси безпечний код і перелічи вразливості».

Модель	Промпт написаний людиною	Промпт оптимізований SecureForge
У середньому по всіх	20,1%	11,8%
GPT-5.4	15,8%	10,1%
GPT-5.4 Mini	21,4%	12,4%
GPT-5.4 Nano	22,1%	15,6%

Частка програм із виявленою вразливістю. У таблицю входять лише програми, які пройшли згенеровані юніт-тести, тобто робочий код, а не сміття. В абстракті статті для базового промпта наведено 23%, а найкращий результат оптимізації заявлений як зниження вразливостей до 48%.

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

Неприємне в тій самій таблиці: 11,8% — це результат машини, яка мала 80 тисяч спроб і незалежного суддю поруч. Ваш системний промпт, написаний руками в п’ятницю ввечері, стартує з гіршої позиції, і наскільки саме гіршої — ви не знаєте, бо не міряли.

Що насправді довело це дослідження

У методі цікавіше, ніж у результаті.

Промпт вдалося покращити рівно тому, що поруч стояв Semgrep. Він визначав, що таке провал, показував, у якому рядку той провал стався, і давав алгоритму сигнал, за яким рухатись. Заберіть статичний аналізатор — і оптимізувати не буде за чим, а перевірити результат буде нічим. Лишиться відчуття, що промпт став кращим.

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

Межі тут дві, і їх варто не плутати. The Batch додає від себе: оптимізували тільки ту частину системного промпта, яку може змінювати розробник, і тільки проти відомих класів вразливостей із каталогу CWE — як воно поводиться з класом, якого в каталозі немає, ніхто не перевіряв. Самі автори в розділі про обмеження пишуть про інше і, як на мене, неприємніше: промпт, оптимізований під одну модель, не обов’язково робить безпечною іншу. Тобто чужий «безпечний системний промпт», скопійований у свій проєкт під іншу модель, — це знову ставка. Прогнати процедуру самому коштує близько 150 доларів разової оплати за токени, і код для цього викладений.

Ще одна деталь, повз яку легко пройти. У тому ж випуску The Batch згадується системна картка Claude Mythos 5 — моделі, яка сама знаходить серйозні вразливості в чужому коді. Там задокументовані випадки, коли вона хибно заявляла, що перевірила код, не помічала суттєвих збоїв і пропускала проблеми безпеки в тому, що аналізувала. Це закриває коротку дорогу «нехай друга модель перевіряє першу»: другій моделі теж потрібен зовнішній суддя. Схожу пастку я вже розбирав на прикладі самонавчання агента без перевірки — цикл зворотного зв’язку без незалежного вимірювання не вчить нічого, він просто закріплює впевненість.

Тест на одне питання

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

Правило в промпті	Хто перевіряє виконання	Що це насправді
«Не видаляй без підтвердження користувача»	Сама модель	Ставка
Те саме + видалення через API — soft delete на 48 годин	Платформа	Контроль
«Не використовуй креденшели, не пов’язані із задачею»	Сама модель	Ставка
Токен зі скоупом на один проєкт і середовище	Провайдер	Контроль
«Пиши безпечний код, уникай SQL-ін’єкцій»	Сама модель	Ставка зі зміщеним шансом
Те саме + Semgrep у pre-commit	Лінтер	Контроль
«Не виводь персональні дані у відповіді»	Сама модель	Ставка
Те саме + агент фізично не має доступу до таблиці з ПД	Права доступу	Контроль

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

Різниця стає видимою в момент інциденту. Ставка не спрацювала — ви дізнаєтесь про це постфактум, з наслідків. Контроль не спрацював — ви дізнаєтесь про це в логах відмов, до наслідків.

Чотири рази поспіль, і промпт тут не допоміг

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

У мене працює редакція з агентів: одні пишуть матеріали, інші деплоять їх на сайти брендів. В інструкції агента, який відповідає за публікацію, прямим текстом написано: перед тим як закривати задачу, перевір, що pull request змерджений, а сторінка реально відкривається. Не «створений PR», а «стаття живе за адресою».

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

Найсмішніше тут — реакція автоматичної перевірки. Формальний аудит матеріалу в такому стані давав 10 з 10, бо дивився на поля в заголовку файлу, а не на те, чи існує сторінка. Дві зелені галочки поспіль, і жодна не про те.

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

Промпт я теж переписав, звісно. Але я більше не вважаю це виправленням.

Що варто покласти в системний промпт сьогодні

Називайте клас помилки, а не чесноту. «Пиши безпечний код» — це побажання. «Параметризуй усі SQL-запити, конкатенація рядків у запит заборонена» — це правило, яке модель може виконати. Базові 23% у Stanford отримали саме на другому варіанті; на першому було б гірше.

Пишіть процедуру для невизначеності, а не заборону. Найдорожча помилка агента в PocketOS сталась не тоді, коли він щось зруйнував, а на кілька секунд раніше — коли натрапив на розбіжність і вирішив розібратися сам. Заборона «не роби деструктивних дій» не описує, що робити натомість. «Натрапив на розбіжність між очікуваним і фактичним станом — зупинись і поверни опис розбіжності» — описує.

На кожне важливе правило — зовнішній чекер. Лінтер, статичний аналізатор, тест, підтвердження людини, скоуп токена, soft delete. Правило без чекера лишається в промпті, просто ви тепер знаєте його справжню вагу.

Міряйте свій промпт, а не вірте йому. Метод SecureForge масштабується вниз до однієї людини: візьміть двадцять типових запитів до свого агента, прогоніть через дві версії системного промпта, порахуйте провали за формальним критерієм. Це вечір роботи, і після нього ви говорите про промпт цифрами. Я користуюсь тим самим підходом, коли оцінюю новий AI-інструмент: спочатку критерій провалу, потім демо.

І окремим рядком, бо про це забувають частіше за все: системний промпт — не сховище. Він потрапляє в логи, в трасування і у відповідь моделі при вдалій атаці на витік інструкцій. Ключі, внутрішні адреси і персональні дані в ньому не тримають; про те, де їх тримати, я писав у матеріалі про те, як залишити дані клієнтів усередині компанії.

Чого в промпт класти не варто

Не варто класти туди те, що має виконуватись незалежно від того, як модель зважила контекст: права доступу, незворотність операцій, ліміти витрат, межу між середовищами. Кожен із цих пунктів у промпті виглядає як економія тижня роботи, а працює як обіцянка.

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

FAQ

Чи є системний промпт рівнем захисту?

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

Чому не можна просто написати в промпті «не роби нічого небезпечного»?

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

Скільки безпеки дає добре написаний системний промпт?

За даними SecureForge — з 20,1% до 11,8% у середньому, тобто мінус сорок відсотків відносно бази; в абстракті статті найкращий результат заявлений як зниження вразливостей до 48%. Обидві цифри стосуються вузького і добре вимірюваного класу: відомі вразливості в Python-коді, згенерованому за один хід. Для витоку даних і виклику інструментів існують свої бенчмарки на кшталт AgentDojo, але це вимір стійкості агента загалом, а не внеску системного промпта, тож переносити сюди «мінус сорок відсотків» не можна.

Чи захищає системний промпт від prompt injection?

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

З чого почати, якщо агент уже в проді?

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

Чи можна автоматично оптимізувати промпт у себе, без Stanford?

Так, і код SecureForge викладений відкрито — github.com/sisl/SecureForge, ліцензія дозволяє комерційне використання. Але спершу потрібна дешевша частина: формальний критерій провалу і двадцять реальних запитів. Без них оптимізувати нема за чим — рівно як у самому дослідженні.

Що далі

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

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

Якщо агент у вас уже в проді, а колонку заповнити нічим, приходьте на discovery-сесію. За годину зазвичай видно, які правила у вас працюють, а які просто написані.

Дивіться також:

• Blast radius AI-агента: чим міряти ризик замість токенів — чотири механізми, які звужують шкоду без заміни моделі.
• Reward hacking: як AI-агент зламає вашу метрику — чому заборона в промпті програє градієнту оптимізації.
• Самонавчання AI-агента не працює без перевірки — про ту саму залежність від незалежного вимірювання.
• Чому AI-агент помиляється: винен пошук, а не модель — сусідній шар, у якому теж винна не модель.

Джерела:

• SecureForge: Finding and Preventing Vulnerabilities in LLM-Generated Code via Prompt Optimization — Houjun Liu, Lisa Einstein, John Yang, Joachim Baumann, Duncan Eddy, Christopher D. Manning, Mykel Kochenderfer, Diyi Yang (Stanford), 8 травня 2026.
• Custom Prompts for Safer Code — розбір у випуску The Batch від 7 серпня 2026: метод, моделі, порівняльні цифри.
• Репозиторій SecureForge — Stanford Intelligent Systems Laboratory, відкритий код пайплайна.
• CWE Top 25 Most Dangerous Software Weaknesses — MITRE, каталог, з якого автори брали класи вразливостей.
• Semgrep — статичний аналізатор, який виконував роль незалежного детектора.
• Nine Seconds to Total Loss: The PocketOS Agent Database Deletion — технічний post-mortem інциденту, травень 2026.
• Your AI wants to nuke your database. Guardrails fix that. — Railway про рівні скоупу токенів і відкладене видалення в API, 29 квітня 2026.