Как Anthropic обеспечивает безопасность своего AI-ориентированного жизненного цикла разработки ПО

Anthropic только что опубликовала один из самых прозрачных взглядов на то, что на самом деле требуется для защиты жизненного цикла разработки, в котором искусственный интеллект пишет большую часть вашего кода. В посте в блоге заместителя директора по информационной безопасности Джейсона Клинтона компания раскрыла, что сейчас Claude авторирует примерно 80% кода, сливаемого в репозиторий Anthropic, а скорость разработки увеличилась в восемь раз по сравнению с базовым уровнем 2021–2025 годов.

Это не теоретический пост. В нем детально описаны конкретные процессы безопасности, которые Anthropic развернула на каждом этапе своего AI-ориентированного жизненного цикла разработки (SDLC), угрозы, от которых они защищаются, и постоянные принципы, которые, по их мнению, будут актуальны по мере развития возможностей моделей. Для любой команды, где AI-агенты начинают писать, проверять или отправлять код — включая команды, использующие автономных агентов на собственной инфраструктуре, — это обязательный материал к прочтению.

source

Новая модель угроз: Три поверхности атаки, которые нельзя игнорировать

Когда AI-агенты занимают центральное место в вашем пайплайне разработки, ландшафт угроз смещается. Команда безопасности Anthropic определила три конкретных класса угроз, от которых они проектируют защиту:

1. Скомпрометированные или подвергшиеся промпт-инъекции агенты, вносящие вредоносные изменения в кодовую базу — когда манипулятивный ввод заставляет агента генерировать код, выглядящий легитимным, но содержащий бэкдоры или уязвимости.

2. Отравление цепочки поставок и зависимостей, которые агенты принимают за доверенный ввод. AI-инструменты для кодирования извлекают данные из реестров пакетов, документации и примеров кода. Если эти источники отравлены, агент относится к вредоносному коду как к эталону.

3. Традиционные уязвимости приложений, поступающие в значительно большем объеме. Когда инженер отправляет в 8 раз больше кода за квартал, процессы проверки безопасности, которые не масштабируются, становятся узкими местами — или того хуже, полностью игнорируются.

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

Четыре стратегии, которые действительно работают

Вместо того чтобы рассматривать безопасность как ворота, замедляющие всё, Anthropic встроила её непосредственно в процесс разработки, используя четыре основополагающие стратегии:

• Сдвиг безопасности «влево» — полная интеграция анализа безопасности в этап разработки кода, а не рассмотрение его как отдельного последующего контрольного пункта.
• Жесткие границы доступа и идентификации — ограничение зоны поражения так, чтобы даже в случае компрометации агента или генерации им вредоносного кода ущерб был ограничен по масштабу.
• Сочетание детерминированных и агентских проверок — использование как автоматизированных проверок на основе правил, так и анализа на базе ИИ до и после того, как код попадает в продакшн.
• Люди в наиболее критичных точках — сохранение человеческого участия, но стратегически, на контрольно-пропускных пунктах утверждения, где человеческое суждение добавляет наибольшую ценность, а не механический обзор каждой строки.

Последний пункт стоит подчеркнуть. В кодовой базе, написанной на 80% ИИ, проверка каждого коммита людьми невозможна и не нужна. Смещение идет в сторону целенаправленного человеческого надзора, где ставки наиболее высоки: архитектурные решения, изменения, затрагивающие безопасность, и окончательные утверждения для продакшн.

PSR: от узкого места к AI-ускоренным воротам

Один из самых конкретных примеров в посте — автоматизация Project Security Review (PSR) в Anthropic. То, что начиналось как веб-приложение на базе Claude Opus, которое поглощало документы по проектному дизайну и анализировало их в соответствии с фреймворком MITRE ATT&CK, значительно эволюционировало.

Изначальная система автоматически идентифицировала потенциальные уязвимости и предлагала меры по их устранению. Она сэкономила большую часть времени команды AppSec. Но Anthropic на этом не остановилась. Они подключили приложение PSR к внутреннему индексу знаний, который обеспечивает более глубокий контекст на основе организационных политик, прошлых решений и смежных систем. Они также создали навык для Claude Code, позволяющий Claude разворачиваться и захватывать дополнительный контекст, где бы он ни находился в организации.

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

Вечный принцип: Контекст — это всё

Пожалуй, самый стратегически важный вывод из поста — это то, что Anthropic называет вечным принципом: *связывать агентов безопасности с организационным контекстом.*

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

Принцип прост: подводить агентов безопасности к местам, где контекст уже существует, а не заставлять команды создавать детальную документацию на этапах, которые в ней уже не нуждаются. Агентам нужен контекст за пределами самого кода. Без него они проводят оценку безопасности в вакууме.

Это имеет глубокие последствия для того, как команды структурируют свои среды разработки, документацию и шаблоны доступа агентов.

Ограничение зоны поражения на практике

Понятие ограничения зоны поражения заслуживает особого внимания для команд, развертывающих автономных агентов. В фреймворке Anthropic это означает проектирование систем таким образом, чтобы даже скомпрометированный или ведущий себя неправильно агент мог воздействовать только на ограниченную область.

На практике это выражается в:

• Границах идентификации — каждый агент работает с определенными, ограниченными разрешениями, а не широким доступом.
• Контроле доступа — агенты не могут повышать привилегии или проникать в системы, для взаимодействия с которыми они не предназначены.
• Контрольных точках проверки — автоматизированные детерминированные проверки (не только другими AI-агентами) удостоверяются, что изменения соответствуют базовым стандартам безопасности до их распространения.

Сочетание детерминированных и агентских проверок — ключевой момент. Вы не хотите, чтобы ИИ проверял ИИ без эталона истины. Детерминированные правила — линтеры, статический анализ, сканирование зависимостей, обеспечение политики — задают жесткий минимум. Агентская проверка добавляет контекстуальный интеллект поверх этого минимума.

Какие выводы должны сделать команды, работающие на self-hosted AI

Для инженерных команд, где AI-агенты становятся основными контрибьюторами в кодовой базе — будь то через Claude Code, пользовательские пайплайны агентов или автономные системы кодирования — пост Anthropic предлагает несколько практических уроков:

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

Во-вторых, проектируйте с учетом ограничения зоны поражения с первого дня. Жесткие границы между агентами, между агентами и продакшн-системами, а также между различными доменами кода не являются опциональными. Это фундамент, который делает возможным всё остальное.

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

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

Более широкий вывод заключается в том, что переход к AI-ориентированной разработке — это не будущее, а настоящее в таких компаниях, как Anthropic, и практики безопасности, необходимые для его поддержки, быстро созревают. Вопрос для каждой инженерной команды заключается не в том, принимать ли эти подходы, а в том, как быстро они смогут их внедрить.