Introduction
Purpose and scope
This standard establishes security requirements and recommendations for artificial intelligence systems deployed fully or partially in Yandex Cloud. It targets security architects, information security specialists, developers, ML and DevSecOps engineers, service owners, SOC analysts, and compliance officers.
This standard applies to the following scenarios:
- Calling Yandex Cloud AI Studio's API and models.
- RAG based on AI Search or on a storage system selected by the organization.
- Agents, MCP Gateway, MCP servers, and other tools.
- Model training, experiments, and deployment in Yandex DataSphere.
- Using AI components in Yandex Managed Service for Kubernetes, Yandex Serverless Containers, Yandex Cloud Functions, and Yandex Compute Cloud.
- Using self-hosted models.
- Calling external model APIs from Yandex Cloud.
- Processing data, model artifacts, system instructions, secrets, and logs throughout the lifecycle.
This standard complements the Yandex Cloud infrastructure security standard. The general requirements for cloud accounts, networks, virtual environments, encryption, and audit logs remain in effect. This document establishes additional responsibilities arising from model call, untrusted context, RAG, autonomous actions, model artifacts, and AI application-specific telemetry.
The standard can serve as a basis for developing internal organization policies. Not all requirements may apply to a specific system; additional measures not covered by this document may also be required.
Responsibility
The limit of responsibility depends on the service and its consumption method. The general principle is described in the Yandex Cloud shared responsibility model.
Yandex Cloud is responsible for the managed part of the service within the limits of the published documentation. The organization operating an AI system is responsible for:
- Choice of clouds, folders, services, and their operating modes.
- Accounts, service account, keys, roles, and binding scope.
- Public entry points, network routes, and communication with external systems.
- Data storage permissibility, minimization, classification, and duration.
- Application-level validation of the model’s input, context, and output.
- Authorization of documents prior to feeding them to the RAG context.
- Authority of the agent and its tools.
- Application-level logs, event correlation, and response action.
- Releasing, replacing, and decommissioning data, indexes, models, and configurations.
The fact that a feature is present in the cloud service does not mean the requirement is fulfilled. The owner of the system must demonstrate that the feature is enabled or disabled for the resource in question, covers the actual data stream, and was tested in relevant scenarios.
How to apply this standard
Before verifying the requirements, a description of the actual or planned architecture is required. It must specify the following:
- Components, environments, and boundaries of trust.
- Entry points and callable model APIs.
- Clouds, folders, and resource IDs.
- Users, service accounts, API keys, and external entities.
- Data stores, RAG indexes, and storage locations for model artifacts.
- Paths of incoming, outgoing, and inter-component traffic.
- Agent tools, their backends, and target resources.
- Locations where personal and other regulated data are processed.
- Sources of audit, application, and operational logs.
- External data providers and recipients.
The word must denotes a mandatory requirement. The word recommended denotes a measure whose application depends on the risks and architecture. The word may indicates a permissible implementation method, but not the only one.
The applicability condition is written in plain text within the requirement. If a condition is missing from the architecture, the reviewer records which component, flow, or data type is missing. Lacking evidence of implementation does not constitute proof of inapplicability.
Exceptions
Exceptions are allowed only for a specific requirement, resource, and term. The system owner must document the rationale, affected assets, risk assessment, compensatory measures, responsible employee, end date, and review conditions. An exception must be approved by a party authorized by the organization. Upon expiration of the term, the requirement must be reviewed again.
A feature at the Preview stage or available upon request may be used as a control only after its availability to the organization has been confirmed. If it is unavailable, the owner chooses an alternative way of achieving the required state or requests an exception; the requirement remains applicable regardless of the availability of a specific product.
IDs
Independent, verifiable requirements have stable AI-* IDs. The ID is used for references and audit records and does not encode severity. A single ID always designates a single required state.
Evidence
The evidence must relate to the exact resource, version, subject, and time of verification. The record must specify the interface or command, expected and observed results, and a reference to the minimum required artifact: a configuration export, bindings, an event, an application trace, or safe test result. A design description without mapping to the actual configuration does not constitute evidence of implementation.
The evidence must not disclose secret values, excessive personal data, full conversation, or restricted documents. If the service does not publish the required event or configuration setting, this must be recorded as a blind spot and, where necessary, addressed through application logging or a manual test; lack of telemetry cannot be treated as a successful result.