Безпековий імператив: Чому традиційні моделі безпеки розриваються, коли агенти штучного інтелекту торкаються коду

У квітні 2023 року Samsung виявила, що її інженери випадково витягнули конфіденційну інформацію до ChatGPT. Але це був випадковий випадок. Тепер уявіть, що ці репозиторії коду містили навмисно закладені інструкції, невидимі для людей, але оброблені штучним інтелектом, призначені для витягування не тільки коду, але й кожного ключа API, даних бази даних та токена служби, до якого штучний інтелект міг дістатися. Це не гіпотетично. Дослідники безпеки вже продемонстрували, що ці “невидимі інструкції” атаки працюють. Питання не в тому, чи це станеться, а коли.

Кордон, який більше не існує

Тривалий час ми будували безпеку на фундаментальній припущенні: код – це код, а дані – це дані. Встановлення параметрів запитів викорало нас до параметризації запитів. Перехрестне скриптинг навчив нас уникати виведення даних. Ми навчилися будувати стіни між тим, що програми роблять, і тим, що вводять користувачі.

З агентами штучного інтелекту цей кордон випарувався.

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

Це представляє фундаментальний розрив від всього, що ми знаємо про безпеку застосунків. Традиційні синтаксичні брандмауери, які шукають зловмисні шаблони, такі як DROP TABLE або теги , повністю терплять невдачу проти атак природною мовою. Дослідники продемонстрували техніки “семантичної заміни”, де заміна “ключів API” на “яблука” в промптах дозволяє атакувачам повністю обійти фільтри. Як ви можете брандмауер намір, коли він маскується під безневинну розмову?

Реальність нуль-кліків, про яку ніхто не говорить

Ось що більшість команд безпеки не розуміє: ін’єкція промпту не вимагає від користувача нічого вводити. Це часто експлойти нуль-кліків. Агент штучного інтелекту просто сканує репозиторій коду для рутинної задачі, переглядає запит на витяг або читає документацію API, і це може спровокувати атаку без будь-якої взаємодії людини.

Розгляньте такий сценарій, заснований на техніках, які вже довели дослідники: зловмисна особа вкладає невидимі інструкції в HTML-коментарі всередині документації популярної відкритої бібліотеки. Кожен помічник штучного інтелекту, який аналізує цей код, незалежно від того, чи це GitHub Copilot, Amazon CodeWhisperer чи будь-який інший корпоративний помічник кодування, стає потенційним збирачем облікових даних. Одна скомпрометована бібліотека може означати тисячі вразливих середовищ розробки.

Небезпека не в самому моделі LLM; це агентство, яке ми йому надаємо. Момент, коли ми інтегрували ці моделі з інструментами та API, дозволяючи їм витягувати дані, виконувати код та доступ до секретів, ми перетворили корисних помічників на ідеальні вектори атак. Ризик не зростає з інтелектом моделі; він зростає з її підключенням.

Чому поточний підхід приречений

Промислова галузь зараз одержима “вирівнюванням” моделей та будівництвом кращих брандмауерів промптів. OpenAI додає більше перил. Anthropic зосереджується на конституційному штучному інтелекті. Усі намагаються створити моделі, які не можуть бути обмануті.

Це програшна битва.

Якщо штучний інтелект достатньо розумний, щоб бути корисним, він достатньо розумний, щоб бути обманутим. Ми потрапили в те, що я називаю “пасткою санітарії”: припущення, що краще фільтрування вхідних даних врятує нас. Але атаки можуть бути приховані як невидимий текст в HTML-коментарях, поховані глибоко в документації або закодовані способами, яких ми ще не уявляли. Ви не можете санітаризувати те, чого ви не можете контекстно зрозуміти, і контекст саме той, що робить моделі LLM потужними.

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

Архітектурний зсув, якого нам потрібно

Ми зараз перебуваємо в “фазі патчування”, відчайдушно додаючи фільтри вхідних даних та правила валідації. Але так само, як ми врешті-решт дізналися, що запобігання ін’єкції SQL вимагає параметризованих запитів, а не кращого.escape рядків, нам потрібно архітектурне рішення для безпеки штучного інтелекту.

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

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

1. Авторизуватися за допомогою своєї верифікованої ідентифікації (а не збереженого секрету)

2. Отримувати тільки-у-час креденціали, які дійсні лише для цієї конкретної задачі

3. Мати ці креденціали, які автоматично закінчуються через секунди або хвилини

4. Ніколи не зберігати або навіть “бачити” довгоживучі секрети

Появилися кілька підходів. Ролі AWS IAM для облікових записів служби, Ідентифікація робочого завантаження Google, Динамічні секрети HashiCorp Vault та спеціальні рішення, такі як Zero Trust Provisioning Akeyless, все вказує на цю безсекретну майбутнє. Деталі реалізації різняться, але принцип залишається: якщо у штучного інтелекту немає секретів для крадіжки, ін’єкція промпту стає значно меншою загрозою.

Середовище розробки 2027 року

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

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

Це не просто технічна еволюція; це фундаментальний зсув моделей довіри. Ми переходимо від “довіряй, але перевіряй” до “ніколи не довіряй, завжди перевіряй і припускай компрометацію”. Принцип найменших привілеїв, довго проповідуваний, але рідко практикуваний, стає непоговорним, коли ваш молодший розробник – це штучний інтелект, який обробляє тисячі потенційно зловмисних вхідних даних щодня.

Вибір, з яким ми стикаємося

Інтеграція штучного інтелекту в розробку програмного забезпечення є неминучою і в основному корисною. GitHub повідомляє, що розробники, які використовують Copilot, виконують завдання на 55% швидше. Прибутки продуктивності реальні, і жодна організація, яка хоче залишитися конкурентоспроможною, не може їх ігнорувати.

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

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

Питання для кожного CISO, кожного керівника інженерії та кожного розробника просте: Коли ін’єкція промпту буде успішною в вашому середовищі (і це буде), що знайде атакувач? Він виявить скарбницю довгоживучих облікових даних або знайде агента штучного інтелекту, який,尽管 скомпрометований, не має секретів для крадіжки?

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

OWASP уже визначила ін’єкцію промпту як #1 ризик у своєму Топ-10 для застосунків великих мовних моделей.NIST розробляє керівництво щодо архітектур нульового довіри. Фреймворки існують. Єдине питання – це швидкість реалізації проти еволюції атак.

Bio: Рафаель Ангел є співзасновником і технічним директором Akeyless, де він розробив патентовану технологію шифрування нульового довіри компанії. Як досвідчений програміст з глибокими знаннями в області криптографії та безпеки хмарних обчислень, Рафаель раніше служив старшим програмістом у дослідницькому центрі Intuit в Ізраїлі, де він будував системи для управління ключами шифрування в публічних хмарних середовищах та проектував служби автентифікації машин. Він має ступінь бакалавра комп’ютерних наук у Єрусалимському коледжі технологій, який він здобув у віці 19 років.