Сегодня мы объявляем о том, что функция Govern Agent Behavior в составе Evo Agentic Development Security (ADS), которая контролирует действия агентов написания кода на базе ИИ во время выполнения, стала общедоступной, начиная с управления MCP (MCP Governance).
С момента представления Evo ADS в июне мы двигались к простой идее: разработка с участием агентов создает риски в трех плоскостях, и каждая из них требует собственной формы контроля:
- То, что используют агенты: серверы MCP, навыки и инструменты, которые они привлекают и которые нуждаются в обнаружении и оценке.
То, что используют агенты: серверы MCP, навыки и инструменты, которые они привлекают и которые нуждаются в обнаружении и оценке.
- То, что генерируют агенты: это требует проверки в момент создания.
То, что генерируют агенты: это требует проверки в момент выполнения.
- И то, что делают агенты: действия, которые они предпринимают, приняв решение действовать, и которые должны контролироваться в реальном времени.
И то, что делают агенты: действия, которые они предпринимают, приняв решение действовать, и которые должны контролироваться в реальном времени.
Govern Agent Behavior — это ответ Evo ADS на этот третий вопрос, и MCP Governance — первый сценарий использования, выпускаемый в рамках этой концепции.
На практике MCP Governance предоставляет командам безопасности и платформ возможность обнаруживать все серверы MCP во всей своей инфраструктуре, определять, какие серверы MCP разрешены к использованию, фиксировать момент выхода агента за рамки этой политики, а также регистрировать или блокировать использование MCP в момент выполнения в реальном времени в Claude Code, Cursor, Codex и GitHub Copilot.
Управление тем, какие инструменты может вызывать автономный агент, имеет фундаментальное значение: это тот уровень контроля, который, как полагало большинство команд безопасности, уже существовал, пока они не попытались его найти и не обнаружили ничего. MCP Governance устраняет этот пробел естественным образом в рамках того же рабочего процесса, в котором обнаруживается цепочка поставок агентов и проверяется код, сгенерированный ИИ, а не в виде отдельного привязанного инструмента.
Почему управление MCP имеет значение именно сейчас
Model Context Protocol (MCP) — это стандарт, который позволяет агентам написания кода на базе ИИ подключаться к внешним инструментам, источникам данных и системам (включая репозитории, базы данных, облачную инфраструктуру и внутренние API) через общий интерфейс. Во многом именно поэтому агенты все меньше похожи на автодополнение и все больше на коллег: агент с доступом к MCP не просто предлагает строку кода, он может сделать запрос к системе тикетов, извлечь записи из производственной базы данных или вызвать внутренний сервис — и все это в рамках одной сессии.
Эта мощь одновременно является и проблемой. MCP стандартизирует способ подключения агентов к инструментам, но ничего не говорит о том, каким инструментам следует доверять или что агенту разрешено делать с теми, к которым он может получить доступ. Каждый сервер MCP, к которому подключается агент, по сути, представляет собой новый элемент вашей цепочки поставок программного обеспечения. Однако в отличие от зависимости, зафиксированной в манифесте, он часто внедряется динамически разработчиком за пару секунд без какого-либо процесса проверки.
Эта уязвимость не гипотетична и не нова; это та же проблема вредоносных пакетов, которая теперь проникает через другую дверь. Скомпрометированный сервер MCP может читать локальные файлы, похищать учетные данные или получать доступ к внутренним системам в момент запуска — еще до того, как команда безопасности узнает о существовании сервера, не говоря уже о возможности его проверить. Риск реализуется на машине разработчика в момент вызова, поэтому именно там его необходимо обнаружить.
Масштаб проблемы больше, чем предполагает большинство команд безопасности. Собственные данные сканирования Snyk, полученные из почти 10 000 сред разработчиков, выявили 4 524 уникальных сервера MCP, находящихся в активном использовании, причем на самых оснащенных машинах одновременно работало 13 и более таких серверов. Более половины разработчиков уже имеют активные подключения MCP к производственным инструментам и системам. А когда мы изучили состояние безопасности этих подключений, оказалось, что у 1 из 12 разработчиков с установленным сервером MCP на сегодняшний день обнаружены подтвержденные проблемы высокой или критической степени тяжести.
Ничего из этого не отображается в традиционном конвейере AppSec, поскольку серверы MCP не являются артефактами, сканируемыми в CI, или зависимостями, проверяемыми перед слиянием. Вместо этого они внедряются в режиме реального времени, во время выполнения, зачастую вне каких-либо процессов безопасности, видимых специалистам. Без возможности указать, какие серверы MCP допустимы, и обеспечить соблюдение этого правила в момент, когда агент пытается воспользоваться одним из них, понятия «внедрение агентов ИИ» и «расширение неуправляемой поверхности атаки» становятся синонимами.
Как работает MCP Governance в Evo ADS
MCP Governance — это ответ Evo ADS на этот пробел и прямое продолжение той видимости, которую Evo ADS уже обеспечивает для цепочки поставок агентов. Она выполняет три задачи:
1. Передает в Snyk ваш список
Команды безопасности и платформ определяют, какие серверы MCP утверждены, используя существующий инвентарь, вручную составленный список или серверы, которые Evo ADS уже выявила в ходе обнаружения. Это становится базовой политикой, по которой оценивается каждый агент в парке. Это можно сделать вручную или просто обратившись к Evo в чате!
2. Наблюдает за использованием вне политики
Как только политика введена в действие, Evo ADS непрерывно отслеживает активность MCP на машинах ваших разработчиков и выявляет каждый случай обращения агента к серверу, отсутствующему в утвержденном списке — будь то разово установленный локальный экземпляр или шаблон поведения, проявляющийся во всем парке. Для того чтобы эта видимость была полезна, ничего не нужно блокировать; для многих команд простое понимание того, к чему на самом деле подключаются агенты, является первой реальной инвентаризацией.
3. Управляет использованием во время выполнения
Именно здесь видимость превращается в контроль. Evo ADS может регистрировать несанкционированное использование MCP для аудита или полностью блокировать его прямо на конечной точке в момент попытки агента подключиться, а не постфактум и независимо от того, решит ли агент подчиниться.
MCP Governance работает везде, где уже работают ваши агенты. На сегодняшний день она доступна для Claude Code, Cursor, Codex и GitHub Copilot и обеспечивается с помощью легковесных перехватчиков, которые работают вместе с агентом, а не перенаправляют его трафик через отдельный прокси-сервер или шлюз. Это тот же подход, который Evo ADS использует для безопасного по замыслу сканирования кода, а это означает, что командам не нужно менять способы подключения агентов к инструментам, развертывать новую инфраструктуру или мириться с новой точкой отказа в пути выполнения агента. Политика хранится централизованно, а ее соблюдение обеспечивается локально, в момент принятия решения об использовании сервера MCP.
Что ждет управление поведением агентов в будущем
Мы намеренно называем это первым сценарием использования, а не завершенной историей. MCP Governance отвечает на вопрос: «Разрешено ли этому агенту обращаться к данному инструменту?» Это необходимый вопрос, но не единственный. Агент, работающий исключительно внутри утвержденного сервера MCP, все равно может выполнить деструктивную команду оболочки или переместить конфиденциальные данные туда, куда не следует, и одна лишь система MCP Governance этого не заметит.
Именно в этом направлении Evo ADS будет развиваться дальше. В ближайшие недели мы расширим возможности принудительного применения за пределы белых списков MCP, чтобы охватить и блокировать действия агентов. Мы переходим от статического списка в политике MCP к решению, которое команды смогут наполнять напрямую из git-репозитория или страницы Confluence с помощью Evo MCP, а также к обеспечению соблюдения правил на основе рисков, чтобы политика отражала реальный уровень риска сервера, а не просто фиксированный запрет или разрешение.
Кроме того, в течение оставшейся части года мы расширяем возможности ADS, чтобы обеспечить контроль несанкционированного доступа к конфиденциальным данным, защиту от инъекций промптов и предотвращение утечки секретов в агентах. Мы также переносим ту же модель «обнаружение — классификация — принудительное применение», которую внедрило MCP Governance, на Agent Skills.
Контроль того, что используют агенты, необходим. Контроль того, что они делают, в момент совершения действия — это то, что делает такой контроль реальным. MCP Governance — первое подтверждение этого, и решение уже доступно.
Хотите увидеть MCP Governance в действии? Запланируйте демонстрацию или изучите Evo Agentic Development Security, чтобы узнать, как Evo ADS защищает то, что агенты используют, делают и генерируют в рамках жизненного цикла разработки на базе ИИ.
ЗАПИСАТЬСЯ НА ЖИВУЮ ДЕМОНСТРАЦИЮ
Безопасное внедрение ИИ в масштабе организации
Evo помогает организациям безопасно внедрять и масштабировать ИИ, обеспечивая прозрачность, управление и безопасность на всех этапах разработки на основе ИИ и в приложениях с искусственным интеллектом.
