Конфиг-файл стал новой зоной риска для AI-агентов в разработке

Есть привычный страх вокруг AI-инструментов для программирования: будто главная опасность в том, что модель однажды «подумает не то» и сама выполнит разрушительную команду. На практике всё оказалось менее кинематографично и гораздо неприятнее.

В нескольких недавних исследованиях проблема всплывает в одном и том же месте — не в самой модели, а в конфигурационных файлах проекта. Тех самых .json, .toml, .yaml и настроек IDE, которые разработчики часто просматривают вскользь или вообще считают служебным шумом.

С AI-агентами это уже не просто настройки. Конфиг может определить, какие команды агенту разрешено запускать, какие MCP-серверы подключать, какие хуки выполнять и куда отправлять запросы. И если такой файл лежит внутри репозитория, агент может принять его как часть доверенной рабочей среды.

Главная мысль простая: в эпоху AI coding agents конфигурационный файл всё чаще ведёт себя как исполняемый слой. А значит, относиться к нему нужно почти как к коду.

TrustFall: атака через «доверенную папку»

В мае 2026 года исследователи Adversa AI описали класс атак под названием TrustFall. Они проверяли Claude Code, Gemini CLI, Cursor CLI и GitHub Copilot CLI и пришли к неприятному выводу: агентные CLI могут запускать проектные MCP-серверы после подтверждения доверия к папке. В большинстве случаев диалог доверия устроен так, что пользователь легко нажимает «да» и не видит всей глубины последствий.

Сценарий выглядит почти буднично. Разработчик клонирует репозиторий, открывает его в AI-инструменте и подтверждает, что папке можно доверять. Внутри проекта лежит конфигурация, которая указывает агенту на MCP-сервер или другие проектные механизмы. После этого уже не модель «решает атаковать», а инструмент честно выполняет то, что ему разрешила конфигурация.

Именно это делает такие атаки опасными. Они не похожи на классический вирус, который пользователь скачал с подозрительного сайта. Всё происходит внутри привычного рабочего процесса: репозиторий, IDE, агент, настройки проекта.

Claude Code: когда проектные настройки становятся точкой входа

Check Point Research отдельно разобрала уязвимости в Claude Code. Исследователи показали, что вредоносные проектные конфигурации могли приводить к удалённому выполнению кода и утечке API-ключей. Проблема затрагивала механизмы вроде Hooks, MCP-серверов и переменных окружения.

Одна из уязвимостей, CVE-2026-21852, описана в NVD как проблема в процессе загрузки проекта: до версии 2.0.65 Claude Code мог позволить вредоносному репозиторию украсть данные, включая Anthropic API keys, до того, как пользователь подтвердит доверие к проекту.

В пересказе это звучит почти абсурдно: диалог о доверии есть, но опасная часть может сработать раньше или вокруг него. А ведь именно такие диалоги должны быть последней точкой, где человек успевает сказать: «Нет, этот проект я запускать не хочу».

Check Point сформулировала проблему довольно точно: конфигурационные файлы, которые раньше считались пассивными настройками, начинают влиять на выполнение команд, сеть и разрешения.

AWS Kiro и инъекция через инструкции

Похожая логика проявилась и в истории с AWS Kiro. Исследователь Йоханн Ребергер из Embrace The Red показал, как indirect prompt injection могла привести к изменению настроек Kiro и MCP-конфигов. AWS позже выпустила бюллетень, где указала, что проблема требовала локального доступа для внедрения инструкций, а в версии 0.1.42 были добавлены подтверждения действий в supervised mode.

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

Это уже другой уровень риска. Не «модель ошиблась», а «модель помогла переписать правила, по которым сама же работает».

Почему старые подходы плохо видят эту проблему

Обычные средства защиты привыкли смотреть на исполняемые файлы, подозрительные процессы, сетевые подключения, вредоносные зависимости. Это всё по-прежнему важно. Но AI-агенты добавили промежуточный слой: текстовые настройки, которые меняют поведение инструмента.

EDR может заметить выполнение опасной команды. Но он не всегда поймёт, что за минуту до этого изменился конфиг, который разрешил агенту запускать такие команды без подтверждения.

Google Cloud в материале о безопасности AI coding agents предлагает шире смотреть на файлы, которым агент доверяет: не только исходный код, но и то, что исполняется, инструктирует, подключает внешние сервисы или расширяет возможности инструмента.

Это хороший сдвиг в оптике. Раньше .vscode/settings.json, .claude/settings.json, .mcp.json или похожие файлы могли казаться скучной обвязкой. Теперь они становятся частью attack surface.

MCP сделал проблему заметнее

Model Context Protocol полезен именно потому, что даёт агенту доступ к инструментам: файловой системе, базам, API, внутренним сервисам, таск-трекерам, облакам. Но чем удобнее агенту работать, тем больше у него появляется прав.

Если MCP-конфиг подключает сервер с широкими полномочиями, хранит секреты или автоматически разрешает действия, он превращается в чувствительную часть проекта. Причём не всегда это выглядит опасно на ревью. Вроде бы обычный JSON. Вроде бы просто настройки. Но по факту — маршрут к данным, командам и внешним системам.

Здесь и появляется главное правило: конфиги AI-агентов надо ревьюить так же внимательно, как код, который запускается в CI/CD. Особенно если они могут подключать внешние инструменты, менять allowlist, задавать хуки или влиять на доверенные команды.

Что реально можно сделать

Полностью отказаться от AI-агентов в разработке вряд ли получится: слишком много пользы, слишком быстро они входят в рабочий процесс. Но запускать их «как есть» рядом с ключами, production-доступами и домашней директорией разработчика — плохая идея.

Базовые меры выглядят не экзотично, а почти скучно:

— запускать агентов в контейнере или отдельной изолированной среде;
— не хранить секреты в проектных конфигах;
— давать MCP-серверам минимальные права, а не доступ «ко всему»;
— отдельно ревьюить изменения в .claude, .mcp, .vscode, .cursor, .kiro и похожих директориях;
— не доверять репозиторию только потому, что он «выглядит как обычный проект»;
— логировать изменения конфигов, которые меняют права агента или подключают новые инструменты.

Sysdig отдельно подчёркивает, что AI coding agents могут выполнять команды, читать и менять файлы, видеть переменные окружения и взаимодействовать с API репозиториев. Это уже не автодополнение, а рабочий субъект с доступами.

Где здесь место Sigil

Автор исходной статьи на Dev.to предлагает свой ответ на эту проблему — инструмент Sigil. Его идея не в том, чтобы «запретить AI-агентов», а в том, чтобы следить за конфигурационными файлами на стороне хоста, оценивать риск изменений и отправлять события в лог или SIEM.

Это разумная мысль, даже если сам инструмент ещё нужно отдельно проверять в реальной эксплуатации. Смысл не в конкретном названии, а в подходе: конфиги AI-агентов нужно не только хранить в Git, но и наблюдать за ними как за живой частью безопасности.

Хорошая формулировка здесь такая: «этот файл изменился, и теперь агент может делать X». Именно такой уровень видимости часто отсутствует в командах.

Это не история про один баг

Самое неприятное в этой теме — она не сводится к одному инструменту. Claude Code, Kiro, Cursor, Gemini CLI, Copilot CLI, MCP-конфиги, IDE-настройки, rules-файлы — детали разные, но общая логика повторяется.

AI-агент получает всё больше автономии. Чтобы работать быстрее, он должен читать больше файлов, запускать больше команд и подключать больше инструментов. А значит, обычные проектные настройки становятся не просто фоном, а частью системы принятия решений.

Пока индустрия обсуждает большие и абстрактные риски искусственного интеллекта, более приземлённая проблема уже здесь: кто контролирует файлы, которым агент доверяет?

Итог

История с конфигами показывает, что безопасность AI-разработки будет гораздо менее романтичной, чем многие ожидали. Не «модель захватила компьютер», а обычный файл настроек разрешил лишнее, подключил не тот сервер или сработал до подтверждения доверия.

Это не делает AI-агентов бесполезными или опасными по умолчанию. Но меняет правила работы с ними. Конфигурация теперь часть кода, часть политики доступа и часть поверхности атаки одновременно.

Самая здоровая привычка здесь простая: не спрашивать только «что агент написал», а смотреть ещё и на то, по каким правилам ему разрешили действовать.

Источник: Dev.to (Ju571nk)

При подготовке также использовались данные Check Point Research, Google Cloud Blog, Cyberis, Embrace The Red, Xakep.ru и Pillar Security.