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

AI-агент за границей доверия в security workflow

Именно это показывает Friendly Fire, exploit brief AI Now Institute от 8 июля. Исследователи Boyan Milanov и Heidy Khlaaf описали путь к remote code execution в Anthropic Claude Code CLI и OpenAI Codex CLI, когда эти инструменты используют как defensive security reviewers для сторонней или open-source библиотеки.

Масштаб важно не преувеличивать. Это не массовая атака на всех пользователей Claude или Codex. Нужны command-capable agent, untrusted codebase и автономный режим подтверждений: Claude Code в auto-mode или Codex в auto-review, как пишут AI Now и The Hacker News. В таком сценарии агенту дают репозиторий и просят проверить безопасность. Он читает обычные проектные тексты, решает, что относится к задаче, и может запустить локальную команду без остановки на человека.

Для AI Practice это важнее одной security-заметки. Именно такие агенты сейчас внедряют в code review, vulnerability triage, Sentry investigation, patch generation, dependency cleanup и CI assistance. Чем полезнее агент, тем больше инструментов он получает: shell, filesystem, package manager, repository access, иногда browser и secrets.

В этот момент он перестаёт быть чат-ботом. Это privileged automation с интерфейсом на естественном языке.

Что показал Friendly Fire

В публичном brief AI Now описана изменённая копия Python-библиотеки geopy. Исследователи добавили README-подсказку, wrapper script, decoy source file и precompiled binary. Публичный GitHub-репозиторий отдельно говорит, что binary stripped from malicious code.

Полезный урок не в payload. Его не нужно повторять в корпоративной инструкции. Урок в отказе границы: агент воспринимает текст репозитория как часть задачи и может перейти от “проанализируй проект” к “запусти команду, которую предлагает этот проект”.

AI Now указывает протестированные версии Claude Code CLI 2.1.116, 2.1.196, 2.1.198 и 2.1.199 с Claude Sonnet 4.6, Sonnet 5 и Opus 4.8, а также OpenAI Codex CLI 0.142.4 с GPT-5.5. Исследователи подают проблему как design weakness workflow, а не как один диапазон уязвимых версий.

Это не значит, что каждый запуск агента опасен. Это значит, что autonomous modes нельзя считать тем же самым, что assisted editing. Проверить свой репозиторий в локальной ветке — один риск. Проверять чужой код с включённым command execution — другой.

Почему хватает README

Security-команды много обсуждают MCP config, hooks, plugins и tool manifests. Это реальные риски. Friendly Fire неприятнее тем, что не требует специального agent config. Достаточно обычного текста в репозитории.

README должен влиять на читателя. Он объясняет, как собрать, протестировать и проверить проект. Для человека это нормально: человек может остановиться, спросить, зачем запускать binary, и заметить странность.

Агент устроен иначе. Он старается помочь, угадать следующий шаг и довести задачу до конца. Если policy разрешает часть команд без ручного подтверждения, текст репозитория становится дорожкой от untrusted data к локальному execution.

Это тот же класс проблем, что prompt injection через тикеты, issues, logs, web pages и tool output. Входные данные не являются “кодом” в старом смысле. Это текст, который агент читает перед выбором действия.

Это больше, чем один PoC

Friendly Fire идёт после нескольких похожих историй. Tenet Security в Agentjacking описывал fake Sentry errors через public DSN, которые попадали к coding agents через Sentry MCP. Tenet называл 2,388 exposed organizations и 85% success rate in controlled testing. Эти числа стоит читать как результат одного исследования, а не универсальную долю по индустрии.

The Hacker News связывает Friendly Fire с TrustFall и другими poisoned-repository/tool-output атаками. Sophos X-Ops 7 июля показал отдельный operational signal: AI coding agents в Windows endpoint telemetry могут вызывать правила, похожие на attacker behavior, включая credential access patterns, PowerShell, LOLBin-style downloads и persistence-like actions.

Методы разные. Это не одна уязвимость. Но operating problem одна: агент может быть benign, attacker-influenced или attacker-run, и имя процесса не отвечает, что именно происходит.

Для компаний вопрос меняется. Уже недостаточно спросить “хорошая ли модель?”. Надо спросить: “что этот агент может сделать, когда входные данные враждебны?”.

Почему компании всё равно будут использовать агентов

Безопасный ответ не “запретить AI agents”. Обычно это красиво звучит и плохо работает.

Агенты уже полезны в инженерной рутине. Они пишут тесты, объясняют чужой код, готовят pull requests, чинят простые ошибки, собирают первичный security report. В security work они могут суммировать findings, сравнивать dependency versions и превращать шумные alerts в черновик расследования.

Риск появляется, когда автономность дают раньше границ. Junior engineer в первый день не получает production credentials и право запускать случайные binaries из скачанного пакета. Агент тоже не должен.

Productivity-выигрыш реален. Но “AI assistant” не означает “low privilege”.

Новый default: сначала читать, потом исполнять

Для untrusted inputs безопасный default простой: читать можно, исполнять нельзя.

Если агент проверяет third-party repository, package, issue, Sentry event, log bundle или external pull request, он должен начинать в read-only mode. Он может смотреть файлы, писать отчёт, перечислять подозрительные команды и предлагать тесты. Он не должен запускать project-provided scripts, unknown binaries, package installs или network calls без явного подтверждения.

Подтверждение тоже должно быть осмысленным. Не маленькое окно “run command?” без контекста. Reviewer должен видеть, почему агент хочет это запустить, откуда пришла инструкция, какие файлы и сети затронуты, какие права есть у среды.

Для high-risk задач одного approval мало. Нужны disposable VM или container, throwaway credentials, запрет доступа к browser credential stores, SSH keys, cloud tokens и production repositories, ограниченный egress, tool-call logs и удаление среды после job.

Это не бюрократия. Так должна выглядеть privileged automation.

Что менять сейчас

Разделите trusted и untrusted workflows. Internal repo cleanup с обычным CI и branch protections — один policy. Security review чужого пакета — другой. Один глобальный режим агента для всего — плохая идея.

Отключите autonomous command approval для untrusted repositories и external telemetry. Если vendor даёт enterprise managed settings для блокировки опасных или auto modes, используйте их. В документации Claude Code есть managed settings и permission controls для организаций; такими настройками должны владеть security/platform teams, а не отдельные разработчики.

Выдавайте агентам отдельные identities. Агент не должен автоматически наследовать полный GitHub, cloud и production access разработчика. Read-only tokens лучше write tokens. Short-lived tokens лучше постоянных. Если токен не нужен, его не должно быть.

Уберите secrets из зоны доступа агента: environment variables, SSH keys, browser cookies, password managers, local cloud credentials. Sandbox с настоящими секретами разработчика внутри — это не граница, а удобная комната для атакующего.

Shell scripts, package installs, binary execution, browser automation и network access должны считаться high-risk actions. В untrusted contexts они требуют human approval или полного запрета.

Сделайте audit logs пригодными для расследования: input source, краткое reasoning summary, proposed tool call, approved command, process tree, network destination, file writes. Иначе после инцидента останется только “AI что-то сделал”.

Что должны дать vendors

Одних предупреждений “будьте осторожны” мало. Агентам нужны product-level trust boundaries.

Untrusted content должен сохранять label внутри системы: repository text, issue comments, logs, Sentry events, web pages, MCP output. Tool policy должна уметь сказать: этот источник можно учитывать для анализа, но он не может разрешать execution.

Permission model должна быть явной. “Autonomous” слишком расплывчато. Может ли агент запускать shell? Какие команды? Ставить packages? Выполнять binaries? Открывать network connections? Читать hidden files? Доступаться до browser profile? Использовать MCP tools? Писать вне workspace?

Enterprise admins нужны central controls: managed settings, policy enforcement, audit export, allowlists, deny rules и safe defaults для high-risk workflows вроде security review чужого кода.

MCP и tool ecosystems тоже должны соблюдать эту дисциплину. Tool result — не system instruction. Log line — не remediation plan. Ticket comment — не разрешение на команду.

Практический тест зрелости

AI adoption teams часто спрашивают, какую модель выбрать. Friendly Fire предлагает более полезный тест.

Может ли организация запустить агента на malicious repository без утечки реальных secrets? Может ли запретить исполнение project-supplied commands? Может ли показать, кто и почему подтвердил действие? Может ли не дать Sentry event или GitHub comment стать инструкцией? Может ли отозвать agent access, не ломая всю developer environment?

Если ответ нет, deployment не готов к автономной security work.

Агенты станут нормальной частью разработки. Но normal не значит harmless. CI runners нормальны, и компании всё равно их изолируют. Build systems нормальны, и secrets всё равно ограничивают. Агенты заслуживают того же подхода.

Практическое правило скучное и полезное: не спрашивайте, доверяете ли вы агенту. Решите, что ему разрешено делать, когда входные данные не заслуживают доверия.