[Yandex Cloud documentation](../../index.md) > [Security in Yandex Cloud](../index.md) > Security standard for implementing and operating AI systems in Yandex Cloud, version 1.0.0 > Agents, tools, MCP, and agent RAG # Agents, tools, MCP, and agent RAG {#agents-tools-mcp} End-to-end, the agent's path looks like this: `user → application → model or agent → MCP Gateway → tool or backend → target`. Verified identity, authority limitations, and correlation along this path are ensured by the requirements of `AI-AGENT-GOAL1`, `AI-IAM-LEASTPRIV3`, `AI-MCP1`, and `AI-MON-TRACE1`. No text output from the model replaces the authorization decision at any of the steps. ## Capabilities and autonomy {#capabilities-autonomy} ### Agent capabilities and external consequences are enumerated {#agent-capabilities-external-effects-enumerated} {#ai-agent1-id} Requirement ID: `AI-AGENT1` {#ai-agent1-requirement} **Requirement** Prior to production use, the owner must list the tools, data, recipients, and actions available to the agent, as well as the maximum consequences of each action. The classification must reflect the actual capabilities: reading, modifying, publishing, financial action, code execution, access management, or impact on an external object. The registry is built based on the actual configuration of the agent, orchestrator, and MCP Gateway, not project descriptions, and takes into account the direct bypass to the target system and third-party provider tools. A capability not described in the registry gets rejected before reaching the target system; the registry version is linked to the release. The model's response does not limit the actual privileges. These are determined by the available endpoint, backend identity, and permissions for the target. {#ai-agent1-manual-check} **Manual check** 1. Map the capability registry to the configurations of the agent, MCP Gateway, backend, and target permissions. 1. For each registered capability, perform one safe allow test; an action with a stronger effect than described gets rejected before calling the target system. An unaccounted tool or a broader actual action blocks the release. {#ai-agent1-artifacts} **Artifact** * Capability registry. * Mapping to configuration. * Registry version. * Test events. ### Autonomous execution has limits and stop conditions {#autonomous-execution-limits-stop-conditions} {#ai-agent2-id} Requirement ID: `AI-AGENT2` {#ai-agent2-requirement} **Requirement** The organization must assign a scenario owner and set limits on the number of steps, execution time, cost, concurrency, retries, and stop conditions. For each limit, you must specify its enforcement point and the safe state to fall back to if the counter fails or a dependent service becomes unavailable. The agent must stop the loop in the event of a recurring error, lack of progress, policy violation, limit exhaustion, or task revocation. It is the orchestrator that enforces counters outside the model; documented MCP tool limits must not serve as security controls. There must be a server-side stop state that, once set, prevents any further actions in the target system. {#ai-agent2-implementation} **Implementation** The limit values depend on the risk and cost of the scenario and must be approved by the owner. [Monitoring alerts](../../monitoring/concepts/alerting/alert.md) and [Yandex Cloud Billing budgets](../../billing/operations/budgets.md) may detect some of the consequences, but alerting is not a substitute for limits and stop controls enforced within the orchestrator or runtime. {#ai-agent2-check} **Check** Create a test with a looping tool response, recurring error, and exhaustion of one of the limits. The agent must stop execution within the specified boundary and take no further external actions. The reason for termination must be recorded, and the log or trace must show no subsequent calls to the target system. {#ai-agent2-artifacts} **Artifact** * Cyclic response, recurring error, and limit exhaustion test. * Policy version and counter configuration. * Final reason for stopping. ### Agent's goal and authority originate only from trusted sources {#agent-goal-authority-from-trusted-sources} {#ai-agent-goal1-id} Requirement ID: `AI-AGENT-GOAL1` {#ai-agent-goal1-requirement} **Requirement** The task objective, system policy, and allowed set of actions must come from a trusted configuration or a verified application solution. A user message, RAG chunk, tool response, or another agent's response must not expand authority, change the data owner, or lift a limitation. The objective is formed as a typed object from an authenticated server source; the initiator, objective and policy versions, and allowed capabilities are preserved. The application must separate facts, suggestions, and control instructions. The change of the trusted objective is logged as a configuration change, not as a regular continuation of the dialog. Any change to the objective goes through a new authorization and confirmation and creates a new version. {#ai-agent-goal1-check} **Check** Provide three synthetic instructions via the user, RAG, and tool to expand the objective or disable control. The agent can use the data as context but must not gain a new privilege. There must be no new action in the target system. Upon failure, the session is stopped, the affected delegation is revoked, the parsing or trust labels are corrected, and the test is repeated. {#ai-agent-goal1-artifacts} **Artifact** * Test of target expansion via user, RAG, or tool. * Target version and delegation. * Confirmation that there is no call for the target system. ## Tool identity and human confirmation {#tool-identity-hitl} ### Each tool uses a separate account with minimal privileges {#each-tool-has-separate-minimal-identity} {#ai-iam-leastpriv3-id} Requirement ID: `AI-IAM-LEASTPRIV3` {#ai-iam-leastpriv3-requirement} **Requirement** Any tool that can access the target resource must use a dedicated account with least-privilege permissions for specific operations. Unrelated tools must not share a single administrative service account. The backend must verify the user or the authorized delegation context; a username provided to the model as an argument is not proof of authorization. The following must be recorded for each tool: the calling subject, runtime service account, target system resource and action, exact role and scope of binding, secret, and network path. If the technical architecture does not support propagating user context, the backend must apply a predefined service policy and narrow down the resource scope to the required minimum. This limitation must be explicitly stated in the agent’s capability description. A service account may only be reused within a single approved boundary with the owner, data, and actions are the same; gateway invocation or management roles are not a substitute for target system access. {#ai-iam-leastpriv3-check} **Check** 1. For each tool, map the backend, service account, roles, and target resources. 1. Attempt to invoke another user’s operation or spoof the user ID. The authorization decision must come from the backend and IAM, and must not be inferred from the model text. The same identity must not be authorized to call an unrelated target system, manage IAM, or read an unrelated secret. {#ai-iam-leastpriv3-artifacts} **Artifact** * Backend, service account, and role mapping. * Spoofing test. * Tool matrix. * Secret IDs. ### Session authority is defined by a trusted delegation {#session-authority-defined-by-trusted-delegation} {#ai-iam-compromise1-id} Requirement ID: `AI-IAM-COMPROMISE1` {#ai-iam-compromise1-applicability} **Scope** This requirement applies when an agent acts on behalf of a user, tenant, or other session with different permissions. {#ai-iam-compromise1-requirement} **Requirement** Before calling the tool, the trusted component must verify the authenticated user, session, and tenant, and provide the backend with a limited delegation context. The backend independently verifies the exact resource and action; the agent cannot broaden their scope through tool arguments or its own judgment. Revocation of the user session, permission, or delegation must prevent subsequent actions, and the agent's persistent workload identity must not retain broader privileges. Short-lived IAM and ID tokens are only used for the documented audience; for each identity, the token audience, lifetime, binding scope, and emergency revocation method are recorded. The OIDC provider's compatibility is verified against the provider's documentation. If end-to-end delegation is not technically available, the service policy must restrict access to predefined resources and operations, and this restriction must be documented as an architectural property. Data and state for different sessions are kept separate under `AI-INFRA6` and `AI-INFRA-ISOL2`. {#ai-iam-compromise1-check} **Check** 1. Perform an allowed action in your session, then attempt to spoof the user, tenant, resource, and action. 1. Revoke the test session or permission and repeat the call. The backend must reject both the spoofing attempt and the action after revocation, and the trace must show the verified context without retaining the delegation secret. The test set includes a modified audience or tenant and an expired token. {#ai-iam-compromise1-artifacts} **Artifact** * User/tenant spoofing and session revocation test. * Delegation record. * Token metadata (excluding secrets). * Revocation event. ### Actions with significant consequences are confirmed by a human {#material-consequence-actions-confirmed-by-human} {#ai-agent-hitl1-id} Requirement ID: `AI-AGENT-HITL1` {#ai-agent-hitl1-requirement} **Requirement** The organization must define actions that require approval by an authorized person, such as irreversible deletion, access changes, publication, payments, or sensitive data transmission. Prior to approval, the interface must display the purpose, object, critical parameters, and impact. Post-approval changes of parameters invalidate the approval. The approval is single-use and tied to the exact action, resource, parameter hash, requesting subject and session, expiration time, and risk summary. Whenever possible, the approver should not have execution credentials. Reused approval, expired approval, and self-approval must be rejected. {#ai-agent-hitl1-implementation} **Implementation** Approval cannot replace IAM or application-layer authorization. For low-risk or fully reversible actions, the organization may choose to automate execution and document this decision. {#ai-agent-hitl1-check} **Check** Initiate a high-impact test action, change one parameter after approval, and repeat the request. The action without a valid approval must be rejected, and the trace must capture the subject and parameter version. {#ai-agent-hitl1-artifacts} **Artifact** * Unconfirmed action test. * Post-confirmation parameter change. * Confirmation ID and hash. * Target system event. ## MCP Gateway and target service {#mcp-gateway-target} ### MCP Gateway and target service access is separated {#mcp-gateway-target-service-access-separated} {#ai-mcp1-id} Requirement ID: `AI-MCP1` {#ai-mcp1-requirement} **Requirement** The owner must separately define the caller identity, Gateway invocation and configuration editing permissions, permission to manage bindings, the Gateway service account, and the target service’s permission to access the resource. Role semantics is defined in the [AI Studio access model](https://aistudio.yandex.ru/docs/en/ai-studio/security/index.html): `serverless.mcpGateways.invoker` is used to make calls, `serverless.mcpGateways.editor`, to update the Gateway, and `serverless.mcpGateways.admin`, to manage bindings. The CLI reference serves as a source of command syntax rather than the sole authoritative source of role descriptions. {#ai-mcp1-implementation} **Implementation** For each tool, the following must be recorded: the channel and backend URL, authentication method, allowed headers, input JSON schema version, and rule for handling unknown fields. Parameter size limits and action approval are application or orchestrator settings, not documented MCP Gateway configuration fields. The `mcp_approval_request` and `mcp_approval_response` Responses elements serve as evidence only for the documented path. The `serverless.mcpGateways.anonymousInvoker` role is used for documented scenarios involving access to external MCP servers or template servers; the role name does not imply public or unauthenticated access. Gateway visibility is configured separately: a public MCP server allows unauthenticated agent access, whereas an agent accessing a private MCP server requires a service account IAM token or an API key with the `yc.serverless.mcpGateways.invoke` scope. These branches are described in the [MCP Hub overview](https://aistudio.yandex.ru/docs/en/ai-studio/concepts/mcp-hub/index.html) and [API key guide](https://aistudio.yandex.ru/docs/en/ai-studio/operations/get-api-key.html). Gateway visibility, client access, the Gateway service account, and target service reachability are verified independently. Gateway access permission does not prove that the target service authorized the operation. Access to the MCP Hub API requires an IAM token according to the [AI Studio authentication guide](https://aistudio.yandex.ru/docs/en/ai-studio/api-ref/authentication.html). Learn about HTTP tool parameters and how to link a service account in the [MCP Gateway creation guide](https://aistudio.yandex.ru/docs/en/ai-studio/operations/mcp-servers/create-brand-new-api.html). Terraform does not provide an official resource for the gateway; a private VPC endpoint does not disable access through the public address. The `--tools-file` operation replaces the entire tool list. Without explicit documentation, a native Lockbox link for arbitrary user-defined target system credentials is not supported. {#ai-mcp1-check} **Check** ```bash yc serverless mcp-gateway list yc serverless mcp-gateway get yc serverless mcp-gateway list-access-bindings yc serverless mcp-gateway list-operations ``` 1. Check the configuration, network, service account, bindings, schema, and authentication parameters. 1. Then make an allowed call, a call without the required role, an oversized request or a request with an unknown field, and a direct call to the target service that bypasses the Gateway. The bypass must not provide more access. For application tracing, use documented AI Studio events, including MCP calls, but do not treat them as proof of complete authorization by the target service. For details, see the [AI Studio event reference](https://aistudio.yandex.ru/docs/en/ai-studio/at-ref.html). {#ai-mcp1-artifacts} **Artifact** * Gateway configuration. * Allowed and denied call. * Backend bypass. * GET result and gateway bindings. * Complete tool specification. * Public access status. * API key scope. ## Inter-agent messages and agent RAG {#interagent-rag} ### The other agent's message is checked as untrusted {#other-agent-message-checked-as-untrusted} {#ai-app-inject2-id} Requirement ID: `AI-APP-INJECT2` {#ai-app-inject2-requirement} **Requirement** An inter-agent message must include a verifiable sender, schema ID and version, task ID, expiration timestamp, trust level label, and protection against replay. The recipient must reject an unknown schema version and must not accept new authorizations or a trusted system instruction from the message. Cycles and redelivery are limited by `AI-AGENT2` rules. The sender communicates using permitted message types; the message cannot convey a valid system instruction, identity, confirmation, or extended purpose. If the message contains a RAG link or a retrieved fragment, the user's access permissions to the document must be verified before transmission to the model via `AI-RAG-ACL2`. Trust in the sending agent does not automatically transfer permissions for the data. {#ai-app-inject2-check} **Check** Send messages with an invalid schema, expired timestamp, duplicate ID, and spoofed sender: each of them must be rejected. An untrusted instruction to expand privileges may persist as data, but it must not alter the trusted objective or actual permissions. A rejection must not produce an effect within the tool or the target system; upon failure, the other agent's channel is isolated, and the sender's credentials are revoked. {#ai-app-inject2-artifacts} **Artifact** * Tests involving incorrect schemas, expired validity, duplicates, sender spoofing. * Sender identity and binding. * Schema and policy versions.