Безпека AGENTS.md: як сторонні файли керують ШІ-агентами

В одному випадку непримітного текстового файлу в теці Downloads вистачило, щоб ШІ-агент для програмування спробував установити шкідливий пакет. Ця стаття про безпеку AGENTS.md: що сталося, які файли інструкцій завантажують Codex, Claude Code і Cursor та які налаштування й заходи можуть запобігти шкоді.

Знахідка на комп'ютері клієнта та її наслідки

Постачальник рішень безпеки Forever Security з'ясував таке: на комп'ютері клієнта в теці Downloads лежав файл інструкцій під назвою AGENTS.md, який мав змусити ШІ-агента для програмування встановити npm-пакет. Цей файл не є програмою, але діє як інструкція до дії.

Що сталося: знахідка в теці Downloads, повторний тест і частка успіху

Відправною точкою стала реальна знахідка. Файл лежав у теці Downloads розробника. Ця тека водночас була робочим каталогом агента. Агент хотів установити npm-пакет function-color. За власними словами, Forever Security зупинила його ще до того, як запустився код. Як файл потрапив у теку, дослідники з'ясувати не змогли.

Пакет function-color підтягує ще один пакет під назвою function-flag. Той завантажує та запускає шкідливе програмне забезпечення для Windows. CloudSEK і Checkmarx називають цю кампанію MALFEX.

Повторний тест із Codex

Forever Security відтворила атаку в ізольованій віртуальній машині. Справжній файл наказував Codex зареєструвати сервер у файлі ~/.codex/config.toml і виконати команду, яка встановлює пакет. Оскільки ця конфігурація діє для всіх сесій Codex на комп'ютері, зміна працює постійно й у кожній теці. Частка успіху становила близько 90 відсотків.

Повторний тест із Claude Code

Для Claude Code використали інший файл. Підготовлений CLAUDE.md видавав себе за налаштування внутрішнього шлюзу й мав змусити агента записати сторонню адресу як ціль API у файл налаштувань проєкту. Тоді API-трафік ішов би на сервер дослідників. Це розкриває токен автентифікації сесії, а сервер може повертати команди, які агент виконує. Для таких записів Claude Code зазвичай вимагає підтвердження і часто відхиляє підозрілі. Лише довге обґрунтування, що звучало майже як документація для розробників, приблизно в половині випадків призвело до дозволу.

Обидва показники не можна напряму порівнювати. Це різні агенти, різні файли та різні цілі. Розмір вибірки й конфігурація тесту (пісочниця, режим підтвердження) невідомі.

Телеметрія: наскільки поширений запуск у теці Downloads?

Приблизно половина клієнтів Forever Security запускає агента для програмування в теці Downloads, близько чверті сесій відкриває браузер. BleepingComputer називає понад 1300 сесій Claude Code з цієї теки. Обидва дані є твердженнями постачальника про власне коло клієнтів, незалежної перевірки немає. Чи справді зловмисники на практиці підкидають такі файли через завантаження в браузері, не доведено. Proof of Concept завантажував лише нешкідливий файл.

Безпека AGENTS.md: чому сторонні файли інструкцій становлять ризик

Під час запуску агенти для програмування читають файли інструкцій із робочого каталогу. У них містяться інструкції зі збирання, правила стилю чи команди для тестів. Агент сприймає цей вміст як вказівки користувача. Він не розрізняє надійно, чи файл походить від команди, чи зі стороннього джерела. У цьому суть непрямої prompt injection проти агента для програмування: інструкція надходить не з поля введення, а з контексту.

Дві самі по собі нешкідливі властивості разом утворюють ланцюг. По-перше, агенти довіряють файлам у відкритій теці. По-друге, вебсайти можуть без запиту класти файли в теку Downloads, якщо браузер так налаштований. Chrome, Edge і Firefox за замовчуванням зберігають у цю теку, не питаючи про місце збереження, і показують лише сповіщення. Brave у тесті спершу перепитав. Файл має ту назву й той вміст, які задає сайт.

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

Браузер не єдиний шлях

У цьому випадку в центрі уваги тека Downloads, але не лише вона. NVIDIA Developer Blog описує споріднений шлях: скомпрометований пакет залежностей сам створює AGENTS.md. Також клоновані репозиторії, розпаковані архіви та скрипти збирання можуть занести сторонні файли інструкцій у теку проєкту. Отже, місце запуску зменшує поверхню атаки, але не усуває її.

Оцінка: що кажуть дослідники та виробники

Дослідники Forever Security заявляють, що OpenAI та Anthropic тут нічого виправляти. Агент виконує свій файл інструкцій так, як передбачено, подібно до браузера, що відображає фішингову сторінку. Це оцінка дослідників. Власної заяви виробників щодо цієї атаки обидва звіти не містять. BleepingComputer лише зазначає, що обидва виробники рекомендують запускати агентів у відповідному каталозі проєкту. Отже, відповідальність лежить на користувачах і на організаціях, які застосовують агентів.

Ризики автономних агентів є ширшою темою. Статті про владу без контролю у ШІ-агентів і про епоху ШІ-агентів пояснюють, чому агентам із власними правами на дії потрібні інші заходи захисту, ніж класичному програмному забезпеченню.

Які файли інструкцій завантажують Codex, Claude Code і Cursor

Вирішальне значення має те, що вважається текою проєкту: тека, у якій запущено агента. Хто запускає агента в теці Downloads, робить кожен файл у ній контекстом проєкту. Наведений нижче огляд узагальнює документацію виробників (станом на 26.10.2026). Документація швидко змінюється, у разі сумніву діє її актуальна версія.

Codex

Згідно з документацією, Codex спочатку читає глобальний файл у каталозі Codex (~/.codex, змінюється через CODEX_HOME), а саме AGENTS.override.md або AGENTS.md. Далі йдуть файли від кореня проєкту, зазвичай кореневого каталогу Git, до поточної теки. У кожній теці враховується щонайбільше один файл: AGENTS.override.md, AGENTS.md або налаштована запасна назва. Загальна межа становить 32 KiB. Якщо корінь проєкту не знайдено, враховується лише поточна тека. Саме це стосується теки Downloads, адже там зазвичай немає Git-репозиторію.

Claude Code і безпека CLAUDE.md

Згідно з документацією про пам'ять, Claude Code завантажує CLAUDE.md і CLAUDE.local.md з робочого каталогу та з усіх каталогів над ним, а за потреби й з підтек. До цього додаються ~/.claude/CLAUDE.md, керована системна політика та файли в .claude/rules/. Для безпеки CLAUDE.md це означає: занадто висока точка запуску, наприклад домашній каталог, теж збільшує поверхню атаки, бо зчитуються файли над нею та поруч.

AGENTS.md Claude Code читає (згідно з документацією, починаючи з версії 2.1.277). За замовчуванням це відбувається лише тоді, коли в робочому каталозі або вище немає CLAUDE.md чи CLAUDE.local.md. Це можна змінити через налаштування інструкцій проєкту: claude-md-or-agents-md є стандартом, claude-md-and-agents-md читає обидва, managed-only допускає лише централізовано керовані інструкції.

Cursor

Згідно з документацією, Cursor підтримує правила проєкту в .cursor/rules/ (файли у форматі .mdc, також у підтеках) і AGENTS.md у корені проєкту та в підкаталогах. Вкладені файли діють у своїй області, перемагає конкретніший. До цього додаються особисті User Rules у налаштуваннях і Team Rules через панель керування.

Конфігураційні файли як справжня ціль

Випадок показує, що файл інструкцій часто лише інструмент. Ціллю є конфігураційні файли, у яких зміна діє тривало. Для Codex це ~/.codex/config.toml, зміна якого зачіпає всі сесії. Для Claude Code це файл налаштувань .claude/settings.json, у якому через змінну середовища можна задати ціль API. Тому обидва файли належать до списку файлів, які агент не може змінювати без підтвердження.

Захист ШІ-агентів для програмування: дозволи, хуки та пісочниця Codex

Напрошується питання, чи достатньо просто не використовувати теку Downloads.

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

Правила дозволів у Claude Code

Claude Code підтримує правила рівнів allow, ask і deny для кожного інструмента (документація щодо дозволів). За замовчуванням агент питає перед командами оболонки та змінами файлів. Правило deny діє навіть тоді, коли агент хоче виконати файл інструкцій. Приклад для файлу .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

Запис відповідає прикладам із документації: правила Bash порівнюють текст команди з * як шаблоном, правила шляхів для читання й редагування використовують синтаксис gitignore, ~/ означає домашній каталог. Зміни файлів регулюються через Edit(…), правила для Write, згідно з документацією, не перевіряються щодо шляхів. До того ж блокування команди не є гарантією, бо тієї самої мети часто можна досягти іншим викликом. Для неминучого призначені хуки та пісочниця.

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

Хуки: блокування незалежно від моделі

Хук PreToolUse запускається перед викликом інструмента і може його заблокувати, навіть якщо модель вважає виклик правильним. Посібник із хуків показує схему: скрипт читає вхідні дані як JSON зі стандартного введення і завершується з кодом виходу, щоб заблокувати. Реєструється він у файлі налаштувань:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Скрипт block-installs.sh за допомогою jq читає команду з поля tool_input.command, перевіряє її за списком заборон (наприклад npm install або поєднання curl і оболонки) чи краще за allowlist і в разі збігу повідомляє причину у стандартний потік помилок із кодом виходу 2. Другий, маловідомий важіль — хук InstructionsLoaded. Він протоколює завантажені файли інструкцій. Однак, згідно з документацією, він не спрацьовує для AGENTS.md, завантаженого через налаштування, а лише тоді, коли його імпортує CLAUDE.md. Тому команді не варто покладатися лише на нього.

Централізовані вимоги через Managed Settings

Для команд найдієвішим важелем є керовані налаштування. Згідно з документацією щодо Managed Settings, permissions.deny, sandbox.enabled і env можна примусово задати централізовано. Тоді підкинуту через файл інструкцій ціль API, як у тесті з Claude Code, було б значно важче нав'язати. Для ясності: це висновок із документації, а не доведений ефект у випадку Forever Security.

Codex: підтвердження, рівень довіри та режими пісочниці

Для пісочниці та дозволів Codex, згідно з документацією щодо підтверджень і безпеки, діють два рівні. Політика підтверджень визначає, коли Codex перепитує (наприклад on-request або never). Режим пісочниці визначає, що технічно можливо: read-only, workspace-write або danger-full-access. У режимі workspace-write мережа за замовчуванням вимкнена.

До цього додається рівень довіри для кожного проєкту в ~/.codex/config.toml (trust_level). Згідно з документацією, у теках під контролем версій діє режим Auto, тобто запис у робочій області з підтвердженням. У теках без контролю версій діє read-only, доки каталог не позначено як довірений. Тека на кшталт Downloads без такої позначки вважається недовіреною. Ризик виникає, коли користувачі підтверджують діалог довіри. Прапорець –yolo прибирає пісочницю та підтвердження і не має місця в командних вимогах. У якій конфігурації тестувала Forever Security, не повідомлялося, тому невідомо, чи спрацювали в тесті стандартні рівні захисту.

Cursor

Однозначних даних виробника щодо підтверджень для термінала в Cursor немає. Тому тут лише порада залишати підтвердження для команд термінала ввімкненими та перевіряти актуальну документацію виробника.

Пісочниця та ізоляція: обмежити шкоду, навіть якщо агент виконує файл

Пісочниця обмежує, що може зробити агент, навіть якщо він виконує сторонню інструкцію. Пісочниця Claude Code дозволяє запис у робочий каталог і тимчасові теки. Мережевий доступ іде через проксі зі списком дозволених доменів, який за замовчуванням порожній. Захищені шляхи, як-от налаштування Claude Code, стартовий файл оболонки .bashrc і Git-хуки, залишаються захищеними від запису. Приклад:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

Документація називає й обмеження. Пісочниця за замовчуванням вимкнена. Доступ на читання широкий, облікові дані потрібно блокувати цілеспрямовано. Захист діє лише для команд оболонки та їхніх дочірніх процесів, а не для вбудованих файлових інструментів, MCP і хуків. Без allowUnsandboxedCommands: false невдалу команду можна повторити поза пісочницею. У Windows вона не працює нативно, натомість використовується WSL2. Проти шкідливого коду вона не є повною межею. Для сильної ізоляції кращим вибором є контейнери або віртуальні машини.

Allowlist для мережі та одноразове середовище

Такий allowlist ускладнив би завантаження пакета та перенаправлення API. Це оцінка, а не доказ у цьому випадку. Невідомий код належить в одноразове середовище: контейнер, VM або Dev Container, без облікових даних основного профілю. Токени мають бути короткоживучими. У разі підозри рекомендується вважати токен автентифікації скомпрометованим і оновити його.

Налаштування браузера для завантажень

Проти тихих завантажень допомагає налаштування, яке перед кожним збереженням питає про місце. У Chrome воно має назву на кшталт "Запитувати, де зберігати кожен файл перед завантаженням" і розташоване в налаштуваннях у розділі «Завантаження». Edge і Firefox мають аналоги, назви відрізняються залежно від версії (Firefox: Налаштування, Загальні, Файли та програми). Brave у тесті BleepingComputer перепитував сам. Як альтернативу теку завантажень можна перенести в місце, яке ніколи не слугує робочим каталогом. Додатковим варіантом є псевдонім оболонки або хук, що відмовляє в запуску в ~/Downloads.

Чекліст для команд і політика використання агентів для програмування

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

• Агентів запускають лише в кореневому каталозі довіреного репозиторію. Downloads, робочий стіл і домашній каталог під забороною.
• Сторонні файли, як-от AGENTS.md, CLAUDE.md або .cursor/rules, читають перед відкриттям щойно клонованого чи розпакованого проєкту.
• Запити дозволів і пісочниця залишаються активними. Автоматичні режими та прапорці на кшталт –yolo працюють лише в ізольованих середовищах.
• Мережевий доступ іде через allowlist, облікові дані зберігаються поза досяжністю, токени короткоживучі.
• Агенти встановлюють пакети лише після дозволу, з lockfile та перевіркою реєстру. Як швидко один пакет підтягує інші, показує випадок із function-color і function-flag.
• Налаштування керуються централізовано. Зміни в ~/.codex/config.toml і .claude/settings.json відстежуються.
• Завантажені файли інструкцій протоколюються, наскільки це дозволяють інструменти.
• План реагування на інциденти: зупинити сесію, оновити токени й ключі, перевірити конфігураційні файли, відстежити встановлення пакетів.

Організації з обов'язками щодо інформаційної безпеки включають таких агентів у своє управління ризиками. Це стосується дозволу на використання, конфігурації та підтвердження того, що правила діють. Стаття про Agentic Coding описує, як організувати їх використання в командах розробників.

Зразок політики

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

Перевірка власних вебсайтів і систем

Випадок стосується насамперед комп'ютерів розробників. Хто сам пропонує файли для завантаження, своїм вебсайтом стає частиною ланцюга. Перевірка вебсайту показує, які скрипти та заголовки віддає сторінка, але перевіряє лише сторінку, а не комп'ютери розробників. Для систематичної перевірки безпеки в командах відправною точкою можуть бути Web Security Checks.

Висновок

Відповідальність лежить на користувачеві, межу встановлює техніка!

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

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