[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > Агенты, инструменты, MCP и агентный RAG

# Агенты, инструменты, MCP и агентный RAG

{#agents-tools-mcp}

Сквозной путь агента выглядит так: `пользователь → приложение → модель или агент → MCP Gateway → инструмент или бэкенд → целевой ресурс`. Проверенная идентичность, ограничения полномочий и корреляция на этом пути обеспечиваются требованиями `AI-AGENT-GOAL1`, `AI-IAM-LEASTPRIV3`, `AI-MCP1` и `AI-MON-TRACE1`. Текст от модели не заменяет решение авторизации ни на одном шаге.

## Возможности и автономность {#capabilities-autonomy}

### Возможности агента и внешние последствия перечислены {#agent-capabilities-external-effects-enumerated}

{#ai-agent1-id}

Идентификатор требования: `AI-AGENT1`

{#ai-agent1-requirement}

**Требование**

До продуктивного использования владелец должен перечислить доступные агенту инструменты, данные, получателей и действия, а также максимальные последствия каждого действия. Классификация должна отражать фактические возможности: чтение, изменение, публикацию, финансовое действие, запуск кода, управление доступом или воздействие на внешний объект.

Реестр составляется по фактической конфигурации агента, оркестратора и MCP Gateway, а не по проектным описаниям, и учитывает прямой обход к целевой системе и инструменты внешнего провайдера. Неописанная в реестре возможность отклоняется до целевой системы; версия реестра связывается с выпуском.

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

{#ai-agent1-manual-check}

**Ручная проверка**

1. Сопоставьте реестр возможностей с конфигурацией агента, MCP Gateway, бэкенда и целевыми правами.
1. Для каждой зарегистрированной возможности выполните один безопасный разрешенный тест; действие с более сильным эффектом, чем описано, отклоняется до вызова целевой системы.

Неучтенный инструмент или более широкое фактическое действие блокирует выпуск.

{#ai-agent1-artifacts}

**Артефакт**

* Реестр возможностей.
* Сопоставление с конфигурацией.
* Версия реестра.
* Тестовые события.

### Автономное выполнение имеет лимиты и условия остановки {#autonomous-execution-limits-stop-conditions}

{#ai-agent2-id}

Идентификатор требования: `AI-AGENT2`

{#ai-agent2-requirement}

**Требование**

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

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

Счетчики применяет оркестратор вне модели; документированные лимиты инструментов MCP не используются как ограничение безопасности. Должно существовать серверное состояние остановки, после установки которого новые действия в целевой системе запрещены.

{#ai-agent2-implementation}

**Реализация**

Значения зависят от риска и стоимости сценария и утверждаются владельцем. [Алерты Monitoring](../../monitoring/concepts/alerting/alert.md) и [бюджеты Yandex Cloud Billing](../../billing/operations/budgets.md) могут обнаружить часть последствий, но уведомление не заменяет лимит и остановку внутри оркестратора или среды исполнения.

{#ai-agent2-check}

**Проверка**

Создайте тест с циклическим ответом инструмента, повторяющейся ошибкой и исчерпанием одного из лимитов. Агент должен завершить выполнение в заданной границе, не продолжая внешние действия. Остановка должна завершаться записью причины; последующие вызовы целевой системы после остановки должны отсутствовать в журнале или трассировке.

{#ai-agent2-artifacts}

**Артефакт**

* Тест циклического ответа, повторяющейся ошибки, исчерпания лимита.
* Версия политики и конфигурация счетчиков.
* Итоговая причина остановки.

### Цель и полномочия агента поступают только из доверенных источников {#agent-goal-authority-from-trusted-sources}

{#ai-agent-goal1-id}

Идентификатор требования: `AI-AGENT-GOAL1`

{#ai-agent-goal1-requirement}

**Требование**

Цель задания, системная политика и разрешенный набор действий должны поступать из доверенной конфигурации или проверенного решения приложения. Сообщение пользователя, RAG-фрагмент, ответ инструмента или другого агента не должны расширять полномочия, менять владельца данных или отключать ограничение. Цель формируется как типизированный объект из аутентифицированного серверного источника; сохраняются инициатор, версия цели и политики и разрешенные возможности.

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

{#ai-agent-goal1-check}

**Проверка**

Передайте через пользователя, RAG и инструмент три синтетические инструкции расширить цель или отключить контроль. Агент может использовать данные как контекст, но не должен получить новое полномочие. Новое действие в целевой системе должно отсутствовать. При провале сессия останавливается, затронутое делегирование отзывается, исправляется разбор или метки доверия, и тест повторяется.

{#ai-agent-goal1-artifacts}

**Артефакт**

* Тест расширения цели через пользователя, RAG, инструмент.
* Версия цели и делегирование.
* Подтверждение отсутствия вызова целевой системы.

## Идентичность инструмента и подтверждение человека {#tool-identity-hitl}

### Каждый инструмент использует отдельную учетную запись с минимальными правами {#each-tool-has-separate-minimal-identity}

{#ai-iam-leastpriv3-id}

Идентификатор требования: `AI-IAM-LEASTPRIV3`

{#ai-iam-leastpriv3-requirement}

**Требование**

Инструмент, способный обратиться к целевому ресурсу, должен использовать отдельную учетную запись с минимальными правами на конкретные операции. Один общий административный сервисный аккаунт для несвязанных инструментов не допускается.

Бэкенд должен проверять пользователя или подтвержденный контекст делегирования; имя пользователя, переданное моделью в аргументе, не является доказательством.

Для каждого инструмента фиксируются: вызывающий субъект, сервисный аккаунт среды исполнения, ресурс и действие целевой системы, точная роль и уровень привязки, секрет и сетевой путь.

Если техническая архитектура не поддерживает передачу пользовательского контекста, бэкенд должен применить заранее заданную сервисную политику и сузить ресурсную область до минимальной. Такое ограничение явно отражается в описании возможности агента. Повторное использование сервисного аккаунта допустимо только в одной утвержденной границе с одинаковыми владельцем, данными и действиями; роли вызова и управления шлюзом не заменяют доступ к целевой системе.

{#ai-iam-leastpriv3-check}

**Проверка**

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

Разрешение должно определяться бэкендом и IAM, а не текстом модели. Та же идентичность не должна вызывать несвязанную целевую систему, управлять IAM или читать посторонний секрет.

{#ai-iam-leastpriv3-artifacts}

**Артефакт**

* Сопоставление бэкенда, сервисного аккаунта, ролей.
* Тест подмены.
* Матрица по инструментам.
* Идентификаторы секретов.

### Полномочия сессии определяются доверенной делегацией {#session-authority-defined-by-trusted-delegation}

{#ai-iam-compromise1-id}

Идентификатор требования: `AI-IAM-COMPROMISE1`

{#ai-iam-compromise1-applicability}

**Применимость**

Требование применяется, если агент действует от имени пользователя, арендатора или иной сессии с различающимися правами.

{#ai-iam-compromise1-requirement}

**Требование**

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

Отзыв пользовательской сессии, права или делегирования должен прекращать последующие действия, а постоянная рабочая идентичность агента не должна сохранять более широкое право.

Краткоживущие IAM- и ID-токены используются только для документированной аудитории; для каждой идентичности фиксируются аудитория и срок действия токена, область привязки и способ аварийного отзыва. Совместимость OIDC-поставщика подтверждается его документацией.

Если сквозная делегация технически отсутствует, сервисная политика должна ограничивать доступ заранее определенными ресурсами и операциями, а это ограничение фиксируется как свойство архитектуры. Данные и состояние разных сессий разделяются по `AI-INFRA6` и `AI-INFRA-ISOL2`.

{#ai-iam-compromise1-check}

**Проверка**

1. Выполните разрешенное действие в своей сессии, затем попробуйте подменить пользователя, арендатора, ресурс и действие.
1. Отзовите тестовую сессию или право и повторите вызов.

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

{#ai-iam-compromise1-artifacts}

**Артефакт**

* Тест подмены пользователя, арендатора, отзыва сессии.
* Запись делегирования.
* Метаданные токена без секрета.
* Событие отзыва.

### Действия с существенными последствиями подтверждает человек {#material-consequence-actions-confirmed-by-human}

{#ai-agent-hitl1-id}

Идентификатор требования: `AI-AGENT-HITL1`

{#ai-agent-hitl1-requirement}

**Требование**

Организация должна определить действия, для которых требуется подтверждение уполномоченного человека: например, необратимое удаление, изменение доступа, публикация, платеж или отправка чувствительных данных. Перед подтверждением интерфейс должен показать цель, объект, существенные параметры и последствия. Изменение параметров после подтверждения делает подтверждение недействительным.

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

{#ai-agent-hitl1-implementation}

**Реализация**

Подтверждение не заменяет IAM и прикладную авторизацию. Для низкорисковых или полностью обратимых действий организация может выбрать автоматическое выполнение и зафиксировать это решение.

{#ai-agent-hitl1-check}

**Проверка**

Инициируйте тестовое действие с существенными последствиями, измените один параметр после подтверждения и повторите запрос. Действие без актуального подтверждения должно быть отклонено, а субъект и версия параметров — отражены в трассировке.

{#ai-agent-hitl1-artifacts}

**Артефакт**

* Тест действия без подтверждения.
* Изменение параметра после подтверждения.
* Идентификатор и хеш подтверждения.
* Событие целевой системы.

## MCP Gateway и целевой сервис {#mcp-gateway-target}

### Доступ к MCP Gateway и целевому сервису разделен {#mcp-gateway-target-service-access-separated}

{#ai-mcp1-id}

Идентификатор требования: `AI-MCP1`

{#ai-mcp1-requirement}

**Требование**

Владелец должен отдельно определить вызывающую идентичность, право вызова Gateway, право редактирования его конфигурации, право управлять привязками, сервисный аккаунт Gateway и право целевого сервиса на ресурс. Семантика ролей описана в [модели доступа AI Studio](https://aistudio.yandex.ru/docs/ru/ai-studio/security/index.html): для вызова применяется `serverless.mcpGateways.invoker`, для изменения Gateway — `serverless.mcpGateways.editor`, для управления привязками — `serverless.mcpGateways.admin`. CLI-справочник используется как источник синтаксиса команд, а не как единственное нормативное описание ролей.

{#ai-mcp1-implementation}

**Реализация**

Для каждого инструмента фиксируются канал и URL бэкенда, метод аутентификации, разрешенные заголовки, версия входной JSON-схемы и правило обработки неизвестных полей. Ограничение размера параметров и подтверждение действия являются настройкой приложения или оркестратора, а не документированным полем конфигурации MCP Gateway. Элементы Responses `mcp_approval_request` и `mcp_approval_response` служат свидетельствами только для документированного пути.

Роль `serverless.mcpGateways.anonymousInvoker` используется в документированных сценариях доступа к внешним MCP-серверам и серверам из шаблона; ее название не является доказательством публичного или неаутентифицированного доступа.

Публичность Gateway задается отдельно: публичный MCP-сервер допускает неаутентифицированный доступ агентов, а для обращения другого агента к закрытому MCP-серверу требуется IAM-токен сервисного аккаунта либо API-ключ с областью `yc.serverless.mcpGateways.invoke`. Эти ветви описаны в [обзоре MCP Hub](https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/mcp-hub/index.html) и [инструкции по API-ключу](https://aistudio.yandex.ru/docs/ru/ai-studio/operations/get-api-key.html).

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

Доступ к MCP Hub API выполняется только с IAM-токеном согласно [документации аутентификации AI Studio](https://aistudio.yandex.ru/docs/ru/ai-studio/api-ref/authentication.html).

Параметры HTTP-инструмента и привязка сервисного аккаунта описаны в [инструкции создания MCP Gateway](https://aistudio.yandex.ru/docs/ru/ai-studio/operations/mcp-servers/create-brand-new-api.html). Официального ресурса Terraform для шлюза нет; частный эндпоинт VPC не отключает путь через публичный адрес.

Операция `--tools-file` заменяет весь список инструментов. Нативная ссылка Lockbox для произвольных учетных данных пользовательской целевой системы без документации не предполагается.

{#ai-mcp1-check}

**Проверка**

```bash
yc serverless mcp-gateway list
yc serverless mcp-gateway get <gateway-id>
yc serverless mcp-gateway list-access-bindings <gateway-id>
yc serverless mcp-gateway list-operations <gateway-id>
```

1. Проверьте конфигурацию, сеть, сервисный аккаунт, привязки, схему и параметры аутентификации.
1. Затем выполните разрешенный вызов, вызов без нужной роли, запрос с превышением размера или неизвестным полем и прямой вызов целевого сервиса в обход Gateway.

Обход не должен предоставлять больше прав. Для прикладной трассировки можно использовать документированные события AI Studio, включая вызовы MCP, но они не подтверждают полноту авторизации целевого сервиса; подробнее в [каталоге событий AI Studio](https://aistudio.yandex.ru/docs/ru/ai-studio/at-ref.html).

{#ai-mcp1-artifacts}

**Артефакт**

* Конфигурация Gateway.
* Разрешенный и запрещенный вызов.
* Обход бэкенда.
* Результат get и привязки шлюза.
* Полная спецификация инструментов.
* Состояние публичного доступа.
* Область действия ключа API.

## Межагентные сообщения и агентный RAG {#interagent-rag}

### Сообщение другого агента проверяется как недоверенное {#other-agent-message-checked-as-untrusted}

{#ai-app-inject2-id}

Идентификатор требования: `AI-APP-INJECT2`

{#ai-app-inject2-requirement}

**Требование**

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

Циклы и повторная доставка ограничиваются правилами `AI-AGENT2`. Отправитель связывается с разрешенными типами сообщений; сообщение не может передать действующую системную инструкцию, идентичность, подтверждение или расширенную цель.

Если сообщение содержит RAG-ссылку или найденный фрагмент, право пользователя на документ должно быть проверено до передачи модели по `AI-RAG-ACL2`. Доверие к агенту-отправителю не переносит автоматически права на данные.

{#ai-app-inject2-check}

**Проверка**

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

{#ai-app-inject2-artifacts}

**Артефакт**

* Тесты с неверной схемой, истекшим сроком, повтором, подменой отправителя.
* Идентичность и привязка отправителя.
* Версии схемы и политики.