Расширение Zero Trust на рабочие процессы агентного ИИ

01Введение

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

Рассмотрим агента для написания кода, такого как Claude Code или Codex. Для выполнения одной задачи он может вызвать LLM для рассуждений, подключиться к MCP-инструментам для чтения Jira и отправки изменений в GitHub, обращаться к SaaS-API для получения данных и просматривать веб-страницы для дополнительного контекста. Всё это он делает автономно, на машинной скорости, используя те учётные данные, которые получил при запуске.

02Почему существующие средства контроля неэффективны

Традиционные средства контроля Zero Trust аутентифицируют пользователя и предоставляют доступ к ресурсу. После предоставления доступа мы полагаемся на то, что человек проявит здравый смысл, или на то, что машины будут следовать заранее определённым правилам. Агент не является ни пользователем, ни детерминированной машиной. Это процесс, который рассуждает, принимает решения и действует — с широким охватом, экспоненциальным масштабом и без человеческого суждения.

В результате одного лишь контроля доступа становится недостаточно. Агент для написания кода может быть авторизован для подключения к GitHub, Jira и утверждённому набору моделей. Реальный вопрос заключается не в том, может ли он подключиться к этим системам, а в том, какие действия он выполняет в них, работая над достижением цели. Чтение репозитория, создание pull request, изменение производственной конфигурации или доступ к конфиденциальным данным — всё это может нести разный уровень риска.

Это переход от контроля доступа к контролю действий. Организациям необходимо оценивать активность агентов не только в момент предоставления доступа, но и на протяжении всего рабочего процесса. В этом и заключается проблема безопасности агентов — и она принципиально отличается от задач, для решения которых изначально разрабатывался Zero Trust.

03От контроля доступа к контролю действий

Cisco Secure Access развивается, чтобы помочь совершить этот переход с помощью Agent Gateway — новой функциональности, которая расширяет применение политик на взаимодействие агентов с LLM, MCP-серверами, SaaS-API и веб-ресурсами. Чтобы перейти от контроля доступа к контролю действий, Agent Gateway будет помогать отвечать на пять вопросов перед тем, как запросу будет разрешено продолжиться:

• Кто этот агент? Cisco использует Duo для идентификации самого агента Codex, Claude Code или LangChain — а не только ноутбука, на котором он работает.
• К чему он пытается получить доступ? Agent Gateway будет сопоставлять запросы с именованной группой ресурсов: утверждённым набором моделей, группой MCP-инструментов, набором SaaS-API или веб-категорией.
• Разрешено ли это действие? Политика будет определять, разрешён ли запрос, находится ли он под наблюдением или заблокирован. Запрос "fetch" из репозитория GitHub разрешён; запрос "create_file" в тот же репозиторий может быть отклонён.
• Какие учётные данные следует использовать? Токены, гранты OAuth и ключи API будут храниться в хранилище Cisco. Агент никогда к ним не прикасается. Agent Gateway будет внедрять правильные учётные данные на стороне сервера для каждого метода и пути.
• Что произошло? Каждое решение — идентичность агента, затронутый ресурс, вердикт политики, ссылка на учётные данные, пройденный маршрут — будет попадать в одно событие аудита.

04Что делает подход Cisco особенным

Многие подходы к безопасности агентов внедряют второй стек доступа, который предприятия принимают наряду с существующей инфраструктурой SSE и управления идентификацией. Подход Cisco отличается: если вы уже используете Secure Client, Secure Access и Duo, у вас уже есть поверхность для применения политик. С помощью Agent Gateway Cisco расширяет эти возможности на агентные рабочие процессы. Никаких изменений в коде агентов. Никакого нового портала управления. Никакой второй системы идентификации.

• Идентификация агента через Duo Non-Human Identity (NHI). Duo будет идентифицировать сам процесс агента с помощью Duo identity, естественным образом расширяя возможности от пользовательской MFA до агентных и нечеловеческих идентичностей. Не требуется отдельный сервис идентификации. В средах MCP Duo и Secure Access работают вместе, обеспечивая детальный контроль на уровне инструментов, чтобы организации могли управлять тем, какие инструменты агенту разрешено вызывать, а не только тем, к каким MCP-серверам агент может получить доступ.
• Единая политика для всего рабочего процесса. Агенты работают с моделями, MCP-инструментами, API и веб-активностью — не в рамках единой плоскости управления. С помощью Agent Gateway Cisco будет применять общую структуру политик во всех этих средах, помогая организациям управлять утверждёнными моделями, MCP-инструментами, корпоративными API и веб-ресурсами.
• Внедрение учётных данных на стороне сервера. Ключи и токены хранятся в хранилище Cisco. Агент никогда к ним не прикасается. Agent Gateway будет внедрять правильные учётные данные на стороне сервера для каждого метода и пути. Это разделяет авторизацию агента и владение учётными данными, позволяя агентам выполнять разрешённые действия без доступа к самим учётным данным. Это закрывает целый класс рисков утечки данных, который не решает ни одно решение, основанное только на прокси.

05Что это означает на практике

Рассмотрим предприятие, развёртывающее сотни агентов для написания кода в рамках разработки программного обеспечения. Каждый агент может быть авторизован для использования утверждённых LLM, доступа к Jira через MCP-инструменты, получения исходного кода из GitHub, обращения к внутренней документации и взаимодействия с выбранными корпоративными API. На бумаге это звучит просто. На практике эти агенты могут выполнять тысячи действий каждый день в десятках систем.

Традиционные средства контроля доступа могут ответить на вопрос, разрешено ли агенту подключаться к GitHub. Они с трудом показывают, было ли то или иное действие уместным после того, как агент туда попал. Даже базовые вопросы аудита требуют сшивки данных из журналов провайдера LLM, журналов MCP-сервера, журналов аудита GitHub и того, что фиксирует фреймворк оркестрации агента.

С Agent Gateway и Duo каждый агент имеет именованную идентичность, привязанную к его владельцу и бизнес-цели. Каждое взаимодействие с GitHub показывает, какой метод был вызван, было ли оно разрешено и какая ссылка на хранилище предоставила токен. Когда у провайдера модели происходит сбой, запросы могут автоматически переключаться на другую утверждённую модель в рамках той же структуры политик. Режим наблюдения может выявлять необычные паттерны — например, всплеск запросов на запись к обычно доступному только для чтения API — и предлагать их в качестве рекомендаций по политике.

Ценность заключается не в ещё одной панели мониторинга. Это единый контур управления для идентичности агента, действия, учётных данных, политики и результата.

Некоторые продукты или функции, описанные в этой статье, могут находиться на различных стадиях разработки и предлагаться по мере готовности. Cisco оставляет за собой право изменять сроки поставки и не несёт ответственности за любые задержки или сбои в поставке.