Большинство программ безопасности строилось вокруг одного допущения, которое никто не записал: тот, кто держит credentials, — человек. Человек, который устаёт, медленно читает и замечает, когда README вдруг просит отправить файл .env куда-то по почте. Coding-агенты ломают это допущение. Они держат те же токены, что и ваши инженеры, читают каждый файл и веб-страницу, на которые вы их направите, и действуют со скоростью машины.
Это не делает агентов уникально опасными. Это делает их новой категорией актора, для которой ваши контроли не проектировались. За последние месяцы команда безопасности Anthropic опубликовала связку материалов ровно на эту проблему — руководство CISO по agentic AI, разбор того, как они защищают собственный AI-native SDLC, руководства по Zero Trust для агентов, по LLM-сканированию кода и по подготовке к AI-ускоренной атаке. Этот пост — мой инженерный синтез: что на самом деле нового в модели угроз, какие контроли выдерживают проверку и как внедрить их, не превратив rollout агентов обратно в очередь тикетов.
Если вы читали пост про AI-native SDLC, считайте этот главой о безопасности, лежащей под ним.
Почему агенты меняют модель угроз
Классический Zero Trust говорит: по умолчанию не доверяй ничему, проверяй каждый запрос, предполагай взлом. Всё это по-прежнему применимо. Меняется то, кто делает запросы и что он читает перед тем, как их делать.
У агента охват service account’а, импровизация человека и ни капли человеческого чутья на «эта инструкция выглядит странно». Важны три свойства:
- Агенты действуют на основании контента, а не только команд. Всё, что агент читает — текст issue, README зависимостей, веб-страницы, выводы инструментов, тестовые fixtures, — становится частью его принятия решений. Если атакующий может написать любую часть этого контента, у него есть канал в вашего агента.
- Агенты используют легитимные permissions. Большинство инцидентов с агентами не будут выглядеть как взлом. Они будут выглядеть как авторизованная идентичность, делающая то, чего никто не предполагал. Контроль доступа, который спрашивает только «разрешена ли этой идентичности такая операция?», пропустит это.
- Агенты становятся способнее, хотя вы ничего не меняли. Апгрейд модели может открыть поведение, которое ваша исходная оценка рисков не рассматривала. В руководстве для CISO есть хороший пример: агент реагирования на инциденты после апгрейда модели, без изменений в инструментах и промптах, начал посреди инцидента просить другого агента написать фикс кода. Человеческий review-гейт поймал это до продакшена — в этом и смысл.
Тем временем внешний мир тоже ускоряется. Материал Anthropic о подготовке к атаке утверждает, что модели сжимают время от обнаружения уязвимости до рабочего эксплойта, и защитникам стоит планировать рост числа отчётов об уязвимостях на порядок примерно за два года. Ваши агенты работают на инфраструктуре, подверженной тому же ускорению.
Ландшафт угроз на нужном вам уровне
Буду держаться концептуального уровня. Для проектирования контролей рецепты эксплойтов не нужны; нужны категории.
Prompt injection
Инструкции, спрятанные в контенте, который читает агент, и нацеленные на перенаправление его действий. Это определяющий риск агентов, а честный статус таков: защиты на уровне модели улучшаются, но никто заслуживающий доверия не утверждает, что доля успеха равна нулю. Относитесь к injection как к фишингу — это то, что вы снижаете и сдерживаете, а не «решаете».
Излишне рьяные и ошибочные действия
Это то, что команды недооценивают. Разбор Anthropic про auto mode в Claude Code каталогизирует реальные внутренние инциденты, которые вообще не были атаками: агент, истолковавший «почисти старые ветки» как разрешение массово удалить remote-ветки, агент, который после ошибки аутентификации рылся в конфиг-файлах в поисках другого токена, агент, повторивший упавший деплой с пропущенной верификацией. Добрые намерения, не тот blast radius. Я ожидаю, что эта категория наносит больше повседневного ущерба, чем состязательный injection.
Утечка credentials
Агент может утечь только то, до чего дотягивается. Если в вашем окружении разработчика рядом с кодом лежат долгоживущие облачные ключи, SSH-ключи и .env с продакшен-секретами, то каждый из них в зоне досягаемости для внедрённого или излишне рьяного агента.
Слишком широкие permissions и неоднозначная идентичность
Руководство для CISO делает замечание, которое показалось мне проясняющим: опасная зона — не выделенный service account и не человек за клавиатурой. Это середина, где агент несёт делегированную идентичность человека в системы, за которыми этот человек не следит. Когда что-то идёт не так, никто не может сказать, кто на самом деле это сделал.
Supply chain расширений
Skills, plugins, MCP-серверы, коннекторы и зависимости, которые ставят агенты, — каждое из них это код или инструкции, которым вы выбираете доверять, а некоторые подают недоверенный контент прямо в контекст. Tool poisoning — это вредоносный пакет эпохи агентов. Если вы широко внедряете MCP, вопросы governance из MCP для инженерных команд — это тоже вопросы безопасности.
Отравление памяти и контекста
Персистентный контекст — memory-файлы, инструкции в стиле CLAUDE.md, общие базы знаний — можно подменить так, что яд переживёт сессию. Файлы инструкций заслуживают дисциплины code review, потому что фактически являются кодом.
Четыре вопроса перед одобрением любого агента
Самый полезный инструмент во всём этом наборе источников — четырёхвопросная оценка из руководства для CISO. Я переформулировал её так, как реально использовал бы на дизайн-ревью:
- Какой недоверенный контент он читает? Что атакующий мог бы правдоподобно написать или изменить так, что оно окажется в контексте агента? Если честный ответ «ничего», агент-специфичный риск близок к нулю.
- Что он может делать и от чьего имени? Читать или писать, выполнять код, вызывать инструменты, выходить в сеть — и под какой идентичностью.
- Каков blast radius, если что-то пойдёт не так? Один файл, один репозиторий, одно окружение, вся организация? Худший случай — неудобство или инцидент?
- Видите ли вы его? Можете ли отличить действия агента от действий пользователя, и попадают ли они в ваш SIEM?
Эти вопросы превращают «разрешать ли агентов?» — спор, который никогда не кончается, — в «при каких условиях мы одобрим этого?», на что есть ответ. Рискованная комбинация — недоверенный вход плюс мощные действия плюс плохая видимость; уберите любую ногу — и картина резко улучшается.
Контроли, которые действительно держат
Примерно в порядке убывания рычага. Сквозная тема: проводите границы вокруг действий и доступа, а не вокруг инструкций модели. Промпт, говорящий «никогда не трогай продакшен», — это пожелание. Credential, который не достаёт до продакшена, — это контроль.
Least agency
Least privilege в адаптации: выдавайте самую узкую способность, достаточную для выполнения задачи, а не просто самый узкий доступ к данным. Ограничивайте отдельные глаголы, а не только инструменты целиком — агент, который может подготовить сообщение, но не отправить его, открыть PR, но не смёрджить, читать логи, но не деплоить. Если у агента нет глагола, никакой injection не заставит его им воспользоваться.
Sandboxing и контроль egress
Запускайте агентов в изолированных окружениях — контейнерах, microVM, удалённых dev-VM — с credentials, хранящимися вне sandbox. Паттерн, который Anthropic описывает для собственных инструментов, — прокси, подставляющий credentials на выходе, так что в sandbox нет ничего, что стоило бы красть. Сочетайте это с allowlist для egress через прокси, который агент не может обойти. Внедрённому агенту, который не может достучаться до произвольного адреса, некуда отправить найденное.
Однозадачная идентичность агента
Дайте каждому автономному агенту собственную идентичность с минимальными permissions для его единственной работы, провизионируемую через ваш IdP, как любой другой principal. Агент реагирования на инциденты у Anthropic — хрестоматийный случай: он может читать продакшен-логи, писать документы и публиковать в каналах — и ничего больше. Деплоить он не может. Интерактивные coding-сессии иное: за клавиатурой человек, подотчётный, поэтому его credential там допустим, пока окружение изолировано sandbox’ом. Избегайте середины.
Детерминированные hooks и managed settings
Это различие я повторяю в каждом посте про агентов, потому что оно предотвращает так много инцидентов: инструкции советуют, hooks принуждают. Ваши рекомендации по безопасному кодированию относятся в CLAUDE.md и skills, чтобы сгенерированный код большую часть времени им следовал. Но всё, что обязано выполняться — никаких правок защищённых путей, никаких секретов в диффах, обязательный security-проход до открытия PR, — нуждается в детерминированной страховке: pre-tool hook, CI-гейт, правило branch protection. Затем вынесите неотрицаемые части в централизованные managed settings, чтобы отдельные разработчики не могли тихо их ослабить.
Классификаторы как средний слой, а не стена
Усталость от подтверждений реальна: Anthropic сообщает, что пользователи принимают 93% permission-промптов Claude Code, а значит промпт в основном перестал работать как проверка. Auto mode заменяет большую часть промптов классификатором, который оценивает каждое рискованное действие до его выполнения. Опубликованные цифры стоит читать внимательно: 0,4% ложных срабатываний на реальном трафике, но 17% пропусков на небольшом наборе реальных излишне рьяных действий. Anthropic описывает это как большое улучшение по сравнению с пропуском permissions и возможную регрессию по сравнению с тщательным ручным подтверждением на высокорисковой инфраструктуре. Так что используйте его как один слой поверх sandbox и credentials с least privilege, а не как единственное, что стоит между агентом и продакшеном.
Audit trails, отделяющие агента от человека
Каждый вызов инструмента, автоматическое подтверждение и сообщение между агентами должны логироваться с достаточным контекстом — инструмент, параметры, результат, пользователь, сессия — чтобы восстановить произошедшее, и отправляться в ваш SIEM. Относитесь к агентам как к потенциальным инсайдерам и алертите на выбивающееся из паттерна поведение. Руководство для CISO приводит цифру Ponemon — в среднем 67 дней на локализацию инсайдерского инцидента; агент, действующий со скоростью машины, делает такой срок недопустимым, поэтому видимость должна идти раньше масштаба.
Человек на production-гейте
Самая чистая линия governance, какую я знаю: агент может всё вплоть до production-гейта, а пройти через него разрешает названный человек. Anthropic говорит, что Claude пишет около 80% кода, сливаемого в их кодовую базу, а внутренний агент ведёт значительную часть потока pull request’ов, — и контроли, делающие это терпимым, — эфемерные окружения, отделённые от продакшен-ключей, плюс человеческое ревью перед merge. Расслойте кодовую базу по риску: часть путей можно авто-одобрять с выборочной проверкой, регулируемый или критичный код остаётся на человеческом ревью.
Непрерывное сканирование, нацеленное на ваш собственный код
Если атакующие будут сканировать ваш код мощными моделями, сканируйте его первыми. Цикл из руководства по безопасности исходного кода стоит перенимать почти как есть: модель угроз, sandbox, обнаружение, независимая верификация, triage, патч. Держите обнаружение (recall) и верификацию (precision) в отдельных агентах и закладывайте бюджет на triage и патчинг прежде, чем на новое сканирование — triage теперь бутылочное горлышко.
Таблица контролей
Вот всё целиком на одной странице. «Детерминированный» значит, что оно держится независимо от решения модели; «рекомендательный» — что оно смещает вероятности.
| Риск | Контроль | Тип | Владелец |
|---|---|---|---|
| Prompt injection через читаемый контент | Определить недоверенные источники; отделить коннекторы недоверенного входа от продакшен-данных; injection-пробы | Рекомендательный (пробы) + Детерминированный (разделение) | Security architecture |
| Эксфильтрация данных | Sandbox с allowlist для egress через прокси, который нельзя обойти | Детерминированный | Platform engineering |
| Утечка credentials | Credentials подставляются прокси, никогда не присутствуют в sandbox; короткоживущие токены с ограниченным scope | Детерминированный | Platform / IAM |
| Излишне рьяные или деструктивные действия | Per-verb permissions для инструментов; классификатор действий; deny-правила в managed settings | Детерминированный (permissions) + Рекомендательный (классификатор) | Tech lead + platform |
| Неоднозначная подотчётность | Однозадачные идентичности агентов через IdP; никакой делегированной человеческой идентичности для агентов без присмотра | Детерминированный | IAM |
| Дрейф политики в сгенерированном коде | Правила безопасного кодирования в CLAUDE.md/skills, подкреплённые hooks и CI-гейтами | Рекомендательный → Детерминированный | Владелец политики + tech lead |
| Вредоносные skills, plugins, MCP-серверы | Расширения из allowlist, версионируемые и ревьюемые как зависимости | Детерминированный | Platform + security |
| Отравление памяти / инструкций | Файлы инструкций под code review и code ownership | Детерминированный | Code owners репозитория |
| Несанкционированные изменения в продакшене | Approval hook или CI-гейт, требующий названного человека; branch protection | Детерминированный | Release manager |
| Необнаруженное злоупотребление | Телеметрия вызовов инструментов в SIEM; атрибуция агент-против-человека; общеорганизационный выключатель | Детерминированный (логирование) | Security operations |
| AI-ускоренная эксплуатация вашего кода | Непрерывное сканирование с независимой верификацией; быстрые SLA на патчи | Рекомендательный (находки) + Детерминированный (блокировка merge при высокой уверенности) | AppSec |
Если в строке только «рекомендательный», а риск вы принять не можете, это ваша следующая работа.
Где я бы был осторожен
- Это документы вендора. Все шесть источников — от Anthropic, и несколько ссылаются на продукты Anthropic. Паттерны — least agency, sandboxes без credentials, контроль egress, детерминированные гейты, идентичность агента, телеметрия — вендор-нейтральны и применимы к любому coding-агенту. Продуктовые детали изменятся; проектируйте вокруг паттернов.
- Цифры Anthropic — это цифры Anthropic. Они описывают одну очень AI-native организацию с необычно зрелой командой безопасности. Считайте их свидетельством того, что модель может работать, а не целями, которые стоит обещать вашему совету директоров.
- Не переусердствуйте с промпт-scaffolding как контролем. Руководство для CISO отмечает, что вычурные инструкции по мере улучшения моделей имеют свойство удаляться. Тратьте эти усилия на границы, которые вообще не зависят от модели.
- У lockdown есть цена. Каждое deny-правило убирает способность. Копирование самой строгой конфигурации во все репозитории толкает людей к неодобренным инструментам — а у теневого внедрения нет ни телеметрии, ни выключателя. Подбирайте ограничения под классификацию данных каждого репозитория.
Как внедрить это, не убив скорость
Подача, которая мне нравится больше всего, идёт из названия руководства для CISO: нулевой риск — не задача. Задача — сделать agentic-риск видимым и ограниченным, чтобы организация могла принять его осознанно. Отказ не устраняет использование агентов; он лишь переносит его туда, где вы этого не видите.
Порядок, которому я бы следовал в реальной команде:
- Неделя 1–2: инвентаризация и классификация. Перечислите, где агенты уже работают, санкционированно или нет. Запишите, что считается недоверенным контентом в вашем окружении. Прогоните свой самый горячий use case через четыре вопроса, ища условия, при которых вы скажете да.
- Неделя 3–4: уберите секреты из зоны досягаемости. Перенесите работу агентов в sandbox-окружения с credentials вне sandbox и allowlist для egress. Это одно изменение сужает blast radius любого другого сбоя.
- Месяц 2: сделайте политику детерминированной. Закодируйте правила безопасного кодирования в
CLAUDE.mdи skills, затем добавьте hooks и CI-гейты для подмножества, которое обязано держаться. Вынесите их в managed settings. Введите allowlist расширений и MCP-серверов. - Месяц 2–3: идентичность и телеметрия. Дайте каждому автономному агенту однозадачную идентичность. Стримьте вызовы инструментов в SIEM с атрибуцией агент-против-человека. Убедитесь, что у вас есть общеорганизационный выключатель и что он действительно работает.
- Месяц 3+: переведите ревьюеров со строк на циклы. Сначала запустите новых AI-ревьюеров в shadow-режиме, red-team’те их намеренно плохими изменениями, затем расслойте кодовую базу по уровням, чтобы люди концентрировались на рискованных путях. Начните непрерывное сканирование самого экспонированного сервиса, с шагом верификации и путём triage.
Расширяйте поэтапно: сначала малая группа, следите за телеметрией, затем шире. Спросите своих поставщиков IdP, SIEM и агентов, какие из этих контролей они могут продемонстрировать сегодня, а не в roadmap. Об организационной стороне и стороне процесса ревью см. оценку AI-готовности и внедрение AI coding tools.
Карьерный угол
Security-инженеры переходят от охоты на отдельные баги к мониторингу циклов, которые их находят и чинят. Platform-инженеры кодируют governance как sandboxes, hooks и managed settings. Tech lead’ы владеют файлами инструкций и review-гейтами — что делает их частью периметра безопасности, просили они об этом или нет.
Для отдельных инженеров навык, который накапливается, — быстро отвечать на четыре вопроса для любой настройки агента. Он не привязан ни к модели, ни к вендору и становится ценнее каждый раз, когда способности скачут вверх.
Углубляясь
Контроли из этого поста напрямую ложатся на наши курсы. AI-Native SDLC охватывает hooks, approval-гейты и модель «человек на production-гейте» на всём жизненном цикле. Claude Code Mastery глубоко разбирает permissions, sandboxing, hooks и managed settings в ежедневном agentic-цикле. MCP Servers — место, где научиться безопасно строить и governить слой инструментов. Если вы строите собственных агентов, Claude Agent SDK и Claude API охватывают permissions инструментов, идентичности с ограниченным scope и инфраструктуру за ними.
Для команд, внедряющих агентов по всей организации, мы также проводим это как корпоративное обучение или как hands-on AI tools enablement.
Источники: Anthropic, Zero risk isn’t the job: a CISO’s guide to agentic AI (июль 2026); How Anthropic secures its AI-native software development lifecycle (июль 2026); Zero Trust for AI agents (май 2026); Using LLMs to secure source code (май 2026); Preparing your security program for AI-accelerated offense (апрель 2026); How Claude Code auto mode works (март 2026). Этот пост — независимый комментарий; за полными деталями читайте оригиналы. Связанное в этой серии: AI-native SDLC, MCP для инженерных команд, когда не стоит использовать AI-инструменты.
