У робочому процесі GitHub AI виявлено вразливість до ін'єкції підказок, яка може призвести до витоку приватних даних.Автор статті, джерело: 36Kr
Noma зазначила, що, хоча GitHub вже впровадив строгі захисні механізми, щоб запобігти такій ситуації, просте використання ключового слова «Additionally» спричинило непередбачувану поведінку моделі. Це призвело до того, що модель отримала доступ до вмісту файлу, який був обмежений, і опублікувала його у відкритих коментарях.
Традиційні моделі безпеки зазвичай припускають, що межі довіри забезпечуються кодом. У агентних системах межі довіри частково залежать від поведінки моделі, яка природним чином здатна виконувати інструкції. Для агентного ШІ атаки з впровадженням підказок стають аналогом SQL-ін’єкцій у веб-додатках: системна, цілісна категорія вразливостей, що вимагає таких самих системних стратегій та заходів захисту.Рекомендації з безпеки: Щоб зменшити ці ризики, дослідники Noma рекомендують ніколи не вважати вміст, що контролюється користувачем, надійним вхідним сигналом для AI Agent. Дозволи Agent повинні обмежуватися строго необхідним мінімумом, оскільки Agent з доступом до кількох сховищ стає дуже цінною мішенню для атак. Організаціям також слід обмежувати обсяг інформації, яку Agent може публічно розголошувати, особливо при відповідях на вміст Issue, і переконатися, що вхідні дані користувача були відповідно очищені або ізольовані від контексту інструкцій перед наданням їх моделі. Попередження галузі
Фракційний CTO Віджендра Малхотра прокоментував у LinkedIn, що відкриття Noma доводить: приватні сховища ніколи не були межею безпеки. Це насправді організаційна межа, яка діє лише тоді, коли всі, хто має доступ до вашого коду, — це люди, яких ви найняли. Агенти зламали це припущення. [...] Якщо агент має доступ до вашого приватного сховища, вважайте всі його дані зараз на відстані одного добре структурованого Issue від публічного розголошення.Користувач Reddit Significant_Sea_4230 зазначив:
Небезпека полягає не в тому, що агент «дуже розумний». А в тому, що він може бути підключений до надто багатьох контекстів, надто багатьох сховищ або мати надто широкі права токена.З іншого боку, користувач cH3332xr підкреслив:
Найцікавішим деталем є те, що “Additionally” обходить механізм: саме завантаження не змінилося, але цей зв’язуючий термін у вигляді захисного механізму перекласифікував його з “нової команди” на “продовження поточного завдання”. Це проблема межі прийняття рішень, а не проблема вмісту.Як останній коментар у спільноті, mcv на Hacker News сказав:
SQL-ін’єкція виникає через те, що система сприймає введення користувача як частину команди, а не як чисті дані, якими вона має бути. Ця проблема вирішується шляхом розділення цих двох елементів. Але ін’єкція підказок неможлива до уникнення, оскільки введення користувача є саме командою.Щоб дізнатися більше про технічні деталі та процес підтвердження концепції, прочитайте повний звіт на сайті Noma.
Посилання на оригінал: https://www.infoq.com/news/2026/07/gitlost-github-prompt-injection
Джерело: AI Frontier