Агентная IDE - это новый класс инструмента, и вместе с удобством она приносит поверхность атаки, которую легко недооценить. Один и тот же агент читает недоверенный текст, запускает команды в вашей оболочке, ходит в сеть через MCP и правит файлы репозитория. Каждая из этих способностей одновременно и польза, ради которой всё затевалось, и канал, по которому что-то может пойти не так. Модель угроз здесь начинается не с паранойи, а с честного перечня того, что агент вообще может задеть.
Наивный ход понятен и почти всегда первый: написать хорошие инструкции и считать, что этого достаточно. Строгая, вежливая, подробная формулировка в промпте или в AGENTS.md ощущается как управление - кажется, что если ясно сказать агенту, чего не делать, он не сделает. На этой уверенности и держится большинство ранних настроек: контроль живёт в тексте.
Ломается это на простом факте: текст, который читает модель, может её убеждать. Prompt injection - это не экзотика, а комментарий в коде, строка в README, docstring или тест, которые адресованы уже не человеку, а агенту и просят его сделать не то. Модель по своей природе поддаётся убеждению, и именно поэтому убеждение не должно менять ваши security-решения. Инструкция влияет на поведение, но не является границей: границу нельзя сформулировать словами внутри того, что сам же агент и интерпретирует.
Полезно разложить источники риска по строкам, чтобы каждый получил свой контроль, а не общий призыв быть осторожнее. Недоверенный репозиторий несёт инъекции и вредные скрипты; вывод агента - баги, небезопасные паттерны и галлюцинации; shell - разрушительные и внешние эффекты; MCP и ACP - утечку данных и действия третьей стороны; cloud - доступ к репозиторию, сети и секретам; plugin и extension - исполнение из цепочки поставки. Ниже эта карта сведена в таблицу источник - риск - контроль.
Профессиональный механизм - разделять влияние и enforcement. Инструкции помогают поведению и остаются полезными, но принуждение дают другие вещи: permissions, hooks, sandbox, branch protection и approvals. Они работают средствами системы, а не доброй волей модели, и потому не зависят от того, какой текст агент прочитал по дороге. Практический приём один: всё, что можно выразить правилом, выносите из промпта в permission, hook или sandbox - там оно становится границей, а не пожеланием.
Почему так, а не просто более строгий промпт. Потому что промпт для модели - это данные, которые она интерпретирует, а не гарантия исполнения. Cognition прямо предупреждает, что Devin может галлюцинировать, вносить баги в код и предлагать небезопасный код или процедуры, и рекомендует обычные инженерные меры: code review и branch protections, чтобы проверки выполнялись до слияния. Раз сам производитель не обещает корректности вывода, единственная надёжная граница лежит вне модели.
| Источник | Риск | Контроль |
|---|---|---|
| Недоверенный репозиторий | Инъекция промпта, скрипты, hooks | Restricted Mode, ревью, sandbox |
| Вывод агента | Баг, небезопасный паттерн, галлюцинация | Diff, тесты, ревью человеком |
| Shell | Разрушительный или внешний эффект | Permissions, проверка CWD, sandbox |
| MCP/ACP | Утечка данных, действие третьей стороны | Гранты инструментов, политика провайдера |
| Cloud | Доступ к репозиторию, сети, секретам | Политика VM, least privilege, аудит |
| Plugin/extension | Исполнение из цепочки поставки | Пиннинг, инспекция, admin allowlist |
Цена невнимания к этому различию конкретна. Недоверенный репозиторий, открытый без Restricted Mode, может увести агента инъекцией в постороннее действие. Вывод, принятый без ревью и тестов, вносит баг или небезопасный паттерн прямо в main. Широкий tool grant для MCP выносит данные за пределы, которые вы держали в голове. Радиус этих ошибок - реальные коммиты и утечки, а не строчка в логе.
Когда какой контроль оправдан, видно из той же карты. Для недоверенного кода - Restricted Mode, в котором агенты не запускаются, и просмотр перед доверием. Для вывода агента - diff, тесты и ревью человеком. Для shell - permissions, проверка рабочего каталога и sandbox. Для MCP и ACP - минимальные гранты инструментов и политика провайдера. Для cloud - политика VM, least privilege и аудит. Для plugin - пиннинг версии, инспекция и admin allowlist издателей.
Проверять безопасность стоит не вопросом звучит ли промпт надёжно, а состоянием enforcement. Включён ли Restricted Mode на незнакомом репозитории. Требует ли protected branch независимых проверок до слияния. Стоит ли deny на разрушительных командах и на путях с секретами. Прочитан ли diff перед принятием. Каждый из этих ответов - факт о системе, который можно предъявить, а не ощущение от текста.
Типичный провал - спутать влияние с контролем. Я же написал агенту не трогать .env вместо deny-правила на .env; доверяю выводу, потому что он выглядит разумно, без прогона тестов; ставлю plugin, не посмотрев издателя и источник обновлений. Признак один: контроль существует только как фраза в промпте и нигде больше. Перенесите его в permission, hook, sandbox или branch protection - и целый класс инцидентов просто перестаёт быть возможным.