Ваш ШІ-помічник для написання коду може перезаписувати ваші SSH-ключі так, що ви навіть не помітите цього. Wiz Research виявила вразливість «GhostApproval», яка дозволяє шкідливому символьному посиланню (symlink) на файл project_settings.json вказувати на приватні ключі, при цьому діалогове вікно підтвердження кожної дії показує лише назву symlink. Підтвердьте дію — і ви щойно надали помічнику необмежений доступ до ваших облікових даних.

Як працює експлойт

  • Зловмисник додає у репозиторій файл під назвою project_settings.json.
  • Цей файл не є звичайним JSON-файлом; це символьне посилання (symlink), яке перенаправляє на приватний ключ користувача ~/.ssh/id_rsa (або аналогічний).
  • Коли розробник просить ШІ-помічника «налаштувати робоче середовище» (set up the workspace), помічник переходить за symlink і готується записати дані у справжній файл SSH-ключа.
  • Діалогове вікно підтвердження, що з'являється, містить лише назву project_settings.json. Воно не розгортає symlink, щоб показати фактичний шлях на диску.
  • Натискання «Approve» надає помічнику дозвіл на зміну приватного ключа, що фактично компрометує особу користувача в усіх сервісах, які довіряють цьому ключу.

Помилка виявлена у шести популярних інструментах: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity та Windsurf. Усі вони показують однакове оманливе діалогове вікно, оскільки інтерфейс відображає отриману назву, а не розгорнуту ціль.

Чому діалогових вікон для кожної дії недостатньо

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

Що роблять вендори — і чому це важливо

  • Amazon, Google та Cursor уже виправили це.
  • Anthropic (розробник Claude Code) стверджує, що користувачі повинні підтверджувати лише те, що вони розуміють. Це ігнорує когнітивне навантаження, необхідне для виявлення symlink, і передбачає, що користувачі можуть миттєво перевірити кожен шлях до файлу — що є нереалістичною очікуваною поведінкою.
  • Cursor також розкрив окрему проблему під назвою DuneSlide, яка дозволяла зловмисникам виконувати код на машині без жодного запиту на підтвердження. Компанія виправила цю помилку, продемонструвавши, як швидко ці помічники можуть стати векторами атак, якщо перевірка дозволів є слабкою.

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

Обмежені дозволи: практична альтернатива

Замість запитів для кожної операції з файлами, розробники можуть встановити область дії (scope) для помічника перед його запуском:

  • Визначити дерево каталогів (наприклад, /src), які ШІ може читати або в які може записувати.
  • Будь-яка спроба звернутися до файлів поза цим деревом — наприклад, ~/.ssh/id_rsa — буде заблокована операційною системою або рівнем пісочниці (sandbox).
  • Область дії встановлюється один раз, що зменшує кількість рішень, які має приймати людина, водночас обмежуючи вплив помічника.

Обмеження області дії переводить модель безпеки з принципу «запитувати щоразу» на принцип «дозволяти лише необхідне». Це подібне до того, як середовища виконання контейнерів та мобільні ОС ізолюють (sandbox) додатки, обмежуючи збитки у разі виникнення проблем.

На що звернути увагу далі

  • Випуски виправлень від вендорів: Стежте за примітками до оновлень шести уразливих інструментів.

Підсумок

Експлойт GhostApproval доводить, що довіра до спливаючого діалогового вікна створює хибне відчуття безпеки. Поки кожен ШІ-помічник для написання коду не почне розгортати symlink і не показувати повні шляхи, розробникам слід впроваджувати обмежені дозволи на запис — чітко вказуючи помічнику, де він може працювати, ще до початку роботи. Ця проста зміна блокує найнебезпечніший клас атак, не викликаючи втоми від постійних кліків.

Джерело: dev.to/girish_r/your-coding-agents-approval-dialog-is-lying-to-you-ih1