AI coding agents теперь часть execution path#
Последний пост Docker Blog открывает новую серию «Coding Agent Horror Stories», но полезная часть здесь не в хоррор-подаче. Главное — модель доверия.
AI coding agents больше не просто autocomplete с более удобным интерфейсом. Во многих командах они уже читают локальные файлы, запускают shell commands, редактируют код, запрашивают сервисы и работают внутри реальных developer environments. Docker ссылается на Anthropic’s 2026 Agentic Coding Trends Report, где говорится, что разработчики используют AI примерно в 60% своей работы. В посте также отмечается более широкий сдвиг: от одиночных agents к скоординированным группам agents, которые могут сжимать работу, раньше занимавшую часы или дни, до минут.
История про productivity реальна. Именно поэтому security-проблема важна.
Инструмент, который может быстро доставить feature, может так же быстро внести плохое изменение. Coding agent, способный refactor большого codebase, может также удалить файлы, запустить destructive commands или затронуть системы, к которым он вообще не должен был иметь доступ. В посте Docker утверждается, что incidents за последние шестнадцать месяцев показывают: это уже не теоретический класс отказов.
Компания говорит, что публично задокументированные failures включали названных victims, screenshots поведения agents и в некоторых случаях извинения vendors. Также утверждается, что по состоянию на февраль 2026 года как минимум десять задокументированных incidents в шести крупных AI coding tools были публично связаны с agents, действовавшими без достаточных границ. Среди названных tools — Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork и Cursor.
К этим заявлениям стоит относиться с правильной осторожностью. Docker — vendor, который продает containment-историю через Docker Sandboxes. Но центральная risk model не зависит от продуктового pitch Docker. Она следует из того, как работают эти tools.
Главный риск — inherited privilege#
Docker описывает типичный agent loop так: observe, plan, act, repeat.
Разработчик дает agent задачу. Agent собирает context. Он читает файлы. Может смотреть logs. Может видеть environment variables. Может вызывать tools. Может писать файлы, запускать tests, выполнять shell commands, обращаться к APIs, а затем решать, что делать дальше, на основе результата.
Важная деталь проста: agent обычно запускается как developer.
Если shell session имеет доступ к repository, agent имеет доступ к этому repository. Если cloud credentials присутствуют в environment, agent может суметь их использовать. Если production database connection string лежит в локальном файле, который попадает в context, agent может его обработать. Если у разработчика есть admin rights, agent может унаследовать практический эффект этих прав.
Часто нет чистой identity boundary между «human developer» и «agent acting on behalf of developer». Во многих setups agent — это просто еще один process, работающий с permissions, которые уже доступны в workspace.
Это меняет то, как команды должны думать об approval. Chat assistant предлагает. Coding agent действует. Как только tool может выполнять commands, редактировать файлы и вызывать services, он должен обсуждаться в той же security-плоскости, что и build scripts, CI runners, deployment bots, internal automation и contractor laptops.
Agent опасен не потому, что он malicious. Он опасен потому, что он полезный, быстрый и часто over-permissioned.
Autonomy меняет failure mode#
Традиционное software все еще может удивлять пользователей, но его поведение ограничено прописанными code paths. AI coding agent устроен иначе. Он принимает решения во время runtime на основе меняющегося prompt, меняющегося context и доступных tools.
Это значит, что рискованный шаг может быть не известной malicious instruction. Это может быть внешне разумный plan, сформированный внутри task loop.
Docker приводит примеры важных решений: agent решает, что drop и recreate table — чистый способ решить schema issue, или что удалить directory быстрее, чем аккуратно ее pruning. Эти примеры поданы как failure modes, а не обязательно как конкретные новые incidents в процитированном source material.
Паттерн все равно валиден. Model принимает решение. Execution layer выполняет его. Если нет confirmation step, policy boundary и sandbox, человек может увидеть результат только после того, как действие уже произошло.
Именно здесь обычные привычки разработчиков становятся слабыми controls. Developer может доверять своему terminal, потому что знает, что именно набирает. Но agent-driven terminal меняет actor. Command все еще запускается локально. Credentials все еще могут быть локальными. Logs все еще могут показывать developer identity. Но непосредственное решение приняло software, интерпретирующее задачу.
Это усложняет auditing. И делает blast-radius control более важным.
Security-категории знакомы#
Docker говорит, что задокументированные failures группируются вокруг критических risk categories, с видимыми примерами destructive changes, data exposure, unsafe command execution и unintended access to systems. Даже если часть конкретных историй нужно проверять отдельно, сами категории не новые. Новое — actor и скорость.
Раньше команда могла рассматривать такие риски как проблему junior developer, плохо написанного script или misconfigured CI job. Теперь похожий риск появляется в интерактивной developer workflow, где agent может переходить от чтения context к выполнению действий за секунды.
Поэтому вопрос не в том, можно ли «доверять model». Это слишком абстрактная постановка. Практический вопрос другой: что именно agent может прочитать, что может изменить, какие commands может выполнить, какие credentials доступны в runtime и где останавливается автоматическое действие.
Если agent имеет read access ко всему home directory, write access к repository, доступ к shell, network, package managers и cloud credentials, то prompt-level rules вроде «не делай опасных действий» — слабая защита. Они полезны как UX-намерение, но не как security boundary.
Что делать командам#
Самый практичный вывод: относиться к coding agents как к semi-autonomous execution environment, а не как к расширенному чату.
Минимальный baseline должен быть таким:
- запускать agents в изолированном workspace, а не в полном developer environment;
- давать только нужные файлы и directories, а не весь home directory;
- не передавать production secrets в agent runtime;
- использовать short-lived и scoped credentials вместо постоянных keys;
- разделять read-only задачи и задачи с правом изменения;
- требовать explicit approval для destructive commands, database operations, network calls и package installs;
- логировать не только итоговый diff, но и commands, tool calls и files touched;
- запускать tests, scanners и policy checks до merge, даже если код написал agent;
- держать production доступ вне локального agent loop;
- регулярно пересматривать allowlist tools и permissions.
Это не означает, что coding agents нельзя использовать. Наоборот, их полезность делает containment обязательным. Чем быстрее agent может работать, тем меньше времени у человека заметить ошибку до эффекта.
Хорошая policy здесь не должна начинаться с запрета. Она должна начинаться с inventory: какие agents используются, где они запускаются, какие repositories видят, какие commands могут выполнять, какие secrets доступны и кто approving их действия. Без этого организация фактически внедряет новую automation layer без threat model.
Bottom line#
Docker продвигает собственное решение, поэтому отдельные claims стоит читать критически. Но общий сигнал правильный: AI coding agents перешли из области assistant UX в область execution risk.
Главная ошибка — считать, что безопасность agent определяется качеством prompt. Prompt важен, но границей он не является. Границы должны быть техническими: sandbox, least privilege, scoped credentials, approvals, audit logs и policy enforcement.
Если agent может действовать как developer, он должен быть ограничен не хуже, чем любой другой actor с доступом к codebase и infrastructure. Иначе команда получает не ускоренного помощника, а ускоренный blast radius.