Security standard for implementing and operating AI systems in Yandex Cloud, version 1.0.0

IntroductionIntroduction

Purpose and scopePurpose 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.

ResponsibilityResponsibility

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 standardHow 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.

ExceptionsExceptions

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.

IDsIDs

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.

EvidenceEvidence

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.

Secure architecture and development of AI applicationsSecure architecture and development of AI applications

An AI application forms an end-to-end path: user or system input, application logic, API, RAG sources, agent tools, external recipients, and telemetry. AI-SDLC1 registers where the subject's identity and privileges are established, where data becomes untrusted, where model output turns into action, and where the request crosses the boundary to leave the controlled zone.

The application must be divided into at least the following logical contours:

The presented scheme is a logical model for analysis, not a required physical topology: one component can implement several contours; and one contour can be comprised of several services. For each contour, the following must be defined: owner, allowed data streams, access mechanisms, audit events, and response procedures. A given AI system's architecture may lack any particular branch (e.g., no external calls or agent tools).

Architecture and changesArchitecture and changes

Architecture and risks are documented prior to releaseArchitecture and risks are documented prior to release

Requirement ID: AI-SDLC1

Requirement

Prior to the first production release and after any major update, the system’s owner must document all components, trust boundaries, data, subjects, model calls, tools, external connections, and the potential impact of errors or malicious behavior. This description must map each major risk to a specific boundary, measure, or check method.

For each mapping, you must state the source subject and resource, target resource or API, data class, protocol, authentication method, network path, event source, and owner.

Make sure to explicitly define these checkpoints: pre_model before calling a model, retrieval during data retrieval; pre_action before applying the tool, post_model after the model responds, and pre_egress before a request leaves the secure zone.

Implementation

An update is considered major if it introduces a new model or provider, data type, RAG source, tool, external recipient, public endpoint, role, or code execution method. The organization must define a procedure to review these updates and assign employees responsible for the approval. This requirement applies to every production system and every major update. The system-wide N/A result is not allowed. Before any work begins, you must agree on the conditions for revising the description and the approving party.

Manual check

1. Map the documented architecture to your deployed resources, routes, and accounts.
2. Select one allowed and one blocked data flow for each boundary.

You are compliant if all the production components are documented, and every boundary has a defined owner and a measure to check. An unmapped component or data flow means failure. You must either update your description and applicable requirements to include such an asset, or remove it from the production environment. After that, repeat the allowed and blocked flow checks.

Artifact

• Architecture description.
• Data flow diagram.
• Mapping to actual resources.
• Test results.
• Documented approval.

Input, context, and outputInput, context, and output

Untrusted input is verified before being used by the modelUntrusted input is verified before being used by the model

Requirement ID: AI-APP-WAF1

Requirement

The application must verify the type, size, encoding, structure, required fields, as well as validity of user and machine input before including the data into the model request or performing any other action. For each field and object type, the allowed values or an explicit rejection rule must be defined. The text, file, URL, search result, and external service's response remain untrusted whether or not they have passed the network perimeter.

Implementation

For public HTTP(S) entry points, Yandex API Gateway and Yandex Smart Web Security can limit requests at the levels of HTTP, WAF rules, bot activity, and frequency. This does not replace application-level validation of the prompt's semantic content.

The connection between API Gateway and an Smart Web Security profile is set by a documented OpenAPI extension; for profile capabilities, see Security profiles.

For additional moderation of requests and responses, you can use guardrails. However, this feature is in Preview and does not replace authorization, schema validation, or personal data processing. For more information, see this guardrail description.

For Serverless Containers, Cloud Functions, and Kubernetes without Smart Web Security, the same validator resides in the Ingress or application intermediate layer; security groups and network policies do not analyze the prompt and request body. The N/A result is acceptable only for the Smart Web Security branch, provided there is no HTTP(S) entry point, and does not cancel application-level input data validation. Semantic moderation of content pertains to AI-CONTENT1.

For a route with an Smart Web Security profile, both profile connection details and access log are saved.

Check

1. Send a valid request, a request with a missing or extra field, violated schema, exceeded limit, and content that should be rejected by the approved rule.
2. Check that each time the rejection occurs before the model call or another risky action, has a specific code or reason, and the log contains no secrets or excessive original content.

A valid request must get a correlation ID. Each rejection must be additionally confirmed by the absence of a subsequent model call or tool call event in the log or trace.

Artifact

• Rejection records.
• OpenAPI specification configuration and hash.
• Smart Web Security profile ID.
• Test requests and their results.
• Subsequent call absence confirmation.

Guardrails have defined categories and fault-tolerant behaviorGuardrails have defined categories and fault-tolerant behavior

Requirement ID: AI-CONTENT1

Scope

This requirement applies if an approved product, corporate, contractual, or legal policy prohibits individual content categories or if the architecture declares guardrails to be the protective measure. The N/A result is acceptable for a specific route only if the approved content policy does not require guardrails for that route.

Requirement

The owner must document the rule version subject to verification: input and output content categories, covered interfaces, action for each category, and behavior if the moderator commits an error or is unavailable. Actions may include blocking, restricting the response, forwarding for a manual review, or another approved reaction. An undefined moderator error must not quietly turn into a permission where the policy requires blocking.

Implementation

In AI Studio, guardrails can only be used within the published Preview function. A rule, dictionary, or classifier and theirs version are configuration objects; edits can be made by a subject with the documented ai.guardrails.editor role.

When blocked, the response has the incomplete status with content_filter for reason; however, these indicators do not replace application-level error handling. Guardrails do not decide whether data is legally admissible and do not replace the schema, IAM, personal data protection, document-level authorization, or agent action verification. For more information, see this guardrail description.

One guardrail is attached to a model instance; a custom guardrail overrides the system one, thus changing the effective category coverage. Management is effected via the management console (AI Studio → Management → Security → Guardrails); the software management interfaces are not documented, so an exported versioned configuration and manual evidence are required. Guardrails are not a WAF.

Check

1. For each approved category, perform allow test and deny test on each covered path. The request and response are checked separately. Request blocking is confirmed by not calling the model; and response blocking, by not displaying the result.
2. Separately simulate the moderator committing an error or being unavailable.
3. Record the rule version, observed action (incomplete status with content_filter as reason), Yandex Audit Trails management event pertaining to guardrail setup, and application record; a separate guardrail trigger event in Audit Trails is not documented and, if necessary, gets recorded as a blind spot.

A bypass via an uncovered interface or allowing where rejection is required means failure to comply. In the event of a false negative, change the category, threshold, or dictionary, wait for it to apply, and repeat the documented set of tests.

Artifact

• Rule version and exported configuration.
• Model instance and guardrail IDs.
• Blocking test.
• Management event or application record.

Model output gets verified prior to its rendering and executionModel output gets verified prior to its rendering and execution

Requirement ID: AI-CONTENT2

Requirement

The application must treat the model's output as untrusted data. Before displaying it as active content, forming a request, writing to storage, or executing a command, the application must validate the format, schema, permissible values, target object, and the calling subject's privileges.

If the model generates SQL, shell command, URL, file name, template, API call, or tool arguments, the application must use a separate deterministic validator and a list of allowed operations. Successful generation of text by the model is not an authorization for an action.

The response gets parsed into a typed object: unknown and missing fields are rejected, and values are escaped according to the target context rules (HTML, SQL, shell, or file name).

For a system that outputs only inert text, execution-related branches may not apply but a safe render is still mandatory. Output validation is implemented by the application: the native output schema validation mechanism in Yandex Cloud is not certified.

Check

Submit a synthetic response with an extra or privileged field, prohibited object, control sequence, HTML or script markup, invalid JSON, fragment of an SQL or shell command, and an unknown action. The requirement is met if the application rejects each such response prior to execution and logs the reason without recording sensitive data. None of the tests should result in a call for the target system, which should be confirmed by the absence of the corresponding event in the log or trace.

Artifact

• Model test responses.
• Rejection records.
• Validator code.
• Schema hash and policy version.
• Confirmation that there is no call for the target system.

System guidelines and policies must only be modified via a trusted pathSystem guidelines and policies must only be modified via a trusted path

Requirement ID: AI-CORE5

Requirement

System instructions, prompt templates, tool policies, routing rules, security configurations, and other trusted settings must be stored separately from user content, have an owner, object ID, and version, and must be modified only through an approved change process. If such a configuration exists, the N/A result is not allowed.

For the object, the reading and writing entities, revision history, and active version are recorded. A deployment record links the artifact hash of the instructions to a model or application version.

The application must not replace them with data from RAG, a tool response, or message from another agent. The runtime environment accepts a trusted set only from an approved release path.

Secrets should not be included in the system prompt. If the configuration is stored in Yandex Object Storage or another cloud resource, the access control, encryption, and versioning mechanisms documented for that resource apply; Object Storage versioning may be used as part of the revision history but does not replace the approval procedure. No native registry for prompts and policies is claimed for Yandex Cloud; cloud-based tools ensure secure storage and deployment, while trusted instruction management handles the application release process.

Manual check

1. Compare the active version of the configuration with the approved version and the subjects authorized to read and modify it.
2. Then, try to change the goal or policy via custom input and the RAG document.

This change must not be included in the trusted configuration. If the change has made its way into the active configuration, stop the release or agent operation, revert to the last approved set, rotate any exposed secrets, and rerun the original negative test.

Artifact

• Active configuration version.
• Release notes.
• Spoofing test result.
• Instruction artifact hash.
• Deployment event.
• Current version log.

External or retrieved context gains no implicit trustExternal or retrieved context gains no implicit trust

Requirement ID: AI-APP-INJECT1

Requirement

RAG chunks, web pages, files, emails, tool results, and other external data must be provided to the model as payload, not as trusted system instructions. For each chunk, the accessible source ID and the result of applied policy are saved.

The application must separate data from control instructions, process the retrieval or validation error in a fail-safe manner, and limit the consequences if an external context attempts to change the objective, disclose a secret, or initiate an action.

Labeling is assigned during the upload: immutable source and document IDs, owner, trust level or data class, and version. External content cannot select a tool, action, or recipient.

AI Search does the uploading, chunking, vectorization, and searching for documents. The application must separate the found data from control instructions, and limit their impact. For the service capabilities, see this AI Search guide.

Check

Put into a test source a document with a known ID and an instruction to change a system policy or call a tool.

The requirement is met if the instruction is treated as data, changes no privileges, and does not lead to an action without a separate verification, and the trace links the result to the source and policy decision. The system may quote or paraphrase such content, but there must be no tool events or target system events.

Upon failure, quarantine the document or index version, disable the affected search source, fix the policy or parser, rebuild the index, and repeat the test.

Artifact

• Test document with instructions.
• Policy decision trace.
• Search result IDs.
• Quarantine or reindexing record.

External connections and public perimeterExternal connections and public perimeter

External model API calls pass through a managed boundaryExternal model API calls pass through a managed boundary

Requirement ID: AI-NET3

Requirement

If the AI system calls a model API outside Yandex Cloud, the owner must define the allowed endpoints, types of transmitted data, service account or another workload identity, secret storage location, route, timeouts, and logging. The application must exclude any unapproved recipient and must not transmit data lacking the required authorization. The list of recipients and transmitted data categories must be reviewed whenever the provider, model, processing region, contract, data schema, or network path changes.

The provider key must be stored within a dedicated storage in compliance with AI-SECRET1; however, its scope, expiration, and revocation must be verified in the provider system. The IAM policy does not create a private network path to an external provider; such a path may only be claimed when documented officially by the provider.

The Yandex Virtual Private Cloud route table and NAT gateway define the network path, but they do not by themselves filter the domain name, recipient, or request content. For the documented properties of the routes and next hop, see the VPC routing description. Where recipient restrictions are required, the organization must implement them through an appropriate proxy, firewall, or application and verify the actual TLS endpoint.

Check

1. Make one allowed call and one call to a non-whitelisted test endpoint.
2. Check the route, DNS/TLS destination, absence of the secret in the log, and the correlation between the application record and the external request.

Whether the data may be transmitted is verified separately according to Compliance and processing of personal and regulated data. The denied call must not appear in the provider’s log; any credentials exposed during the check must be rotated and must not be reinstated.

Artifact

• Proxy and firewall configuration.
• Allowed and denied call record.
• Secret ID.
• Call correlation log.

Public HTTP(S) perimeter has an explicit protection schemePublic HTTP(S) perimeter has an explicit protection scheme

Requirement ID: AI-NET7

Requirement

For each public endpoint, the owner must record the domain, route, authentication method, rate limit, maximum request size, logging policy, and internal backend connection. Direct backend access must not bypass the checks established for the public path.

Implementation

API Gateway supports authorization via documented extensions, including JWT authorizer, and Smart Web Security integration. Do not assign a non-existent generic invocation role to API Gateway: the authorization method depends on the OpenAPI specification and backend integration. Smart Web Security logs events within its documented log model. A list of allowed requests does not substitute for a complete application log.

The Smart Web Security rate limits protect the relevant HTTP route but do not apply to model token costs or content semantics. The N/A result is allowed for a closed internal system without a public route, but partner endpoints must comply.

Check

1. Compare your published OpenAPI specification, domain, and backend to make sure they match.
2. Test a request without credentials, request with invalid credentials, request exceeding the limit, and a direct request to the backend.

Access must match the specified schema, and there must be no way to bypass the perimeter. Match gateway or Smart Web Security logs and target system logs using the unified correlation ID. Run this test from both from a public and private source. A prohibition and disabled public access indicate a safe disaster state.

Artifact

• OpenAPI specification.
• Unauthenticated requests.
• Backend bypass test.
• Specification and Smart Web Security profile IDs.
• Bindings.
• HTTP test results.

Data, training, models, and releasesData, training, models, and releases

The requirements of this section apply to lifecycle objects that actually exist. For managed inference without custom tuning, there are no requirements for the training environment or loaded weights; however, there are still requirements for input data, RAG corpus, application configuration, and model version. For RAG without tuning, a model release is a coordinated combination of the model, index, system instructions, and applied configuration.

Data intake and preprocessingData intake and preprocessing

Each dataset has an owner, provenance, and allowed purposeEach dataset has an owner, provenance, and allowed purpose

Requirement ID: AI-DATA1

Requirement

Before ingestion or use, the system owner must register the dataset or RAG corpus: source, owner, lifecycle stage, sensitivity category, purpose, version, transformations, use limitations, permitted recipients, and communication with the system, model, index, or release. For an external source, the receipt and acceptance conditions must be additionally recorded. Synthetic data is marked separately as per AI-DATA7.

The record is created before the set is ingested; if the set is changed, a new record version is formed. If the system uses only the managed model API and does not maintain its own sets, permitted data categories and the evaluation set are recorded anyway.

Implementation

Yandex Cloud provides storages and access control tools but does not form the registry of origin and permitted use for the organization. DataSphere delimits access to communities and projects; a published DataSphere access model does not replace the record of origin for a specific set. The record is associated with the exact object version in the actual storage: Object Storage object version, Vector Store ID or index ID, location in Yandex Managed Service for OpenSearch or Yandex Managed Service for YDB, or a DataSphere set.

Manual check

1. Select at least one internal, one external, and one synthetic set, if used.
2. Trace the process from a registry record to the actual object and version.
3. Additionally, select sample objects from the expanded corpus and trace each one up to the record; an object without a record gets rejected during ingestion or release, quarantined, and gets an owner, source, and classification, or gets deleted according to storage rules.

An unaccounted or unauthorized source must not end up in a training, evaluation, or index.

Artifact

• Registry record.
• Tracing up to object and version.
• Card version.
• Object version or hash.
• Approver.

RAG loader is restricted to an approved source and destinationRAG loader is restricted to an approved source and destination

Requirement ID: AI-RAG-INGEST1

Scope

This requirement applies if the system creates or updates a RAG corpus or a search index.

Requirement

The loader's service identity must read only from approved sources and write only to the designated staging area and the target index. It should not have the permission to modify another production corpus simply because it resides in the same cloud or folder.

The source, version, acceptance check result, loading entity, and publication decision are linked to the update operation. Loading and search identities are separated.

Prior to recording, the loader verifies the source card, type, size, hash, and mandatory tenant and access metadata; an unapproved package is placed in quarantine.

Implementation

For AI Search, the source object, file, vector store, and management roles are recorded.

For Managed Service for OpenSearch, YDB, or another storage solution, the specific roles, network boundaries, and configuration objects of the selected service are used.

The architecture can distribute reading from the source, writing to an intermediate area, and publishing across multiple identities.

In AI Search, an index is created by a documented flow (AI Studio → AI Search → search indexes); Terraform manages the infrastructure but not corpus admission.

Check

1. Read from the approved source, write to the designated staging area, and publish a test version.
2. Then, verify that reading from an unapproved source and writing to an unauthorized index or area are rejected.
3. Rejection due to a modified hash or an invalid tenant is checked separately, prior to indexing.

The record must link the published version to the source, verification, and change subject. In the event of a failure, the loader pauses, the package is quarantined, the affected index segment is deleted or rebuilt, the compromised identity is replaced, and the test is then repeated.

Artifact

• Successful upload of an approved object.
• Rejection of an unapproved source.
• Loader version.
• Acceptance and rejection events.
• Reindexing record.

Data stages are separatedData stages are separated

Requirement ID: AI-DATA3

Requirement

Source, cleaned, marked-up, training, evaluation, or published data must be distinguishable by objects or versions, write permissions, and advancement rules. Transition between stages takes place only after a relevant check and decision.

Updating an already approved object requires a new version and re-admission. The production environment must not change the production corpus directly. By default, the network and IAM must not give the record back or between parallel stages.

If one immutable input is used directly without derivative stages, the N/A result is allowed only for absent branches.

For Object Storage, you can use separate buckets or prefixes, access policies, and versioning.

For network storages available online, VPC security groups are used where the service supports them. The particular scheme must suit the selected service, not be transferred from one storage to another.

In AI Search, uploading a file and creating an index are treated as different lifecycle objects.

Check

Check the path of one record from the source object up to the published version, subjects authorized to write at each stage, and the impossibility to write from the production environment to the source or evaluation set. The derived results created during the violation are recognized invalid, and the pipeline is repeated after narrowing down the access.

Artifact

• Bucket/prefix access policies.
• Record test from the production environment.
• Stage schema.
• Input and output versions.
• Transition log.

Data was classified and minimized prior to being forwarded for AI processingData was classified and minimized prior to being forwarded for AI processing

Requirement ID: AI-DATA4

Requirement

For each field or object type, the data owner must define a sensitivity category, allowed recipients, and an allowed action: retain, delete, aggregate, mask, or tokenize. Fields, records, attachments, and secrets that are irrelevant for the stated scenario must be removed before transmission.

If using reversible transformation, its execution location, acceptable reversibility, and subjects with access to the key or mapping table must be defined.

Fields are mapped based on the destination: prompt, RAG context, tool data, external call, and log event; data must be deleted or transformed before crossing the boundary, not after delivery to the provider or model.

Implementation

Data Security Posture Management (DSPM) can be used to search for specific data categories in supported sources. It does not transform the source data or establish the lawful basis for processing.

For info on the source scope, service account with the dspm.worker role, and extra permissions for KMS-encrypted buckets, see the DSPM guide on creating a scan. Discoveries from DSPM or NER are not transformations: the detected candidate must confirmed by a human reviewer or application logic.

Check

1. Take a sample from the actual input dataset post-transformation and check it against the approved schema.
2. Try to upload prohibited fields or object.

A detection report alone, without source remediation, does not confirm minimization. Any additional sensitive field must be blocked or modified before the call and must not appear in logs. If the test fails, the affected flow must be stopped, and all cached, indexed, and logged copies must be deleted according to applicable retention policies and legal requirements. After that, the test is must be repeated.

Artifact

• Field schema.
• Post-transformation selection.
• Rejection of prohibited fields.
• Field mapping by destination.
• Record of copy deletion.

Data quality and independence of assessment are verified prior to releaseData quality and independence of assessment are verified prior to release

Requirement ID: AI-DATA5

Requirement

The organization must define the input versions, metrics, thresholds, and known limits for checking quality, completeness, and acceptable bias for a specific scenario. Training and evaluation samples must be separated so that leakage between them does not compromise check results. For RAG, chunking quality, relevance, metadata completeness, and search reproducibility must be checked. Checks must evaluate completeness, duplicates, schema, distribution, sources, and overlap between the training and evaluation samples.

If synthetic data is used, the report must specify its proportion, retrieval method, and impact on the score. There is no single cloud-wide quality threshold. The product owner must approve the criteria in coordination with the risk officer.

The result must be approved by an independent reviewer, non-affiliated with the data producer. The report must be linked to the exact version of the dataset, model, or index. If there is no managed dataset, the N/A result is only acceptable if the model or API selection undergoes independent review.

Manual check

1. Repeat the approved assessment on a fixed data version and configuration.
2. Make sure there are no matching IDs or other signs of leakage. Also, check the report you saved specifying the initial version, criteria, and result.

Any data batch containing duplicates, corrupted schemas, prohibited data, or overlaps between the training and evaluation samples must block the release. Such batches must be quarantined, the source or transformation fixed, a new report generated, and check repeated.

Artifact

• Saved report with version, criteria, and result.
• Code version for checks and tests.
• Dataset hashes.
• Independent reviewer.

Data and/or RAG corpus changes are controlledData and/or RAG corpus changes are controlled

Requirement ID: AI-DATA6

Requirement

Source, intermediate, and published versions must have verifiable IDs or checksums. For every process, the system must record the owner, change creator, code or configuration version, performed checks, decision to publish, and rollback procedure to restore the previous secure version. Ingestion, cleansing, chunking, indexing, and publication must be handled by a trusted identity through a repeatable workflow. An non-verified object must not become available to the production system.

The acceptance check must align with the source risk level and, prior to publication, detect unsupported formats, corrupted structure, unexpected executable content, and categories prohibited by the organization. Model traffic moderation does not replace a full review of the dataset.

Implementation

In Object Storage, you can enable versioning to track object history, and, to enforce immutability, use object locks considering their rules and timelines.

In AI Search, uploading files and creating a vector store is part of the documented indexing process. The application must separately implement document authorization and content admission.

A manifest maps a logical release to the exact IDs and hashes of objects, files, and indexes. Each change creates a new version and enforces a new approval; the only copy is never overwritten. The object lock is enabled only after the retention period is approved: locked versions may become undeletable. For storages without versioning, an immutable release copy and change record are saved.

Check

1. Trace a published version from the source object to down to the index or dataset.
2. Attempt to bypass a check and publish a modified object.
3. As a separate step, use a synthetic object to check that a new version is created while you retain access to the previous version and can use it for recovery.

The requirement is met if the bypass attempt is rejected, and the saved data allow you to identify the active version and change initiator.

Artifact

• Version-to-source mapping.
• Check bypass test.
• Release manifest with hashes.
• Change event.
• Recovery test.

Synthetic data is accounted for separatelySynthetic data is accounted for separately

Requirement ID: AI-DATA7

Scope

This requirement applies if synthetic data is used for training, fine-tuning, or evaluation.

Requirement

For the synthetic portion of the dataset, the following must be registered: generation model or method, generator version and parameters, purpose, source data, share of synthetic records, and known limitations. Synthetic records go through the same admission and quality assurance stages as other data; their provenance must not be mixed with observed data.

Each synthetic record or batch gets the synthetic=true label; unprocessed generated data is not included into training or evaluation unless explicitly approved. The final batch receives a separate ID and dataset hash.

Implementation

When generated via AI Studio or DataSphere, the record contains the available IDs of the model, API, project, or task. Yandex Cloud does not maintain a universal registry of synthetic data for the organization.

Check

1. Trace the synthetic sample version back to the generator, source data, and parameters.
2. Check that the report shows its share and separately evaluates the required properties versus a non-synthetic control sample.

A generated test case without a label must be rejected at ingestion.

Artifact

• Synthetic portion record.
• Share and control sample report.
• Generator version.
• Unlabeled data rejection test result.

Training and model artifactsTraining and model artifacts

Development, training, and production execution are separatedDevelopment, training, and production execution are separated

Requirement ID: AI-TRAIN1

Requirement

If the organization trains, fine-tunes, or runs experimental models, such workflows should be isolated from the production system at the project, namespace, service account, access control, storage, and network path levels in line with the selected environment. Experimental workloads must never have access to production secrets or permissions to change production data simply because they run in the same cloud.

For each job, a secret must only be provided to its workload identity with minimal privileges. Do not store secrets in notebooks, datasets, container images, or logs. Limit outgoing traffic to approved sources, recipients, and scopes. Open internet access may allowed as a rare exception that has an owner, time limit, and compensatory control.

The secret delivery method and network controls are environment-specific and must be reviewed against the requirements from IAM, network, encryption, secrets, and audit and Implementation profiles in Yandex Cloud.

Implementation

In DataSphere, permissions are granted at the community and project levels based on this access management guide.

Managed Service for Kubernetes also separates IAM cluster access and Kubernetes RBAC. For namespace, network policy, and metadata security best practices, refer to this Kubernetes security guide.

For systems that only access a managed model API without training, the N/A result applies to this entire requirement.

For DataSphere, the service account, project network and security groups as well as job evidence are recorded. Management events do not prove the origin of data within a notebook or job.

For Kubernetes, a separate namespace or cluster with a workload identity, RBAC, and network policy is used.

For Compute Cloud, a dedicated service account, security groups, encrypted disk, and secret delivery path are configured.

A workload identity does not modify the production artifact pointer; the release copies the exact approved artifact.

Check

1. Compare the users and service accounts across the experimental and production environments.
2. Attempt to read a production or another subject’s test secret, modify a production object, or access a restricted endpoint from the experimental environment and unrelated job.
3. Also confirm that a development or training subject cannot deploy or overwrite a production version.

An allowed job must only get the assigned secret and source; unauthorized actions must be denied, and logs must not contain the secret value. Acceptable variance must be documented as an exception. Artifacts created within a compromised boundary are considered invalid and must be rebuilt once isolated.

Artifact

• Contour mapping.
• Unauthorized secret read and production write test.
• Hashes of job input and output objects.

Model package has verifiable provenanceModel package has verifiable provenance

Requirement ID: AI-MODEL1

Requirement

For a self-hosted or third-party model, the owner must record its source, version, checksum, licensing and operational limitations, weight format, tokenizer, configuration, ingestion code, dependent software components, related data versions, approval status, and check results.

For a managed API, the model vendor, API, ID, or version as well as available parameters affecting its behavior are recorded instead of unavailable weights.

The record must uniquely identify the package that has passed the check and is now used in the release. Approved artifacts are copied to a controlled storage; in a production environment, direct ingestion based on a dynamic external URL is not permitted because the production environment only ingests an exact digest.

Object Storage can store the package files, Yandex Container Registry can store Docker images, and DataSphere can store documented resource types, including models, Docker images, and file storages. The organization must link together the actual objects and versions in a separate provenance record no matter where they are stored. See the description of resource boundaries in the Container Registry and DataSphere guides.

Manual check

1. Find out the model package of the running instance and compare it with the admission record.
2. Recalculate the digest of deployed files and images and compare it against the record. A modified artifact or unknown source would block admission be quarantined.

A mismatch of weight, configuration, loader, or dependency requires a new check.

Artifact

• Provenance record.
• Mapping to a running instance.
• Model card.
• Hashes and versions of objects in storage.

Model format and loader do not allow arbitrary executionModel format and loader do not allow arbitrary execution

Requirement ID: AI-MODEL2

Requirement

Before using an external model package for the first time, the organization must assess the properties of its format, supporting code, custom loader and dependencies, eliminate unnecessary code execution, verify the checksum, and run the first launch in an isolated environment without production secrets or write access to production stores. Choosing a format depends on the risk. The extension name alone does not prove security.

The admission rules must list the allowed formats and exact versions of loaders for the framework in use. Executable deserialization of an untrusted artifact must not be used if a compatible secure format exists.

Implementation

The Container Registry scanner analyzes Docker image vulnerabilities rather than model behavior, weight contents, or data poisoning. For information on scanner scope, refer to this guide.

Check

Repeat running the fixed package in an isolated environment while observing file, network, and process activities. If you observe unexpected code execution, external state changes, or checksum mismatch, using the package is prohibited. The initial check concludes upon an expected smoke test result, after which the check’s one-time environment is wiped out.

Artifact

• Isolated execution result.
• Activity monitoring.
• Format and loader versions.
• Isolated environment configuration.
• Admission decision.

Release, rollback, and revocationRelease, rollback, and revocation

Only the exact verified version is admitted into the production environmentOnly the exact verified version is admitted into the production environment

Requirement ID: AI-REL1

Requirement

The release decision must bind the exact versions of data or index, model package, system instructions, app configuration, image, check results, current exceptions, and the approvers. Building and publishing must be handled by a trusted process. The release result must match the approved package; manual component swapping after the check is prohibited.

The deployment must use the release manifest, not the default tag or name. For serverless runtimes, use the exact revision or version, for Kubernetes, image digest and configuration, and for AI Studio, IDs of the model instance, guardrail, and index.

Implementation

For a containerized release, an image scanning result may be part of the release decision, but the organization must set the acceptance threshold and deadline for fixing vulnerabilities. Image scanning does not replace the model package and data checks.

Check

Use a production revision to restore all listed versions and the release decision. The requirement is met if the model package is unambiguous, reproducible, and it matches the approved one. The latest tag or an unapproved discrepancy between the actual revision and manifest means failure.

Artifact

• Release decision.
• Production revision mapping.
• Release manifest hash.
• Deployment event.

Version replacement, rollback, and revocation are managed explicitlyVersion replacement, rollback, and revocation are managed explicitly

Requirement ID: AI-REL2

Requirement

The model, index, and associated configuration must each have defined compatibility requirements, phased replacement sequence, rollback criteria, previous safe compatible set, and method for revoking an unsafe version. A rollback must not reintroduce a known vulnerability, prohibited data, or a revoked secret. Revocation must cover every production endpoint, alias, direct reference, and workaround that could have been used to select the version.

Implementation

Service-specific tools are used only within their documented scope: Serverless Containers revisions and deployment and rollback events from the Audit Trails reference, Object Storage object versions, or the application's own versioning scheme. The availability of object history does not guarantee a functional rollback of the entire AI system.

The rollback target is defined per environment: for serverless environments, it is the previous verified revision or version; for Kubernetes, the previous image and configuration; for Compute Cloud, the image, disk, and configuration recovery plan; for RAG, the previous corpus or index manifest, or a rebuild procedure; for AI Studio, the previous instance, guardrail, and index configurations.

Before release, backward compatibility of the data and index is verified. A reference to a previous version without a specific ID and verified compatibility is not considered a rollback plan.

Check

In the test environment, perform the replacement and rollback of the related package.

1. Check that the active version can be identified, the log associates the initiator with the change, and the revoked version cannot be selected through the standard process.
2. The rollback rehearsal includes switching to the previous target, functional and security checks; reverting to the new version can only be performed after approval.

A rollback is not considered valid if it exposes data from a newer state.

Artifact

• Replacement and rollback test.
• Initiator log.
• Revoked version unavailability.
• Rollback target IDs.
• Return approval.

IAM, network, encryption, secrets, and auditIAM, network, encryption, secrets, and audit

In this section, a subject may refer to a person, service account, agent, MCP client, or tool backend. The access model from AI-IAM-LEASTPRIV1 binds the subject, operation, resource, role, or any other policy and assignment level. Permissions for a cloud resource do not replace application-layer user authorization within the AI system.

Permissions and accessPermissions and access

Intercomponent connections are limited by the actual topologyIntercomponent connections are limited by the actual topology

Requirement ID: AI-NET2

Requirement

The system owner must define permitted inbound, outbound, and intercomponent connections between the application, model API, RAG store, agent, tool, and logs. For the purpose of communication, the following are recorded: purpose, owner, source, recipient, and application authentication method. Where the service supports VPC and security groups, the rules must allow only the necessary directions, protocols, ports, and sources.

Implementation

VPC security groups track connection status. They do not perform document-level authorization, nor inspect the semantics of model requests.

For serverless and managed services, the published network connection method must be verified separately. The Serverless Containers and Cloud Functions network connection controls outbound access to a custom VPC but does not constitute a private ingress to the instance. The managed AI Studio API is not assigned any custom subnets or private endpoints that are not documented. Yandex Identity and Access Management does not replace the internal Kubernetes or OpenSearch RBAC at the data level.

Check

1. Map the rules to the stream diagram and execute an allowed and a denied connection for each boundary.
2. Pay special attention to broad access rules, shared service accounts, and paths bypassing the gateway.
3. Check the actual connection, route, and application denial, not just the security group configuration; when fixed, a broad rule is not replaced by a 0.0.0.0/0 rule.

Artifact

• Flow diagram.
• Security group rules.
• Allowed and denied connection.
• Connection results from allowed and denied sources.

Workload identities have minimal effective permissionsWorkload identities have minimal effective permissions

Requirement ID: AI-IAM-LEASTPRIV1

Requirement

The production component must be executed under a separate workload identity, not always the developer's personal account. For each subject, the owner must associate the required operation with the minimum documented role and the narrowest supported assignment scope. The agent or model output is not the reason for authorization: the decision is made by IAM or backend possessing a checked user identity.

Implementation

The check takes into account direct, group, and inherited bindings. The resource and role model principles are described in this IAM guide.

If the organization uses IAM access policies, this feature complements roles with explicit prohibitions.

The whole of the CIEM (Cloud Infrastructure Entitlement Management) module, as part of Yandex Security Deck, is at the Preview stage and can be used only after an availability confirmation. It shows assigned access permissions, including direct and obtained through groups, but does not say which permission is excessive instead of the organization.

For viewing, you need the organization-manager.viewer role for the organization or a broader documented role. For more information, see CIEM and Viewing a list of a subject's accesses. Access revocation has additional restrictions by roles and group types and is not treated as available just because viewing is available.

The service account of the runtime environment is separate from the deployment identity and the administrator. The actual minimum of permissions is confirmed by a controlled test, not only by mapping to examples of documentation.

Check

1. For each production subject, export effective direct and inherited permissions in the cloud, folders, and target resources.
2. Map each role to an operation.
3. For Kubernetes, additionally check RoleBinding and ClusterRoleBinding.
4. For the key workload identity, run a permitted operation and an adjacent forbidden operation of creating, deleting, or reading another resource: the last one should be denied.

An unused, broad, or unjustified role must be deleted or formalized as an exclusion.

Artifact

• Effective direct and inherited permissions.
• Role-to-operation mapping.
• subject → operation → resource → role and scope → binding level matrix.
• Masked key scopes.

AI Studio call uses a documented authentication methodAI Studio call uses a documented authentication method

Requirement ID: AI-IAM4

Requirement

The AI Studio client must use an IAM token or API key of the service account and a role matching the selected API. Use the ai.languageModels.user role for text generation, ai.assistants.editor together with ai.languageModels.user for the Responses API, and ai.models.user for the Realtime API. These roles are API-specific; always consult the respective API guides before using them with a different API. For information about headers and minimum roles, see this AI Studio authentication reference.

An API key must have explicitly defined scopes and a limited lifetime or an approved review period. To select a scope, refer to the target API guides and the current list of available scopes. Do not use one single scope for all models. To learn more about key management and scope behavior, see this IAM guide.

If your API supports IAM tokens, opt for a short-lived one.

To run a Vector Store search, you need the yc.ai.foundationModels.execute scope. You cannot replace it with yc.ai.languageModels.execute or any other similar scope.

Implementation

You can check the scopes of any API key in the management console or through the API with the key metadata output. To find out how to view scopes, refer to the current version of the IAM CLI reference or the management interface.

Check

yc iam api-key list --service-account-name <service_account_name>

1. Map each key’s metadata to the key’s owner, API you are calling, assigned scopes, and lifetime.
2. View the current scopes via the management console or API, or by running the yc iam api-key get command.

Do not output the secret value in the check report. Allowed calls should succeed, while API calls outside the selected scopes, or those using expired or revoked keys, must be rejected.

Artifact

• Key metadata without the value.
• Owner and API mapping.
• Service account bindings.
• Key lifecycle in Audit Trails.
• Results of the allowed and denied calls.

Effective permissions are reviewed on a schedule and after changesEffective permissions are reviewed on a schedule and after changes

Requirement ID: AI-IAM5

Requirement

For production identities, the access owner must establish the frequency of reviewing the organization policy and conduct out-of-schedule reviews after major updates to the architecture, responsibilities, group membership, external integrations, or the delegation method.

The scope of review encompasses direct assignments, group membership, and inherited permissions; to check the list of direct bindings alone is not enough. The scope covers organization, cloud, folder, and resource-level bindings, API key scopes, and the internal RBAC of the selected storage or runtime, e.g., Kubernetes or Managed Service for OpenSearch.

The result must contain the date, covered subjects and resources, the reviewer, the decision for each excessive or unconfirmed permission, and valid exceptions. The review must identify primitive or overly broad roles, assignments above the required resource scope, and capabilities the subject is not actually using for the approved operation. CIEM can be used to view assigned access permissions within its documentation; the decision on whether a permission is required remains up to the organization's policy.

CIEM unavailability is a branch condition, not the result of N/A for control: in this case, IAM exports and disclosed group membership are retained as manual evidence.

Check

1. Select a workload identity, a user with group access, and a subject with an inherited role.
2. Compare the current effective state against the last dated review record and changes made after it.

An overdue review, an out-of-scope inheritance branch, or a permission without a decision means failure to comply. An unused, orphaned, or shared permission and an overly broad role are finds; permission removal has to be confirmed by a repeated negative test.

Artifact

• Dated revision record.
• Decisions on excessive permissions.
• Origin of permissions.
• Exception period.
• Repeated negative test.

Privileged user accounts use MFAPrivileged user accounts use MFA

Requirement ID: AI-IAM-MFA1

Scope

This requirement applies to users that have administrative access to AI system resources in Yandex Cloud, either directly or through a group. It covers roles that allow managing access, secrets, AI Studio, DataSphere, runtime, networks, storages, logs, and other resources used by the AI system.

Requirement

Multi-factor authentication (MFA) must be enabled for every privileged user. MFA must be enabled before granting privileged access and remain enabled until that access expires.

For local and federated Yandex Identity Hub users, MFA is configured in Yandex Identity Hub. For external federation users, you must verify that the identity provider has enabled and enforced MFA for the user or group with assigned Yandex Cloud roles.

Service accounts, API keys, static keys, and other technical credentials do not replace MFA for a person who manages access to or resources of the AI system.

Implementation

The access owner defines the privileged roles and groups used in the AI system and maps them to users. Role assignments at the organization, cloud, folder, and resource levels are reviewed, including direct assignments and assignments to groups.

At a minimum, broad roles, such as admin and editor, are reviewed, as well as administrative roles in IAM, Yandex Identity Hub, Lockbox, Audit Trails, AI Studio, DataSphere, Managed Service for Kubernetes, Serverless, Compute Cloud, VPC, Object Storage, Container Registry, YDB, and OpenSearch if the relevant services are part of the AI system architecture.

Exceptions are allowed only for a specific user, role, or resource and must have a documented justification and expiration date. Exceptions for an entire group or federation are not allowed.

Check

1. Get a list of role bindings at the organization, cloud, folder, and critical resource levels for the AI system.
2. Expand groups to individual users and identify users with privileged roles.
3. For every such user, verify the MFA status in Yandex Identity Hub or in the external IdP in use.

The requirement is met if MFA is enabled for every privileged user or a valid documented exception is in place.

After remediating the non-compliance, verify again that MFA is enabled or that the privileged role has been revoked.

Artifact

• List of privileged roles and groups.
• Export of role bindings.
• List of users with permissions inherited through groups.
• Evidence of enabled MFA in Yandex Identity Hub or external IdP.
• Register of exceptions including the user, role, resource, justification, and expiration date.
• Re-export after remediation.

Runtime administrative bypass channels are disabled by defaultRuntime administrative bypass channels are disabled by default

Requirement ID: AI-INFRA-CONSOLE1

Scope

This requirement applies to Yandex Compute Cloud VM instances used in the execution, loading, and administration environments, RAG store, agent backend, MCP tools, telemetry, or other AI system components.

Requirement

For AI system VMs, access to the serial console (serial console) must be disabled. The serial console must not be used as the standard method for production VM administration.

Standard administrative access must take place via an approved method, e.g., OS Login over SSH. Access must be personalized, limited to IAM roles, and loggable.

The serial console can be enabled only for emergency response or approved maintenance works. Each time, the following must be specified: VM, reason, responsible party, validity period, and approval. After the works are completed, the serial console must be disabled.

Implementation

For each VM in the AI system, the following are recorded:

• Serial console access option status.
• Approved administrative access method.
• Users or groups with OS Login permissions.
• Source of administrative action logs.

For Linux VMs, we recommend using OS Login with the compute.osLogin or compute.osAdminLogin roles instead of persistent SSH keys on the VM. If OS Login is not used as such, another approved method of personalized and loggable access must be documented.

The OS Login, SSH access, VM service account, and metadata access configuration is checked separately from the serial console configuration. The presence of IAM minimum roles does not mean that the serial console is disabled.

Check

1. For each VM in the AI system, check that serial console access is disabled in the VM settings.
2. If the serial console is on, check that there is a valid exception stating the VM, reason, owner, approval, and duration.
3. After the emergency work are done, confirm that the serial console is off by re-checking the VM configuration.

A VM with enabled serial console and no valid exception in place is considered non-compliant.

Artifact

• Export or screenshot of the VM configuration with serial console access status.
• List of the AI system's VMs.
• Approved administrative access method.
• List of OS Login roles or another access mechanism.
• Request for temporary activation of the serial console, if any.
• Confirmation that it was disabled after the works ended.

Storages and cryptographic protectionStorages and cryptographic protection

Model and data storages have no unaccounted for public accessModel and data storages have no unaccounted for public access

Requirement ID: AI-NET5

Requirement

For each bucket, database, index, disk, and registry, the owner must record an exact ID, read and modification operations, subjects, network path, encryption mode or a link to AI-CRYPT1, and a requirement for public access. By default, model artifacts, training data, RAG documents, and logs must not be publicly accessible. The publication exception must describe a specific object and purpose.

Implementation

For Object Storage, you need to check IAM, the ACLs, and the access policy in line with the service access model.

You should not consider roles assigned to Managed Service for OpenSearch and YDB for the Yandex Cloud resource as application authorization; such authorization is designed separately.

For Vector Store, the AI Studio roles, API key scope, and application authorization are verified; no documented method for disabling the AI Search public network path is specified, and no private endpoint is assigned to the service.

Check

1. Check the effective bindings, ACLs, policies, and network accessibility of each storage.
2. Perform a read operation from an authorized test subject and an unauthorized one.

A negative result must apply to the actual application path, not just the management console. The set includes unauthenticated access and access by a subject belonging to another tenant; if broad access is detected, the exposed credentials are replaced.

Artifact

• Effective bindings.
• ACL.
• Read test from authorized and unauthorized subject.
• Public access and network configuration.

Encryption is chosen based on the capabilities of the specific serviceEncryption is chosen based on the capabilities of the specific service

Requirement ID: AI-CRYPT1

Requirement

Data, model artifacts, indexes, disks, and backups must use an encryption mode documented for the selected service for storage and a secure protocol for transmission. If the organization requires its own Yandex Key Management Service key, it must confirm that the specific resource supports this mode and check permissions for the key, lifecycle, and consequences of blocking or deletion.

Implementation

Object Storage supports documented server encryption modes.

For Compute Cloud disks, images, and snapshots, KMS encryption is selected during creation and is subject to certain limitations described in the Compute Cloud guides.

These properties cannot be automatically applied to AI Search, OpenSearch, YDB, or an external service. It is recommended to maintain a matrix in asset → exact resource → supported mode or KMS key → required subject and role → read test format: for Object Storage, server encryption mode and a custom KMS key if needed; for Compute Cloud, disk, image, or snapshot key and the kms.keys.user permission; for Managed Service for OpenSearch, a custom key under documented preconditions. Yandex Lockbox uses KMS inside the service itself.

For AI Search and Vector store, custom KMS key management is not documented and not declared. Encryption does not replace authorization and anonymization.

Check

1. For every storage, record the encryption mode, relevant key, and subjects with a permission to use the key.
2. Read a permitted object using the regular runtime environment and reject reading for a subject without the required permission for the key or object.

The test with the key inactive must be performed only on an isolated non-production resource. The last usable key is neither disabled nor deleted; the keys are updated according to the recovery plan.

Artifact

• Encryption configuration.
• Permitted read and unauthorized access denial.
• Key ID and bindings.
• Recovery rehearsal.

SecretsSecrets

A secret has an owner and a managed lifecycleA secret has an owner and a managed lifecycle

Requirement ID: AI-SECRET1

Requirement

API keys, external provider tokens, passwords, and other secrets must be stored in a special storage and have an owner, secret and version IDs, purpose, permitted consumers, precise role and scope of access, delivery method, revision date or period, replacement and revocation procedure. Do not store values in source code, build history, image, dataset, system prompt, public configuration variable, log, or check certificate.

Implementation

For supported environments, we recommend delivering a secret from Lockbox to the working service account with the lockbox.payloadViewer role for the specific secret. For a KMS-encrypted secret, a documented permission for the key is additionally required. The method depends on the environment:

• Cloud Functions gets the link to the secret in the function configuration. The integration is at the Preview stage.
• Serverless Containers uses the integration at the Preview stage.
• Managed Service for Kubernetes uses External Secrets Operator.
• In Compute Cloud, the application receives the secret via the API by ID, and the value cannot be placed into an unencrypted user-data.

For DataSphere, the task reads the secret via the API with the service agent token according to a documented instruction. For Kubernetes, instead of External Secrets Operator, you can use a path with a workload identity and application access via the API. Lockbox is not required unconditionally if the policy selects another approved specialized storage; in this case, the exact delivery path is documented.

For each secret, a single delivery branch is selected: value implementation, reading via the API, or Kubernetes Secret materialization.

Check

1. Map each secret and its active version to consumers, delivery method, and permissions.
2. Browse the code, build history, image, deployment parameters, IaC configuration, resource variables, data, and log selection for the value or synthetic marker of the secret.
3. Revoke the test version and make sure access is discontinued with due account for documented environment caching. Then check the replacement without disclosing the value.

Artifact

• Mapping a secret to a consumer.
• Revocation and replacement test.
• IAM and KMS bindings.
• Value retrieval event in Audit Trails.
• Rotation record.

Audit and log contentAudit and log content

Each significant operation has an event source specifiedEach significant operation has an event source specified

Requirement ID: AI-AUDIT1

Requirement

The system owner must list the significant operations involving models, keys, secrets, storages, indexes, MCP Gateway, and runtime, as well as specify the event source for each operation. For RAG, creation, ingestion, update, deletion, and search operations are mapped separately; for Lockbox, secret management and value retrieval are mapped separately. Audit Trails is only used for events published by the relevant service. Operations not covered by the cloud event reference must be logged by the application or the storage itself.

The mapping must follow this structure: operation → service → event level (management, data, application) → specific event → source scope and filter → destination → correlation field. The term all operations must not be used. The application must separately add events for model requests, searches, tool calls, and effects in the target system.

Implementation

When configuring a trail, verify the resource scope, selected services, management and data events, filters, and destination. A single train can have only one destination; for details, see the trail description and event reference. The preset should not be treated as an exhaustive configuration; verify the actual configuration using this Audit Trails guide.

Only events listed in the Audit Trails reference for Lockbox must be used for accessing values and managing secrets. AI Search and MCP only use published AI Studio events; application tracing must be used to cover any missing documented search event. A trail that lacks the required service scope or filter does not provide sufficient evidence of operation auditing.

Check

1. For each significant operation, perform a safe test action and find the associated record.
2. Record the resource, subject, timestamp, event type, and correlation ID, if available.
3. If the cloud event is not documented, provide the application record and evidence of its delivery.
4. Perform a separate coverage test: intentionally omit a service or event filter, and verify that the test reports incomplete coverage rather than met.

The event must appear at the destination within the expected delivery time.

Artifact

• Trail configuration.
• Safe test action and found record.
• Event map.
• Trail specification.
• Missing event test.

Logs do not collect sensitive content without a purposeLogs do not collect sensitive content without a purpose

Requirement ID: AI-AUDIT2

Requirement

The logging schema must remove or transform secrets, personal data, full prompts, responses, documents, and dialog history before sending a record to Yandex Cloud Logging or another destination. Such content can be stored only if backed with a documented purpose, legal basis, retention period, access scope, and deletion method.

A minimum application record contains the request, subject, and resource IDs, model and configuration versions, policy result, invoked tool, and technical outcome. Every system has logging; no N/A result is allowed for this requirement.

Cloud Logging accepts application records. Official guides do not mandate any universal removal of secrets or personal data from any application content, so the schema and record editing remain part of the application. Read and write permissions must comply with the Cloud Logging access model, and the retention period must align with the approved policy and actual retention period configuration.

Check

1. Review a sample of successful, failed, and denied requests.
2. Check that there are no API keys, Lockbox values, or unapproved content.
3. For permitted dialog storage, confirm the purpose, period, access, deletion, and connection with the legal approach under Compliance and processing of personal and regulated data.
4. Additionally, send synthetic markers for secrets and personal data: events must preserve correlation but not the marker values.
5. Also check log reader bindings.

Artifact

• Logging schema.
• Record selection.
• Storage purpose confirmation.
• Test events with synthetic markers.
• Log reader bindings.

Runtime, RAG stores, and decommissioningRuntime, RAG stores, and decommissioning

The runtime environment determines which processes share nodes and a network, where the state is stored, how the application retrieves secrets, and which logs are automatically generated. Managed Service for Kubernetes, Serverless Containers, Cloud Functions, Compute Cloud, DataSphere, and managed APIs have different models. The requirement is considered met only for the environment that is actually in use.

The owner specifies the applicable branch:

• For a managed AI Studio API, no control over the OS or node is claimed; the calling application as well as its identity, inputs/outputs, data, and external state are verified.
• For DataSphere, the boundaries are defined by the community, project, task or node, its service identities, network, and external resources.
• For Managed Service for Kubernetes, the following are checked separately: Identity and Access Management, Kubernetes RBAC, namespaces, pods, nodes, and the network.
• For Serverless Containers and Cloud Functions, the following are factored in: revision or version, respectively, active service account, instance reuse, and external state.
• For Compute Cloud, the organization is responsible for the VM, OS, process, model loader, and telemetry agent.
• For the external model API, a local runtime profile is used, along with a dedicated outbound traffic boundary, external credentials, and a recipient.

Specific roles, configuration objects, and verification methods are listed here.

Runtime isolationRuntime isolation

Independent workloads and tenants are isolatedIndependent workloads and tenants are isolated

Requirement ID: AI-INFRA6

Requirement

If a single environment hosts multiple systems, tenants, or data classes, the owner must isolate their identities, network paths, state, and permissions for computing resources. One tenant’s workload must never be allowed to read memory, files, secrets, logs, or temporary objects of another tenant.

Implementation

In Managed Service for Kubernetes, use separate namespaces and ServiceAccount resources, Kubernetes RBAC, network policy, and pod restrictions. Implement IAM cluster access and Kubernetes RBAC at different layers. For guidelines, refer to this Kubernetes security guide and access management tutorials.

If using dedicated GPU pools, you must separately record node groups, execution and scheduling permissions, quotas, and workload resource limits. Native GPU isolation is not guaranteed: to confirm isolation, you must provide relevant evidence for the selected runtime.

Serverless Containers and Cloud Functions isolate the managed runtime for a published model; however, the application code is still responsible for isolating tenant data and managing state between requests.

In Compute Cloud, the organization is also responsible for the OS, process isolation, and access to VM metadata.

Even with a single tenant, development, testing, and production environments must be isolated. You must explicitly state the unit of isolation: a cluster, node group or namespace, DataSphere project, Function or Container resource, VM, folder, network, or managed service resource with the application rule for the tenant.

Check

1. Create two test subjects or tenants and attempt cross-tenant access to files, secrets, cache, and endpoints.
2. For Kubernetes, additionally check IAM, RoleBinding/ClusterRoleBinding, network policy, and workload allocation.
3. For a serverless environment, check the tenant isolation keys in each external store.

Tests must involve access attempts with a foreign tenant identity, foreign namespace, storage key, and direct endpoint. In case of a failure, the mixed cache or index must be dumped.

Artifact

• Test of cross-tenant access to file, secret, cache, and endpoint.
• Topology and map of resources and tenants.

No state is preserved between independent tasks by defaultNo state is preserved between independent tasks by default

Requirement ID: AI-INFRA-ISOL2

Scope

The requirement applies if the same environment, in sequence or in parallel, serves independent tasks, sessions, users, or tenants, whether the generated code can be executed or not.

Requirement

Temporary files, cache, session memory, and alternative operational state must be created for a specific task or access scope and cleaned up on completion. A long-lived state is allowed only in a named external storage with application-level authorization, life period, and cleanup rules. Reusing a process or instance by the managed service must not result in reusing data of another task.

State inventory covers memory, temporary files, cache, session storage, and volumes of the selected environment. For each one of them, a scope, lifespan, and cleanup procedure are specified. A dialog application may save an explicitly limited state of an authenticated subject’s session. An unrelated state is not inherited.

Serverless Containers and Cloud Functions provide managed instance lifecycle; however, the application must not see the completion of a specific request as a guaranteed destruction of the instance. For Kubernetes and Compute Cloud, the boundary of the process, pods, VMs, or a specific working directory is defined by the architecture. An end of a serverless revision or pod restart is not by itself an evidence of application state cleanup; the task status and DataSphere notebook status are two different things.

Check

1. During the first test session, create a synthetic marker in temporary state, complete the task, and start an independent session.
2. If the state is preserved intentionally, show its owner, authorization, and cleanup time.

The marker must not be accessible through the app, file path, cache, or diagnostic interface. The marker is also checked using the key cache; the previous implementation is returned only after a successful retest with the marker.

Artifact

• Synthetic marker.
• Unavailability after task completion.
• State map with lifespans.
• Cleanup event.

Execution of code, commands, and dynamic queries is restrictedExecution of code, commands, and dynamic queries is restricted

Requirement ID: AI-INFRA-ISOL3

Requirement

If a model or agent can generate code, command, SQL or another executable query, execution must take place in a separate environment with minimum identity, an explicit list of available processes and storages, limited CPUs, memory, and time, controlled file system and network. For permitted outputs, the exact recipients and operations are specified. Unknown output is forbidden.

The state is linked to a specific task or tenant; a timeout or boundary violation forcibly terminates the process, and temporary data gets purged. Production secrets and administrative permissions are not transferred solely for ease of execution.

In absence of such execution paths, the N/A result is permitted only together with inventory of execution points. For SQL, parameterized queries and query policies are used.

Implementation

For Kubernetes, limitations are implemented by pod and container security settings, RBAC, network policy, and resource limits to the extent of the Kubernetes security guide.

For Serverless Containers and Cloud Functions, you should consider the limits and properties of the specific revision or version from the Runtime in Serverless Containers or Cloud Functions profile. Runtime isolation does not replace the model output check by AI-CONTENT2.

In Kubernetes, the load is not started from root, with prohibition on elevation of privileges and host namespaces, and a limit on volumes and outgoing traffic. Yandex Cloud does not provide a universal isolation switch for executable AI code.

Manual check

1. Run a permitted operation with a permitted temporary object.
2. Then run a synthetic command attempting to create a child process outside the list, read a file belonging to another user, write to persistent storage, access a forbidden address or metadata service, exceed the resource limit, and survive a timeout.

None of the attempts must go beyond the approved environment boundaries. After the check, confirm the process completion and test data cleanup.

Artifact

• Permitted operation.
• Boundary tests.
• Process completion.
• List of permitted operations.
• Confirmation of absence of side effects.

RAG authorizationRAG authorization

Document-related permissions are verified before the chunk goes to the modelDocument-related permissions are verified before the chunk goes to the model

Requirement ID: AI-RAG-ACL2

Requirement

If RAG contains documents from various access scopes, the application must form a search query based on verified user identity and permissions and apply document authorization prior to putting the found fragment into the model context. A check only after the response is generated does not fulfill the requirement: the model has already received the hidden content.

The user and tenant access scope must be saved in the agent path. The tenant ID and filter are not received from the query without a binding to checked attributes on the server side.

After the search, the IDs of returned documents are checked again before building the context. The version policy and IDs of returned documents are logged, not the hidden content.

For Managed Service for OpenSearch, cloud roles manage the service resource, but they do not by themselves implement document authorization of the end user. If the architecture uses internal roles and OpenSearch filters, their supported semantics and negative tests are recorded separately. The capabilities of Yandex Cloud roles are described in this Managed Service for OpenSearch guide.

For YDB, roles for the database are not a ready row-based authorization either; client authentication is described in this YDB guide.

For another storage, the owner must document an access model of their own.

Implementation

AI Search implements Vector Store metadata and supports filtering by file attributes in the search API; however, this is not a ready-to-go document authorization.

If the required access scope cannot be reliably expressed and protected with a filter, the service uses either separate Vector Store instances or application-based authorization before the fragment is included into the context. The filter becomes a part of the control circuit only when the app forms it from confirmed permissions and rejects substitution. For more, see the articles on Vector Store and search parameters.

Check

1. Create documents of at least two access scopes.
2. Run a permitted search from each subject to their own documents and attempt to receive another user’s document or row.
3. Check not only the output, but also the actual context of the model query.

The requirement is fulfilled if authorization applies before the model is called, and the hidden document or row are not present in the search results and in the actual context of the unauthorized subject’s query. Substitution of the tenant or metadata filter must be rejected. The evidence is the manifest of the model query’s actual context that confirms the absence of hidden content.

Artifact

• Permitted search.
• Attempt to get another user's document.
• Model context.
• Policy version.
• Actual request context manifest.

DecommissioningDecommissioning

Component is decommissioned fullyComponent is decommissioned fully

Requirement ID: AI-DECOM1

Requirement

Before decommissioning a model, index, agent, or application, the owner must register a versioned inventory of all active and reserved objects: data, models, indexes, logs, keys, secrets, identities, role bindings, endpoints, routes, disks, backups, and external integrations.

For each object, select one of the following: deletion, transfer, retention for an approved period, or a deletion-prohibition mode based on legal grounds. Procedure readiness is required for each production component; the N/A result is acceptable as evidence of actual execution, but not for verifying readiness.

Implementation

First, new calls and access to the component are halted: its keys and bindings are revoked, the dedicated endpoint is closed, or the route for the component being decommissioned is removed from the shared gateway. The shared identity or gateway is not deleted entirely if it serves other systems; instead, the capabilities and permissions associated with the component are deleted in this case. CIEM is entirely at the Preview stage: if availability is confirmed, it can be used to verify assignments and revoke access within published roles and group restrictions.

Next, active objects are deleted, and lifecycle termination for backups and versions is configured. Immediate deletion may not be possible due to an object lock, established retention periods, backups, or specific KMS features. Any legal prohibition on deletion takes precedence.

Before destructive operations, the configuration is exported, as it may not be possible to roll back the deletion.

Check

1. Try to invoke the component using the same method, use the revoked key, and read the active object.
2. Match the result with the inventory and change events.

The completion report must include the inventory version, evidence for each object, unresolved dependencies, the owner of the preserved data, the next action date, and the approving authority. The system is deleted from the registry of active systems only after mandatory items have been checked off; pending deletion remains a recorded obligation. After execution, the inventory process is repeated and must not reveal any unaccounted for objects; the saved record is only accessible to the specified owner.

Artifact

• Inventory version.
• Completion report.
• Call test using the same method.
• Pre- and post-inventory.
• Result of search for residual objects.

Monitoring and incident responseMonitoring and incident response

AI system observability consists of three layers: cloud-level management events and individual operations, runtime environment operational metrics, and application-level tracing of model or agent requests. Their connections and investigation signals are verified against AI-MON-ANOMALY2 and AI-MON-TRACE1.

Signals and alertsSignals and alerts

Atypical use of APIs and resources is detectedAtypical use of APIs and resources is detected

Requirement ID: AI-MON-ANOMALY2

Requirement

The organization must define observable signs of abuse for its scenario: spikes in model or tool calls, unusual spending, repeated policy denials, changes in outbound traffic volume, resource exhaustion, atypical GPU activity, or sudden changes in errors and latency. For each signal, the following are defined: source, observation window, channel, and expected action.

For the agent layer, these are additionally monitored: data extraction and tool decisions, MCP sessions, and tool runtime.

For each rule, the following are recorded: exact metric or event, resource labels, query and threshold, purpose, and owner.

Implementation

Yandex Monitoring allows you to build queries and alerts based on available metrics; an alert evaluates the condition and sends a notification but does not stop the payload by itself. Yandex Cloud Billing budgets can supplement cost control but do not show the number and nature of model calls.

Yandex Cloud Detection and Response is at the Preview stage; you can access the section in Security Deck after your request for access is approved. You can use the service as an additional source provided there is access, a separate collector is deployed for the cloud, and the required signal is actually coming in via the documented TLS path. For conditions and architecture, see this YCDR guide.

The ycdr.admin family of service roles is the only documented one for YCDR; it is not assigned broader than required.

Check

For each rule, generate a safe test signal and confirm the alert trigger, delivery to the correct channel, and logging of the responsible party's action. Threshold values and frequency are approved by the organization; the standard does not set any universal numbers. The alert must reach the owner together with the resource and correlation IDs. A separate negative test confirms that a missing or disabled alert route is detected.

Artifact

• Alert configuration.
• Delivery test.
• Logging of the responsible party's action.
• Dashboard and alert IDs.
• Event timeline.
• Response ticket.

End-to-end application traceEnd-to-end application trace

Model and agent request is traced without excess contentModel and agent request is traced without excess content

Requirement ID: AI-MON-TRACE1

Requirement

The application must assign a correlation ID to the request. A general record contains a timestamp, a subject's verified identity or anonymized ID, a calling component's operational identity, a target resource or endpoint, model and configuration versions, RAG source IDs, input and output policy results, a technical outcome, an error code, and a duration.

For the agent, the following are additionally recorded: step, selected tool, authorization check, request for human confirmation, and backend result.

Platform request IDs are mapped to the application ID in the correlation card and are not considered identical to it.

Full prompts, responses, dialogs, and the model's hidden reasoning do not constitute a mandatory minimum and should not be collected solely for the sake of compliance. If the cloud service does not publish the required data-level event, the application must generate a record itself. Cloud Functions and Serverless Containers transmit request logs and stdout/stderr to Cloud Logging within the documented model: Cloud Functions logs, Serverless Containers logs.

Check

Run a request that includes RAG and a test tool call, and reconstruct the path from input to result. The trace must show policy decisions and technical outcomes, but must not contain secrets or unapproved data. Individual negative test: a missing or incorrectly matched ID causes the coverage check to fail.

Artifact

• End-to-end trace from input to result.
• No secrets.
• Mapping of platform and application IDs.

Each agent loop iteration is linked to a task and an actionEach agent loop iteration is linked to a task and an action

Requirement ID: AI-MON-TRACE2

Scope

This requirement applies if the system runs a multi-step agent loop.

Requirement

For each iteration, the system must save the task and session IDs, step number, selected tool, parameters provided after editing, permission check, result or error code, and the decision to continue, stop, or request confirmation. If the orchestrator creates a plan or subgoal, the system must record their IDs and versions. The standard does not require storing the model’s hidden reasoning.

If using MCP, the mcp_call, mcp_approval_request and mcp_approval_response Responses items must be linked to the mcp_hub.StartMcpSession, mcp_hub.ListMcpTools and mcp_hub.InvokeMcpTool Audit Trails events and to the corresponding target system event. None of these records independently prove a side effect in the target system, and the Audit Trails reference contains no dedicated confirmation event.

If metrics are available, you can also record the time and resource usage for a step. Such a record must be linked to AI-MON-TRACE1 but must not contain secrets, full regulated data, or unapproved content.

Check

1. Run a multi-step workflow that includes one successful and one rejected tool call.
2. Use the unified task ID to restore the sequence of actions, current plan version, if any, authorization decision, error, and the stop condition.

You fail the compliance check if there is no iteration or the effect is not confirmed in the target system.

Artifact

• Trace of a multi-step workflow with a successful and rejected call.
• Task state machine version.
• Confirmation record.
• Target system event.

Preservation of investigation materialsPreservation of investigation materials

Dialog content archive has approved scope and controlled accessDialog content archive has approved scope and controlled access

Requirement ID: AI-FORENSIC2

Scope

This requirement applies if the full or partial contents of a dialog is retained for investigation, quality assurance, support, or another approved purpose. If only minimal forensic events without the contents are preserved, the N/A result for the raw contents branch is acceptable with reference to the decision.

Requirement

A decision regarding storage must specify the composition of messages and context changes, purpose, legal basis, retention period, storage location, owner, and readers. The archive is separated from standard application logs, encrypted using the mechanisms of the selected storage, and is not used as a mandatory source in cases where metadata from AI-MON-TRACE1 is sufficient.

Reading and export of the archive must be logged by the service or application within the scope of available telemetry.

By default, the archive contains IDs, versions, and resolutions rather than the actual contents; no global collection of dialogs for potential future incidents is enabled. The archive is isolated by case, while readers of production journals and investigators are separated.

Check

1. Match one saved session with the approved composition and timeframe.
2. Perform permitted and prohibited read operations, verify the read event or application record, and delete the test session upon expiration.

If the platform does not publish a read event, this blind spot and the compensating record must be explicitly specified. An investigator handling a different case must not gain access to the subject matter of the case under investigation.

Artifact

• Saved session.
• Test of permitted and prohibited reading.
• Case scope.
• Result of deletion or deletion prohibition.

Investigation materials are protected from tamperingInvestigation materials are protected from tampering

Requirement ID: AI-FORENSIC3

Requirement

Logs and exports used in forensic investigation must be kept separately from the reviewed system's active administrators. Write, read, and delete permissions must be separated; the time, source, and integrity of the record must be verified. The retention period must be as per the approved policy and legal requirements.

Implementation

For a secure Audit Trails destination, you can use audit log based recommendations.

In Object Storage, versioning and Object Lock can support immutability if configured correctly, but indefinite lock hold and retention period require separate management.

Write and read identities are separated; the hash manifest and export refer to the exact object version. Object Lock gets enabled only after storage is approved: data protected by it may become undeletable.

Check

Select a saved incident, verify the chain from the original record to the archive, effective permissions, and the ability to detect modification. The application's active administrator must not single-handedly modify or delete the only copy. An allowed attempt to modify or delete a protected synthetic object must behave as per the lock mode; the restored version is verified by hash.

Artifact

• Log permissions.
• Only copy modification test.
• Bucket, policy, ACL, versioning, lock, and encryption configuration.
• Object version and hash.

Response procedureResponse procedure

To execute AI-MON-ANOMALY2 and AI-FORENSIC3, follow this procedure:

1. Install affected modules, data, identities, tools, and receivers.
2. Limit the consequences: stop the dangerous route or tool, revoke the key, narrow down the binding, or switch the endpoint to safe mode.
3. Save the minimum required investigation materials.
4. Eliminate the cause in the data, policy, configuration, code, or accesses.
5. Repeat the original or associated negative check.
6. Return the service only after a documented solution is reached.

Perform the actions with the risk of data loss and possible rollback in mind. Incident isolation must not destroy the only investigation materials without any checks.

Agents, tools, MCP, and agent RAGAgents, tools, MCP, and agent RAG

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 autonomyCapabilities and autonomy

Agent capabilities and external consequences are enumeratedAgent capabilities and external consequences are enumerated

Requirement ID: AI-AGENT1

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.

Manual check

1. Map the capability registry to the configurations of the agent, MCP Gateway, backend, and target permissions.
2. 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.

Artifact

• Capability registry.
• Mapping to configuration.
• Registry version.
• Test events.

Autonomous execution has limits and stop conditionsAutonomous execution has limits and stop conditions

Requirement ID: AI-AGENT2

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.

Implementation

The limit values depend on the risk and cost of the scenario and must be approved by the owner. Monitoring alerts and Yandex Cloud Billing budgets may detect some of the consequences, but alerting is not a substitute for limits and stop controls enforced within the orchestrator or runtime.

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.

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 sourcesAgent's goal and authority originate only from trusted sources

Requirement ID: AI-AGENT-GOAL1

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.

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.

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 confirmationTool identity and human confirmation

Each tool uses a separate account with minimal privilegesEach tool uses a separate account with minimal privileges

Requirement ID: AI-IAM-LEASTPRIV3

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.

Check

1. For each tool, map the backend, service account, roles, and target resources.
2. 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.

Artifact

• Backend, service account, and role mapping.
• Spoofing test.
• Tool matrix.
• Secret IDs.

Session authority is defined by a trusted delegationSession authority is defined by a trusted delegation

Requirement ID: AI-IAM-COMPROMISE1

Scope

This requirement applies when an agent acts on behalf of a user, tenant, or other session with different permissions.

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.

Check

1. Perform an allowed action in your session, then attempt to spoof the user, tenant, resource, and action.
2. 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.

Artifact

• User/tenant spoofing and session revocation test.
• Delegation record.
• Token metadata (excluding secrets).
• Revocation event.

Actions with significant consequences are confirmed by a humanActions with significant consequences are confirmed by a human

Requirement ID: AI-AGENT-HITL1

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.

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.

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.

Artifact

• Unconfirmed action test.
• Post-confirmation parameter change.
• Confirmation ID and hash.
• Target system event.

MCP Gateway and target serviceMCP Gateway and target service

MCP Gateway and target service access is separatedMCP Gateway and target service access is separated

Requirement ID: AI-MCP1

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: 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.

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 and API key guide.

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.

Learn about HTTP tool parameters and how to link a service account in the MCP Gateway creation guide. 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.

Check

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. Check the configuration, network, service account, bindings, schema, and authentication parameters.
2. 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.

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 RAGInter-agent messages and agent RAG

The other agent's message is checked as untrustedThe other agent's message is checked as untrusted

Requirement ID: AI-APP-INJECT2

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.

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.

Artifact

• Tests involving incorrect schemas, expired validity, duplicates, sender spoofing.
• Sender identity and binding.
• Schema and policy versions.

Supply chainSupply chain

Software dependencies, container images, model artifacts, datasets, prompts, agent configurations, and external services are verified separately under AI-SUPPLY1 to AI-SUPPLY6 and AI-DATA-CHECK1. Verifying one category does not confirm the security of another.

Third-party datasetsThird-party datasets

Third-party dataset provenance and integrity are verifiedThird-party dataset provenance and integrity are verified

Requirement ID: AI-SUPPLY1

Scope

This requirement applies to a dataset or RAG corpus from an external author, provider, or public source.

Requirement

The source, author, or provider, date of receipt, version, terms of use, and checksum of the received object must be recorded before use. If the author publishes a signature or checksum through an independent trusted channel, it must be verified before unpacking and transformation. If independent verification is unavailable, a self-generated checksum must not be used as a substitute; source risk and the decision to accept the object must be recorded separately.

The provider record additionally contains contact details and the exact version of the accepted internal object; an isolated identity is used for downloading and importing through the preparation path. The production system only uses the accepted internal copy, not an externally hosted mutable URL.

Implementation

The received object first goes to an acceptance area that is inaccessible to production training and search. After verification, the object's immutable ID gets associated with the AI-DATA1 record.

Check

Retrieve or select the saved source object again, calculate its checksum, and compare it with the acceptance record and, if available, the author's publication. A modified object or an object without the required approval must not proceed to the next stage. A checksum mismatch sends the batch to quarantine; if the check fails, derived objects, such as the index or model, are isolated as well.

Artifact

• Acceptance record.
• Repeated retrieval and checksum comparison.
• Source and internal hashes.
• Quarantine test.

Third-party dataset content goes through an intake checkThird-party dataset content goes through an intake check

Requirement ID: AI-DATA-CHECK1

Scope

The requirement applies to any external, custom, or otherwise untrusted dataset prior to training, fine-tuning, evaluation, or publication in a RAG system.

Requirement

For a specific data type, the owner must define automated and manual checks: expected size and number of objects, field formats and types, mandatory metadata, sensitive data categories, structural anomalies, duplicates and outliers, source consistency, control and hidden characters, unexpected executable objects, and signs of injected instructions. The verification result is linked to the precise ID or checksum of the input version and the versions of the applied validators.

For a multi-modal set, hidden content is additionally checked if the selected analyzer is capable of detecting it; lack of this capability is flagged as a blind spot rather than a successful check.

Implementation

An object containing a parsing error, an unknown type, or a prohibited field, or exceeding an approved threshold, is not automatically published. It is rejected or quarantined, with the reason, owner, and manual review decision recorded. The statistical anomaly threshold and manual sampling amount are defined by a specific scenario's policy. DSPM can scan supported storage but does not transform data or prove its absence; guardrails do not scan the corpus outside the request flow.

Check

1. Submit a valid set and a synthetic set containing an incorrect amount, missing metadata, an incompatible type, sensitive field, control or hidden character, and a corrupted object.
2. Verify the link between the report and the specific input version, automated resolution, reason entry, quarantine status, and manual resolution where applicable.

No rejected item should appear in the published version. Lack of the rejected object is also confirmed in the index; in the event of a failure, the derived indexes are rebuilt.

Artifact

• Test error set.
• Link between the report and the input version.
• Validator versions.
• Confirmation of the object's absence from the index.

Third-party modelsThird-party models

Third-party model format, loader, and behavior are checked prior to admissionThird-party model format, loader, and behavior are checked prior to admission

Requirement ID: AI-SUPPLY2

Scope

The requirement applies to the model, weights, tokenizer, or ingestion code received outside the approved internal pipeline.

Requirement

The model package must be associated with the source you are checking and the checksums. For access to the production network, secrets, and data, the serialization format, accompanying code, custom loader, and dependencies are checked. The first run is made in an isolated environment using AI-MODEL2. It is preferred to use a format that does not require you to run random code during the ingestion; however, the format name alone does not guarantee security.

Implementation

Static file check and dynamic execution answer different questions. The scope of behavioral tests, test inputs, and admissibility criteria are defined by the risk owner. The standard does not imply that the cloud scanner is able to analyze weights or hidden behavior.

Check

Map the package against the source and checksums, repeat the ingestion in an isolated environment, and monitor the file, process, and network actions. A mismatch, unexpected execution, or external write attempt will block admission until a separate decision is made. After the check, the initial ingestion environment gets deleted.

Artifact

• Package with the source.
• Action monitoring during ingestion.
• Configuration of the initial check environment.

Third-party model goes through a formal acceptance procedureThird-party model goes through a formal acceptance procedure

Requirement ID: AI-SUPPLY3

Scope

This requirement applies prior to the initial production deployment of any third-party model package and after its major modification.

Requirement

The procedure must include a request explaining how you plan to use the model, a check on the source and license terms, integrity check, format and loader analysis, isolated run, results of approved behavioral tests, admission decision, and and a record of the exact version number. The requesting party cannot approve their own package if the organization policy mandates an independent review. The approval is bound to the exact hash of the acceptance package; the deployment control must only accept approved model packages.

Implementation

The acceptance record must be linked to AI-MODEL1, while the production release, to AI-REL1. Reusing a previous approval decision for a different version is not allowed.

Manual check

1. Select a running third-party model and restore the associated request, approved package, results, decision, and registry entry.
2. Replace the test checksum or version: the old decision must reject the new package.

A missing or outdated acceptance package must also be rejected.

Artifact

• Acceptance record.
• Checksum spoofing test.
• Acceptance package and its hash.
• Confirmation or exclusion.

Software component vulnerabilitiesSoftware component vulnerabilities

Dependency and container image vulnerabilities are managedDependency and container image vulnerabilities are managed

Requirement ID: AI-SUPPLY4

Requirement

The organization must maintain a registry of software dependencies and images, obtain vulnerability information, determine the remediation timeframe with respect to the risk, and must not release a component that violates the approved criterion. An exception must name the specific version and the compensating measure. Scanning covers the dependencies of the application and the model loader; the finds are linked to the release manifest. If there is no container, an N/A result is acceptable for the image branch, but the dependency branch remains applicable.

Implementation

Container Registry can scan Docker images manually, on upload, or on a schedule; the scope and results are described in the scanner docs and the scanning guide. The scanner does not analyze model weights, model behavior, the RAG corpus, or the external service.

Check

1. Compare the production image digest and dependency versions against latest scan results.
2. Check test find processing and the impossibility to release a version that violates the approved criterion.

You can roll back to a previously accepted digest only after its vulnerabilities are checked.

Artifact

• Image digest.
• Latest scan results.
• Release test.
• Dependency report.
• Redeployment event.

Reproducible release compositionReproducible release composition

The composition of software and AI components of the release is knownThe composition of software and AI components of the release is known

Requirement ID: AI-SUPPLY5

Requirement

For each release, a reproducible list must be preserved that covers its software dependencies, images, model, adapters and tokenizer, configuration, prompts, applied guardrails and model instance, tools and MCPs, external provider, and data sources or index.

For the software component, we recommend to generate an SBOM in a standard machine-readable format. A separate manifest may be required for the model and data, as a software SBOM does not describe their meaning and provenance.

If the pipeline generates an SBOM, signature, or attestation, a reference to it is provided, but this is not referred to as native Yandex Cloud control.

Implementation

Documented Container Registry functions include storage and distribution of Docker images and vulnerability scanning. These results in themselves do not constitute a complete SBOM or release attestation. The organization selects a specific tool for generation and verification and links the result to the release digest.

Check

Reconstruct the contents of the working version from the saved manifest and compare the checksums against the actual objects. An unspecified component or a floating version means that the release is non-reproducible. The check must detect an intentionally omitted or altered component.

Artifact

• Saved manifest.
• Comparison with actual objects.
• Manifest hash.
• Component cards.

Supplier risk changeSupplier risk change

Change to a component or external service triggers re-assessmentChange to a component or external service triggers re-assessment

Requirement ID: AI-SUPPLY6

Requirement

The owner must identify official channels and public sources for provider security notifications. They must monitor and act on alerts regarding compromises, critical vulnerabilities, revocations, terms-of-service updates, or unavailability of a model, data, library, image, or external API. This procedure must enable you to pinpoint affected releases, restrict usage, replace a component, and repeat relevant checks.

Implementation

For an external service, updates to the API, model, processing region, retention terms, and telemetry must be tracked. Yandex Cloud does not manage permissions and lifecycles for external providers unless a specific integration is explicitly documented. Security Deck and YCDR only process incoming signals within a configured environment and do not replace provider monitoring.

Manual check

Take a test notification about a revoked version and trace the response: search of affected systems, restriction decision, replacement, and repeating the check. The registry must allow you to do this by the exact version, not just the product name. Simulating an update to a version, notification, or endpoint should trigger a new check and prevent silent production drift. The system must never run an unknown version without notice.

Artifact

• Test notification.
• Search for systems.
• Restriction decision.
• Affected release manifests.
• Ticket.

Yandex Cloud implementation profilesYandex Cloud implementation profiles

This profile links requirements to a specific request path and Yandex Cloud objects. Profiles do not introduce new requirements; they present resources, settings, and evidence for the requirements from these sections:

• Secure architecture and development of AI applications
• Data, training, models, and releases
• IAM, network, encryption, secrets, and audit
• Runtime, RAG stores, and decommissioning
• Monitoring and incident response
• Agents, tools, MCP, and agent RAG
• Supply chain
• Compliance and processing of personal and regulated data

Multiple profiles can be used simultaneously within a single system: for example, an application in Managed Service for Kubernetes invokes AI Studio, employes AI Search, and accesses tools via the MCP Gateway. A reviewer consolidates profiles based on the actual architecture without transferring properties from one service to another.

The following table links each requirement to applicable Yandex Cloud profiles and specifies exactly what to verify and which artifact to use to confirm the result. For requirements not linked to a specific service, a general verification principle is stated; lack of a profile does not negate the requirement itself.

The profile numbers in the table are examples of implementation, not a limitation on applicability. The applicability of a requirement is determined by architectural conditions: controls for regulated data apply to any profile handling such data; image checks apply to all container runtime environments; and public perimeter protection applies to any profile with a public HTTP(S) access.

Managed inference via AI StudioManaged inference via AI Studio

Scope and status

This profile is applied to the managed AI Studio API. In the architecture, a specific capability is identified, such as text generation, Responses, Realtime, or another documented API operation. Guardrails and IAM access policies only count for actual usage. Guardrails are at the Preview stage and require a separate availability check.

Flow and trust boundaries

user → application or runtime environment → AI Studio API → model → application. The input and response cross the application validation boundary; files, responses, and guardrails form separate branches.

Workload identity and authentication

The runtime environment uses a separate service account and an IAM token or API key documented for the selected API. Managing the MCP Hub requires an IAM token rather than an API key. The methods and headers are listed in the authentication guides.

Roles and scope

For text generation, ai.languageModels.user is checked; for Responses, ai.assistants.editor together with ai.languageModels.user; for Realtime, ai.models.user. Assignments are checked at the supported organization, cloud, or catalog level. The role from one API does not transfer to another; role semantics are derived from the AI Studio access model.

Network

The actual managed endpoint and runtime source path are recorded. If the IAM access policy is used for Responses, the aistudio.responses.restrictNetworkAccess, allowed_src_ips, allowed_vpc_network_ids pattern and the allowed and denied sources are checked. This policy restricts a previously granted permission and does not create a private endpoint.

Secrets and credentials

For an API key, the following are recorded: ID, owner service account, scopes, expiration or review date, and delivery path from the runtime environment profile. The key value is not included in the configuration record. For an IAM token, the workload identity and acquisition method are logged.

Configuration objects

Catalog ID, model and API capability, service account, bindings, API key ID and scopes, application configuration version; where applicable, guardrail ID and version and IAM access policy.

Telemetry and blind spots

Only published Audit Trails events for AI Studio are used. They do not guarantee a full prompt, response, or end-to-end application correlation; the missing trace is generated by the application. Export and analysis are configured in line with the official guide.

Positive and negative checks

1. Make an authorized invocation. Check the following: rejection due to a missing role, rejection due to a revoked or unsuitable key, and correlation with the application record.
2. For the IAM access policy, check the allowed and denied network sources.
3. For guardrails, check the allowed category, blocking, and moderator error.

What you need for profile implementation

• Architecture: API, model, runtime environment, and data branches.
• Policy: IAM token or API key, key expiration, network restrictions, and log rules and composition.
• Legal approach: permissible data categories, target, recipients, and retention period.

AI Search-powered RAGAI Search-powered RAG

Scope and status

The profile is applied if the RAG uses files and AI Studio Vector Store. Web Search is recorded by a separate external branch; AI Search properties are not transferred to a random vector store.

Flow and trust boundaries

approved source → loader → file → Vector Store → application search → allowed fragments → model context. The admissibility boundary is before the file publishing; and the document authorization boundary is before the model fragment transfer.

Workload identity and authentication

Ingestion and search identities are separated if keeping them together is not justified. Each one uses an IAM token or API key as per the requirements of the specific API and runtime environment profile.

Roles and scope

ai.assistants.editor manages files and Vector Store; ai.assistants.viewer allows reading them and performing search. For subsequent text generation, ai.languageModels.user is used; for Responses, ai.assistants.editor together with ai.languageModels.user. A single operation example and its API key scope is not a universal combination; relevant semantics are taken from the AI Studio access model.

Network

The managed AI Studio endpoint is used; a loader with VPC does not create a separate Vector Store network boundary. For Web Search, the permitted domains and external boundary are recorded. No undocumented private endpoint is declared.

Secrets and credentials

Loader and search environment credentials are delivered by their runtime environment profiles. The corpus card stores the ID and scopes of the key, but not the value. The data source secret is separated from search credentials.

Configuration objects

Source and version, file identifiers and Vector Store, grouping and tokenization settings, file attributes, ingestion and search identities, lifecycle state, and relation to a release. For a description of the features and metadata, see Vector Store.

Telemetry and blind spots

AI Studio event catalog publishes searchindex.CreateSearchIndex, searchindex.UploadFilesToSearchIndex, searchindex.DeleteFilesFromSearchIndex, and searchindex.DeleteSearchIndex. No separate index change event or event of every search query are declared in this list; the application writes end user permissions and search tracing with source IDs and an authorization decision.

Positive and negative checks

1. Upload a permitted object. Test rejection of a non-permitted source and refusal to write to another user’s Vector Store.
2. Perform search on behalf of two subjects, substitute the filter attribute, and confirm the absence of the hidden fragment in the model context.
3. Delete the test file and make sure the output stops.

What you need for profile implementation

• Architecture: corpus, ingestion and search identities, and document access model.
• Policy: rules of acceptance, grouping, reindexing, and lifespan.
• Legal approach: admissibility of sources, data categories, and Web Search. Authorization via a filter is used only after its exact application semantics is confirmed; otherwise, separate Vector Store instances or authorization before search are used.

Own storage-powered RAGOwn storage-powered RAG

The Managed Service for OpenSearch and YDB properties differ; therefore, they form two profiles. For another product, the owner creates a dedicated profile using the same ten fields; the generic entry named other storage does not constitute evidence.

Managed Service for OpenSearchManaged Service for OpenSearch

Scope and status

This profile applies if Managed Service for OpenSearch is the RAG knowledge store.

Flow and trust boundaries

source → ingestion environment → cluster and index; separately, search environment → OpenSearch endpoint → result → model. The application authorizes access to the document before returning a retrieved chunk.

Workload identity and authentication

Identity and Access Management manages the service's resource and the data environment connection uses an internal OpenSearch user and their password. An IAM binding by itself does not authenticate the search query. The user, password, and internal role mappings are verified separately as per the user management guide.

Roles and scope

managed-opensearch.user is used to work with the cluster; managed-opensearch.auditor and managed-opensearch.viewer allow reading the available configuration; managed-opensearch.editor enables updating the resource; and managed-opensearch.admin additionally manages access.

If you opt for a customer KMS key when creating or restoring the cluster, the subject performing the operation should also be assigned the kms.keys.user role or higher for that specific key according to this storage guide. The exact operation is checked against the access model.

These roles do not replace the internal permissions of the index or end user authorization.

Network

The following are recorded: VPC, subnets, host groups, security groups, FQDNs, and public access flag. The connection uses TLS as per this guide; 0.0.0.0/0 shown in this example is not an approved access rule.

Secrets and credentials

The internal user's password is stored in Lockbox or another approved storage system and delivered through the runtime profile. The certificate specifies the secret ID and version, user, and consumer, but not the secret value.

Configuration objects

Cluster ID, host groups and node roles, network and security groups, public access flag, FQDNs, internal users and role mappings, indexes, aliases and filtering rules, and, optionally, the KMS key as required by the relevant documented storage encryption mode (if selected).

Telemetry and blind spots

Only events from the Audit Trails reference for OpenSearch are used. They can show operations and privilege errors but do not prove that the application ACL is correct or that the end user context is complete.

Positive and negative checks

1. Run an allowed search and a search for another user's document.
2. Send a direct request that bypasses the application, attempt to log in with an invalid internal user account, and connect from a denied network.
3. Correlate the application request ID with the relevant service event.

What you need for profile implementation

• Architecture: indexes, ingestion and search environments, and the document ACL location.
• Policy: public access, internal roles, KMS, and log retention periods.
• Legal approach: document categories and authorized recipients.

YDBYDB

Scope and status

The profile is applied if YDB is used as a storage for documents, metadata, or RAG search results.

Flow and trust boundaries

runtime → database endpoint and path → tables and indexes → rows → model context. User authorization for a document or row remains an application-level boundary.

Workload identity and authentication

A YDB SDK or CLI client uses an IAM token or a documented credential provider, which gets IAM tokens from an authorized access key or runtime metadata service. The choice of library and provider is recorded according to the YDB connection guide.

For direct access to the management API, only the IAM token is provided in the Bearer scheme according to the API authentication reference; the authorized access key is not declared as direct Bearer credentials.

Roles and scope

ydb.auditor is used for connection and metadata within the docs; ydb.viewer, for reading; ydb.editor, for reading, writing, and schema changes; and ydb.admin, for access management. Roles are assigned for a specific database when the assignment supports the required operation. They are not a ready-made list of access controls applied at the row or document level. For more information, see the description of the YDB access model.

Network

The serverless or dedicated mode, endpoint, database path, and actual network path are recorded. For a dedicated database, the official connection guide requires incoming and outgoing TCP traffic on port 2135; the source and destination of the rule are limited to the actual application environment, not the 0.0.0.0/0 example. The serverless database uses the grpcs endpoint and path issued by the service; the security group setup of the dedicated database is not transferred to it.

Secrets and credentials

With an IAM token from the metadata service, there is no long-lived secret, which is marked as N/A with an indication of the workload identity. The authorized access key file for the SDK or CLI is stored and delivered according to AI-SECRET1; the IAM token obtained through it does not replace key accounting.

Configuration objects

Database ID and mode, endpoint and database path, IAM federated credentials, tables, indexes, schema, authentication method, security groups for the dedicated database, tenant application schema, and document-level access control lists.

Telemetry and blind spots

The YDB Audit Trails reference describes management events. It does not log reads and edits of each row; these operations and the application ACL decision are logged by the application or an approved query layer.

Positive and negative checks

1. Run an allowed read and a query to a foreign tenant or row.
2. Run a direct query bypassing the search API and a call with revoked credentials.
3. Separately show the management event and the application trace of the data plane query.

What you need for profile implementation

• Architecture: database mode, schema, indexes, and ACL.
• Policy: authentication method, query rules, and log period.
• Legal approach: data categories. KMS configuration is not declared without an official confirmation for the selected YDB configuration.

Agent with MCP Gateway and toolsAgent with MCP Gateway and tools

Scope and status

The profile is applied only if the agent calls MCP Gateway or is managed via MCP Hub. Gateway publicity, access to external or templateMCP server, and action confirmation are independent properties.

Flow and trust boundaries

user → application → agent → MCP Gateway → tool HTTP backend → target resource. Gateway input, Gateway service account, backend authorization, and permissions for the target resources are checked separately.

Workload identity and authentication

The calling and managing identities, the Gateway service account and backend credentials, are separate. For MCP Hub management, an IAM token is used. The calling environment gets the IAM token of its service account; the API key with the yc.serverless.mcpGateways.invoke scope is used only in the documented call scenario and delivered through that environment's profile.

Roles and scope

serverless.mcpGateways.invoker allows the call, serverless.mcpGateways.editor allows the Gateway update, serverless.mcpGateways.admin is for binding management.

The additional serverless.mcpGateways.anonymousInvoker role is assigned for documented external MCP servers and template-based servers. This assignment does not replace and prove configured Gateway publicity.

The subject creating the Gateway gets the serverless.mcpGateways.editor and iam.serviceAccounts.user roles for the folder as per the creation guide. The second one allows service account binding and is not a working Gateway role.

The semantics of other roles are taken from the AI Studio access model and the MCP Hub overview, not derived from names.

Network

public, IAM bindings, VPC cloud networks (when used), and backend reachability are recorded. public=true stands for unauthenticated access for agents. The serverless.mcpGateways.anonymousInvoker role relates to a documented branch of external and template servers and is not an equivalent of the flag above. None of the branches is an evidence of target service authorization.

Secrets and credentials

With useServiceAccount, Gateway uses the linked service account, so the long-lived backend secret is marked as N/A. The account’s permissions for the target resource are checked separately.

If the backend requires a bearer token or credentials in a user header, a supported mechanism for storage, transfer to Gateway, and rotation must be named prior to admission. The current link for creating Gateway does not confirm the native link to Lockbox, so putting the value into the configuration without proper justification is not a permissible path.

Headers allowed for forwarding are provided as an explicit list. Secret values are not included into the tool schema or evidence.

Configuration objects

Gateway, folder and service account IDs, public, cloud network, log group and logging level, list of tools, URL and method, inputJsonSchema version, body, headers, request parameters, authorization and header forwarding mode. Supported fields are checked against the Gateway creation guide.

Parameter size limits and action approval by a human are implemented by the application or agent orchestrator using AI-AGENT-HITL1 and are not documented MCP Gateway configuration fields.

Telemetry and blind spots

Cloud Logging is enabled by the Gateway configuration. AI Studio events, including mcp_hub.InvokeMcpTool, do not prove full backend authorization, effect at the target resource, or response content. These parts are associated by the application-level trace and the target service log.

Positive and negative checks

The syntax of diagnostic commands is taken from the MCP Gateway CLI reference.

1. Run list, get, list-access-bindings, list-operations.
2. Check the private Gateway call with an IAM token or API key and failure without invoker.
3. Check access to the selected external or template server with required additional role and failure without it.
4. For public=true, check an unauthenticated call and its rejection after disabling publicity.
5. Additionally, check a managing operation from the production environment, exceeded size or schema limit, direct bypass of backend, action requiring confirmation, and cycle stop.

What you need for profile implementation

• Architecture: tools, backends, target resources, and delegation scheme.
• Policy: public/anonymous, approval, headers, sizes, and cycle limits.
• Legal approach: external backends and transmitted data categories.

Training and experiments in DataSphereTraining and experiments in DataSphere

Scope and status

This profile is applied to notebooks, tasks, nodes, and published DataSphere resources. The managed environment does not replace data provenance tracking, model acceptance, and release decision.

Flow and trust boundaries

user or CI → community and project → notebook/task/node → storages and external services → model artifact → release. Project membership, task workload identity, and access to an external resource are different boundaries.

Workload identity and authentication

The project user, the associated project service account, and the community service agent are kept separate. To run tasks under a service account, the latter has to be added to the project; its permissions for external resources are assigned separately.

In the documented branch of a task with a service agent, its token is saved to a file, the path to which the task gets via SA_TOKEN_FILENAME. The official guide does not define this file's permissions or process isolation: the task owner separately configures access to the path using the selected image's tools and does not transfer the token into task parameters, logs, or evidence.

Roles and scope

The project uses datasphere.community-projects.viewer, datasphere.community-projects.developer, datasphere.community-projects.editor, and datasphere.community-projects.admin depending on which operation is required. For the community, datasphere.communities.viewer, datasphere.communities.developer, datasphere.communities.editor, and datasphere.communities.admin are used separately.

For a task under a service account, the datasphere.community-projects.developer role for the project is checked; a broad role for the cloud does not replace access to the project.

If the service agent of the task is reading Lockbox, it gets the lockbox.payloadViewer role for the particular secret. If the secret uses a custom KMS key, it gets the kms.keys.encrypterDecrypter role for that key as per the Lockbox access model.

DataSphere relevant operations and inheritance are cross-checked against the service access model.

Network

The default or custom subnet, VPC, security groups, and outbound path are recorded. A project in a service subnet has documented internet access; a custom subnet without configured NAT does not get it.

For a custom subnet, the project's service account needs the vpc.user role; if internet access is maintained via a NAT gateway, the vpc.gateways.user role is additionally required as per the project settings. Roles are assigned for an actually selected network or gateway, but not entire cloud.

For notebooks and tasks, no direct access to the subnet is declared. If a node or alias is published, the endpoint and public/private status get recorded; DataSphere docs state that the public alias is accessible to all authenticated Yandex Cloud users, while the private one requires the described project permissions. If no node or alias exists, this inbound branch is marked as N/A.

Secrets and credentials

For a project secret, its ID, owner, and scope are specified, but not the value.

For a task that accesses Lockbox, the following are recorded: service agent, specific secret, bindings of the lockbox.payloadViewer role and applicable KMS permission, as well as the SA_TOKEN_FILENAME variable name according to the official guide. The selected image and task specification must separately limit the path users; the token value and secret content do not form part of the evidence.

Configuration objects

Community and project IDs, participants and roles, project service account and community service agent, cloud networks, subnets, security groups, NAT gateways, SA_TOKEN_FILENAME (without the token value) and the selected restriction of path access, limits, task ID and specification, task data period, secrets, datasets, files, artifacts, node, and alias.

Telemetry and blind spots

Audit Trails in DataSphere covers published management-plane operations. Node and alias metrics show operational status, but not cell execution, data content, prompt logs, or the full provenance chain; these are covered by process logs and the provenance card.

Positive and negative checks

1. Start as an authorized or unauthorized user or service account. Check the task's access to an allowed and forbidden resource.
2. For the service agent branch, check a successful API call with a token from SA_TOKEN_FILENAME, denial after the role is revoked, and that no token value is present in parameters and logs.
3. Verify the outbound path of the custom subnet, secret visibility, task data period, and management event without displaying the token or secret value.
4. Trace the dataset and model package through to release.

What you need for profile implementation

• Architecture: projects, workload types, network, sources, and recipients.
• Policy: roles, limits, TTL, shared access, and internet access.
• Legal approach: training data and usage permissions. If undocumented telemetry of data operations is required, it must not be claimed until there is an official source; until then, it remains an application-level blind spot.

Runtime in Managed Service for KubernetesRuntime in Managed Service for Kubernetes

Scope and status

The profile applies if Managed Service for Kubernetes is the AI component runtime.

Flow and trust boundaries

Ingestion → Service → Pod → AI/RAG/MCP dependencies; Kubernetes API, modes and workloads are evaluated separately. Identity and Access Management manages Yandex Cloud resources, Kubernetes RBAC manages Kubernetes API objects; application authorization manages user data.

Workload identity and authentication

The following identities are separated:

• Cluster service account.
• Node group service account.
• ServiceAccount resource of a Kubernetes workload and its linked IAM account.
• Kubernetes API user.

If a workload does not access the Yandex Cloud API, its cloud credentials are marked as N/A.

For a workload to access the API directly without an authorized key, you can use a workload identity federation: an OIDC token of the ServiceAccount resource in Kubernetes is exchanged for an IAM token of the linked IAM service account. The External Secrets Operator retains a separate path with the specified key.

A workload utilizing a node’s service account token via the metadata service is the node’s shared identity. To implement this, you must explicitly restrict permissions and provide justification. Otherwise, the pod’s access to metadata is blocked.

Roles and scope

• The subject creating a cluster and node group is assigned the k8s.editor role or higher and the iam.serviceAccounts.user role for the selected service accounts. To create these entities with public access, the subject also requires the vpc.publicAdmin role.
• The cluster’s service account gets the minimum k8s.clusters.agent role; for public access, it also gets the vpc.publicAdmin role. If VPC resides in another folder, the account is assigned the vpc.privateAdmin, vpc.user, and vpc.bridgeAdmin roles for the folder in this network.
• The node group’s service account gets the container-registry.images.puller role for the selected Container Registry or the cloud-registry.artifacts.puller role for the selected Cloud Registry. For any other registry, these roles are not automatically assigned.
• For user access to the cloud API and Kubernetes API, the k8s.viewer, k8s.editor, k8s.cluster-api.viewer, k8s.cluster-api.editor, k8s.cluster-api.admin, and k8s.cluster-api.cluster-admin roles are used depending on the operation. Inside the cluster, Role/RoleBinding are applied within the namespace. ClusterRoleBinding must be individually substantiated.

Subject and role boundaries are checked against the Kubernetes access model.

Network

The CIDRs of the cluster, nodes, and pods, public access to the master endpoint, security groups, ingress controller, service, and network policy are recorded.

For workspaces, a default-deny rule applies, with required directions whitelisted. The pod’s access to 169.254.169.254 is blocked unless the node’s metadata token is required.

If a workload identity federation is used to access the Yandex Cloud API, the nodes are provided with an outbound path via a public IP address, NAT gateway, or NAT instance, alongside allowed outbound security group rules as per this integration guide. This condition does not require assigning a public IP address to each node if NAT is selected.

Secrets and credentials

In a workload identity federation, there is no authorized key: instead, the IAM service account, federation, federated credentials, and system:serviceaccount:<namespace>:<ServiceAccount_name> exact subject are recorded.

A separate External Secrets Operator documented integration uses a service account authorized key stored inside a Kubernetes Secret and the lockbox.payloadViewer role for a specific secret. This path with the key does not qualify as a keyless workload identity: the key, SecretStore, ExternalSecret, target Secret, rotation, and consumer are tracked according to AI-SECRET1.

Configuration objects

Cluster and node group IDs, service accounts, namespaces, ServiceAccount Kubernetes resources, deployments, jobs, Role/ClusterRole and bindings, network policies, Ingress and Service objects, security groups, pod security context, resource limits, SecretStore/ExternalSecret/Secret, and image digest.

For a workload identity federation, the following is also recorded: the federation active status for a cluster and node group, issuer URL and JWKS URL, workload identity federation IDs and its bindings, IAM service account ID, yandex.cloud/federated-yc-service-account-id annotation, and an external subject: ServiceAccount resource in Kubernetes.

For audits, master-logging.enabled, audit-enabled, log-group-id or folder-id, and the logging.writer role assigned to the resource service account are recorded.

Telemetry and blind spots

The Kubernetes API audit is only delivered to Cloud Logging with master-logging.enabled and audit-enabled and configured assignment of log-group-id or folder-id. For info about these settings, see this cluster update guide. The record content is restricted by the published audit policy.

The node, pod, and application logs as well as application-layer agent tracing are separate sources; the management-level audit does not prove their completeness.

Positive and negative checks

1. Check IAM and RBAC individually and run an allowed and prohibited API action.
2. For a workload identity federation, check the exchange of the allowed ServiceAccount resource token in Kubernetes, confirm rejection if using a different namespace or ServiceAccount resource, and a failure an outbound route or rule to the Yandex Cloud API is deleted.
3. Test cross-namespace requests, the default deny network policy, and metadata endpoint.
4. Test retrieval and revocation for a test secret without outputting its value and check the image digest.
5. Check the audit event and its correlation with the pod or application log.

What you need for profile implementation

• Architecture: topology, inbound path, workload identities, and dependencies.
• Policy: RBAC, outgoing traffic, pod security settings, limits, and retention period.
• Legal approach: stored and training data.

Runtime in Serverless Containers or Cloud FunctionsRuntime in Serverless Containers or Cloud Functions

Serverless Containers and Cloud Functions are verified separately: the container revision and function version, management roles, triggers, and logs are not interchangeable.

Serverless ContainersServerless Containers

Scope and status

The profile is applied if Serverless Containers is the runtime.

Flow and trust boundaries

HTTPS/trigger/API Gateway → service's public API → active revision → targets. The managed instance does not accept an arbitrary inbound connection directly.

Workload identity and authentication

For a non-public container, the calling environment obtains an IAM token for its workload identity and has the serverless-containers.containerInvoker role. The public branch exists only if this role is bound to the system:allUsers system group, in which case the request does not contain an authorization header. The binding and the absence of credentials are verified as per the public container guide.

The revision's service account accesses targets and obtains a short-lived IAM token through the GCE metadata service as per the official guide. These subjects and their permissions are kept separate.

Roles and scope

serverless-containers.containerInvoker is used for invocation; serverless-containers.editor manages the container, and serverless-containers.admin manages its access permissions only depending on what operation is required.

The subject that creates the revision with a service account separately has iam.serviceAccounts.user for that account.

The revision's service account gets granular roles for the targets and, if the image resides in a non-public Container Registry, also the container-registry.images.puller role for the selected registry or repository. The semantics and assignment levels are cross-checked against the Containers access model.

Network

Even if connecting a custom network, the container is invoked via the public API of the service. The inbound access mode, cloud network, subnet, and outbound path are recorded; the custom network opens access to its resources, while the default network uses documented NAT. For more information, see the network model description.

Secrets and credentials

The Container + Lockbox integration is at the Preview stage. The service account gets lockbox.payloadViewer for the specific secret and kms.keys.encrypterDecrypter for the key if the secret is encrypted with a custom KMS key. The link forms a part of the new revision; the value may be cached for up to five minutes after revocation.

Configuration objects

Container and revision IDs, active revision, image digest, service account, access mode, CPU, memory, concurrent request processing, timeout, environment variables and links to secrets, cloud network, log group, and access permissions.

Telemetry and blind spots

Cloud Logging receives the request log and stdout/stderr as per the log model; requests are correlated via X-Request-Id. Audit Trails shows published management operations but not every invoke or application decision.

Positive and negative checks

1. Perform an invocation with and without the role.
2. Check the active and previous revisions, and the operation with the target performed by the minimum role.
3. Check the issuing and revocation of a test secret with cache taken into account.
4. Check the request log and rollback.

What you need for profile implementation

• Architecture: trigger, inbound mode, network, and targets.
• Policy: public accessibility, scaling, timeout, log content redaction, and retention period.
• Legal approach: request content and logs.

Cloud FunctionsCloud Functions

Scope and status

The profile is applied if Cloud Functions is the runtime.

Flow and trust boundaries

HTTPS/trigger/API Gateway → service's public API → active revision → target resources. The trigger, Gateway, and direct calling subject are considered separately.

Workload identity and authentication

For a non-public function, the calling environment obtains an IAM token for its workload identity and has the functions.functionInvoker role. The public branch exists only if this role is bound to the system:allUsers system group, in which case the request does not contain an authorization header. The binding and the absence of credentials are verified as per the public function guide.

The version’s service account gets access to target resources, while its short-lived IAM token is available through the handler context or GCE metadata service as per the official guide. Service accounts of the trigger and API Gateway are checked separately and must also have permissions to call a non-public function.

Roles and scope

functions.functionInvoker allows the call; functions.editor manages functions, versions, and related objects; functions.admin manages access in addition to the above.

The subject which binds a service account to a version, trigger, or API Gateway gets the iam.serviceAccounts.user role for that account; this role is used during deployment and does not define the function’s permissions during execution. The exact operation and scope are cross-checked against the Cloud Functions access model.

Network

The function is called via the service’s public API. Random incoming connection to the instance is not supported. API Gateway, trigger, custom or default network, and actual outgoing path as per the Cloud Functions network model are recorded.

Secrets and credentials

The Cloud Functions and Lockbox integration is at the Preview stage. The link to the secret creates a new version, and the value may be cached for up to five minutes after revocation. The lockbox.payloadViewer role for the secret, the kms.keys.encrypterDecrypter role for the custom KMS key (if used), and the exact version of the secret are checked.

Configuration objects

Function ID, version, and tag, runtime environment, entry point, code hash, memory, timeout, cloud network, service account, links to secrets, log group, scaling, trigger, and API Gateway.

Telemetry and blind spots

Cloud Functions logs contain the query ID and stdout/stderr. Cloud Functions audit logs are published management operations, not data plane logs for each call.

Positive and negative checks

1. Make one allowed call and one denied call.
2. Check the trigger identity, version and tag switching, and target resource failure.
3. Check the issuing and revocation of a test secret.
4. Check the query ID correlation and version rollback.

What you need for profile implementation

• Architecture: trigger, Gateway, version, and target resources.
• Policy: access, scaling, timeout, log content redaction, and retention period.
• Legal approach: content of the call and logs.

Runtime on Compute Cloud with a self-hosted modelRuntime on Compute Cloud with a self-hosted model

Scope and status

This profile applies when the AI model or runtime environment runs on a VM instance or instance group. The organization is responsible for the image, operating system, updates, processes, model loader, and application logs.

Flow and trust boundaries

input/load balancer/API Gateway → VM and process → model → disk/Object Storage/external services. The VM cloud configuration, OS, process, and model package are considered separately.

Workload identity and authentication

The VM is associated with a service account; the application obtains a short-lived IAM token through the metadata service.

The subject that creates or modifies the VM separately has the iam.serviceAccounts.user role for the selected service account, as specified in this binding guide. This deployment permission is not an application runtime role.

The VM cloud identity and OS users remain separate. Learn how to get a token in this guide on authenticating from within a VM.

Roles and scope

• VM management. compute.operator allows starting, stopping, and restarting the VM, but not creating or modifying it; compute.editor is used for task-specific management. The deployment identity is separately assigned the iam.serviceAccounts.user role for the associated service account. For a public IP address, the required VPC permission is verified, including vpc.publicAdmin where required.
• KMS and Lockbox. When using a customer KMS key, the subjects that create the encrypted disk or VM, attach the disk, or start or restart the VM get the kms.keys.user role for the specific key as specified in the Compute Cloud encryption guides. The kms.admin role is not required by default. When retrieving a value from Lockbox, the VM service account is assigned the lockbox.payloadViewer role for the specific secret. If the secret uses a customer KMS key, the VM service account is also assigned the kms.keys.encrypterDecrypter role. The VM service account gets no other roles beyond those required for the target storages and APIs.
• OS Login. The user or service account is assigned the compute.osLogin role or the compute.osAdminLogin and resource-manager.auditor roles or higher for the VM folder; compute.operator is only added when connecting over yc compute ssh. Check roles and connection method against this OS Login guide.
• SSH keys in metadata. If your organization keeps an SSH key section within instance metadata, it records the relevant subjects, keys, revocation procedure, and policy rationale, without treating it as OS Login.

For the general cloud role model, see Compute Cloud guides.

Network

The system records VPC, the subnet, security groups, public IP address, routes, NAT, load balancers, and outbound path.

The metadata service is located at 169.254.169.254. Use aws-v1-http-token=DISABLED to disable getting a token via Amazon EC2 IMDSv1 as required by the baseline Yandex Cloud security standard, IAM 16. If the app needs the IAM token of the VM service account, GCE metadata with gce-http-endpoint=enabled, gce-http-token=enabled, and the required Metadata-Flavor: Google header are used. If the app does not need it, both options should be disabled. For more information, see the VM metadata description.

Secrets and credentials

In the documented VM path + Lockbox, user-data only contains the secret ID; the IAM token is taken from the metadata service, and the VM service account with the lockbox.payloadViewer role for the secret requests the token value via the API. For a secret with a customer KMS key, the system also verifies the kms.keys.encrypterDecrypter role for the key under the Lockbox access control model.

The secret value is never stored in the metadata or image.

Configuration objects

VM, disk, disk image, and disk snapshot IDs, KMS key, service account, metadata flags, security groups and public IP addresses, routes, load balancers, cloud-init, operating system, runtime, process manager, and model package ID and hash.

For administrative access, the system records the organization's OS Login modes, the serial_port_settings.ssh_authorization value (OS_LOGIN or INSTANCE_METADATA), and the enable-oslogin value (for an existing VM with the agent installed manually). These values and modes are verified against the organization's OS Login setting and guide for the existing VM.

As per this Compute Cloud guide, you can enable KMS encryption for a disk, image, or snapshot when creating them.

Telemetry and blind spots

Compute Cloud Audit Trails covers published cloud operations, but not the OS or model process. Monitoring metrics require an available service metric, Yandex Unified Agent, or application instrumentation. Operating system and application logs are delivered separately.

Positive and negative checks

1. Check IAM, the security groups, routes, public IP addresses, aws-v1-http-token=DISABLED, selected GCE metadata flags, and encryption settings. A token request without Metadata-Flavor: Google must be denied.
2. For OS Login, check that access with compute.osLogin or compute.osAdminLogin is allowed and, after the role is revoked, denied, and does not require an extra compute.operator for non-CLI connections.
3. For the INSTANCE_METADATA section, verify the list of SSH keys and revoke the test key.
4. Send an allowed network/IAM request and a denied one.
5. Retrieve and revoke the test secret. Check that the value is missing from the image and user-data.
6. Correlate a management event, an OS or application log, and the correlation ID.
7. Verify recovery or rollback.

What you need for profile implementation

• Architecture: ingress path, GPU/CPU, runtime environment, process isolation, and storages.
• Policy: security and OS update settings, metadata, KMS, backups, and retention period.
• Legal approach: data, model, and licensing.

Calling an external model API from Yandex CloudCalling an external model API from Yandex Cloud

Scope and status

This profile applies when a request leaves Yandex Cloud and goes to a model provider or AI API. IAM does not manage the provider account.

Flow and trust boundaries

runtime in Yandex Cloud → NAT/proxy/firewall → provider DNS/TLS endpoint → external API → response. The data transfer boundary comes before the outbound request, and the response is treated as untrusted again.

Workload identity and authentication

A Yandex Cloud service account gets external credentials from an approved storage. The provider account, its roles and their revocation status are verified in the provider's system against approved contractual and technical documentation, not in IAM.

Roles and scope

The runtime only requires specifying the Yandex Cloud roles for Lockbox, log, proxy, and other Yandex Cloud resources in use. External key permissions are documented separately for each operation and provider model.

Network

The VPC route, NAT, proxy or firewall, DNS, and TLS endpoint being verified are recorded. VPC routing verifies the next hop, but not the list of allowed FQDNs or contents. The recipient restriction is implemented at the proxy, firewall, or application layer and verified by sending a negative test request.

Secrets and credentials

API keys, mTLS keys, or other credentials are stored in Lockbox or other approved dedicated storage. When using Lockbox, the documented delivery path for the selected runtime is taken from its profile. The owner, ID, and version of the secret are recorded, along with its expiration, rotation, and revocation status; the secret value is not recorded.

Configuration objects

Model provider and endpoint, DNS/TLS, proxy or firewall route, schema of transmitted fields, credential reference, timeout, retries, circuit breaker, quota, correlation ID, as well as declared processing region, retention period, and subcontractors.

Telemetry and blind spots

Application and proxy logs, along with Monitoring, cover the observable client path. Audit Trails shows only related Yandex Cloud operations, such as accessing a secret or updating a route, but not provider-side request processing.

Positive and negative checks

1. Send an allowed request with synthetic data.
2. Send a request to an unapproved host name and a call using revoked credentials. Make sure DNS/TLS rejects both.
3. Test the behavior under repeated failures or exceeded limits, and when submitting an extra field.
4. Correlate the application and proxy logs without attributing the external revocation to IAM.

What you need for profile implementation

• Architecture: provider, endpoint, runtime, route, and fallback path.
• Policy: list of allowed recipients, timeouts, retries, quotas, and logged fields.
• Legal approach: legal framework, personal data, retention period and storage location, cross-border transfers, and subcontractors.

Boundaries of shared security toolsBoundaries of shared security tools

The DSPM scanning service account is assigned the dspm.worker role according to this scan guide. For a bucket with a custom KMS key, kms.keys.decrypter is also required. If bucket access is governed by a bucket policy, the allowlisting of the published Security Deck IP addresses and successful completion of the scan are verified separately.

To view permissions in CIEM, you need the organization-manager.viewer role for the organization or a broader documented role; access revocation is verified separately based on the documented roles and restrictions.

YCDR evidence includes access approval, a separate collector configuration for each cloud, successful transmission of a test event over TLS, and ycdr.admin binding. For details, see the YCDR review and access model description.

CIEM and YCDR conditions do not extend to the entirety of Security Deck or its Alerts.

Compliance and processing of personal and regulated dataCompliance and processing of personal and regulated data

This section sets out technical requirements for implementing an approved legal and compliance approach for an AI scenario. It does not define the lawful basis for data processing, allowed recipients, retention period, or legal status of cross-border transfer.

The Yandex Cloud features and tools, including region selection, encryption, DSPM, IAM, and audit logs serve strictly as technical controls; they do not replace a review of a specific workflow by your organization’s authorized legal or compliance teams.

Throughout this section, regulated data refers to any personal data, trade secrets, banking secrets, payment details, or any other categories subject to special processing rules under the applicable law, agreement, or internal policy.

Legal approach and placementLegal approach and placement

Approved processing admissibilityApproved processing admissibility

Requirement ID: AI-COMPLY1

Risk

Running AI scenarios without established legal, organizational, and technical requirements for personal data or other regulated data processing may lead to regulatory violations, breaches of contractual obligations, or internal policy non-compliance.

Requirement

Prior to feeding regulated data into a model, RAG database, vector index, log, backup, external API, or any other component, the authorized party must define, document, and agree upon the following:

• Goal, lawful basis, and allowed processing operations.
• Categories of subjects, data categories, and minimum required fields.
• Roles of the organization, Yandex Cloud, external providers, operators, and other recipients.
• Allowed processing and storage locations, localization rules, and cross-border transfer requirements.
• Data processing delegation terms, applicable contractual obligations, and subcontractor involvement.
• Time frames for storing, deleting, destroying, archiving, and backing up data.
• Requirements for data protection and logging, incident response, and fulfilling data subjects’ rights.
• Features of data used for training, fine-tuning, assessing, and using a model as well as building a RAG database.

This baseline must be linked to a versioned processing card detailing the goal, data classes, source, operations, exact Yandex Cloud resources and region, model and provider, recipients, storage details, technical measures, and the approving authority. This card must map to data flows defined under AI-SDLC1. For a production processing scenario, the N/A result is prohibited.

Implementation

As a data controller hosting personal data in Yandex Cloud, the customer delegates data processing to the provider under the applicable agreement terms. Information on the Yandex Cloud measures and certifications is available in its compliance documents; however, this does not replace the assessment of the customer’s specific system. The configuration of Yandex Cloud services does not translate into a legal approach. Configuration proves that controls are in place but does not establish the lawful basis.

Recommendation

Conduct privacy and compliance assessments prior to connecting a model, external API, or RAG system. These assessments must also be performed prior to model training or fine-tuning, and ahead of any major updates to the data, recipients, region, endpoint, or architecture.

Manual check

1. Map the approved baseline to the actual fields, subjects, models, logs, indexes, and recipients.
2. Verify that each type of regulated data, each scenario, and each recipient is covered by the baseline.
3. Do not allow the processing of undocumented data types or transfers to unauthorized recipients prior to revising and approving the baseline.
4. Select an actual resource, log, or request field and trace it to the approved processing card. An expired baseline means failure.

Artifact

• Approved legal and compliance approach.
• AI scenario registry.
• Data flow diagram.
• Architecture description.
• List of processors and recipients.
• Agreement references.
• Baseline revision records.
• IDs of data flows and resources.
• Examples of traces without real personal data.

Placement restrictions are implemented in the architecturePlacement restrictions are implemented in the architecture

Requirement ID: AI-COMPLY2

Risk

Hosting personal data or any other regulated data in components that fail to meet the localization, region, protection, or retention requirements, creates a risk of unauthorized processing and unaccounted data copies.

Requirement

The organization must create and maintain an up-to-date lifecycle map for regulated data within the AI workflow: ingestion, transfer, storage, backup, caching, logging, indexing, vectorization, inference, training, fine-tuning, maintenance, and deletion.

For each component processing regulated data, explicitly define:

• Permissible use and data category.
• Cloud, folder, region, availability zone, or external location.
• Resource owner and data owner.
• Backup retention period and methods for storage, deletion, destruction, and control.
• Applicable protection measures.
• Incoming and outgoing data flows, including external endpoints.

Inventory must track each copy of data, including exports. Approved services and regions must be enforced proactively via the resource creation and release policy.

Implementation

A Yandex Cloud region is a geographical area that groups availability zones. It has its own structure and services. Selecting a region does not prove legal compliance and does not describe data transfer to external systems. You cannot assume where data is processed by simply looking at resource folder. If using an external provider, you must obtain their official written records of processing locations.

Recommendation

Ensure that the component registry encompasses, at minimum: Object Storage, Yandex Managed Service for PostgreSQL, or any other databases, VM disks, queues, caches, Cloud Logging, Audit Trails, RAG indexes, vector databases, observability tools, administrator workstations, and external AI APIs.

Check

1. Trace a synthetic regulated object from the ingestion point to all its copies and recipients.
2. For each cloud resource, cross-reference its region and actual location against the approved decision.
3. Check backups, logs, indexes, caches, and work data for unaccounted copies.
4. Any unaccounted copy, external route, or region change must block modification deployment until the approval is renewed.
5. In case of a negative test, deployment or export to a prohibited branch must be blocked.

Artifact

• Data flow map.
• Component registry.
• Yandex Cloud resource inventory.
• Region and folder configuration.
• Retention polices.
• Deletion evidence.
• Architecture review results.
• Resource exports.
• Migration or deletion record.

External recipients and cross-border flowsExternal recipients and cross-border flows

Transfer to external recipients is allowed and limitedTransfer to external recipients is allowed and limited

Requirement ID: AI-COMPLY3

Risk

Sending personal data or any other confidential information to an external model, API, SaaS tool, or third-party provider without a compliance review may lead to a violation of legal requirements, contractual obligations, and organization policies.

Requirement

Before sending data, the organization must document the following for each external recipient:

• Recipient, their jurisdiction, and allowed subcontractors.
• Purpose, categories, composition, and maximum allowed amount of data.
• Allowed endpoints, domain names, IP addresses, and the sending workload identity.
• Data processing, storage, and backup region, if defined by the provider.
• Terms for data processing delegation, cross-border transfer, retention, deletion, and processing termination.
• Validity period of the decision and events requiring its review.

An application or centralized AI gateway must only send approved data to a trusted endpoint. Changing a recipient, endpoint, processing region, included fields, provider terms, or subcontractor requires a new check.

Implementation

VPC route tables allow routing subnet traffic through a specified next hop but do not confirm transfer legitimacy and do not support content filtering or recipient control at the application layer.

Recommendation

Implement a centralized AI integration layer to handle workload authentication, recipient whitelisting, field minimization, PII masking, request metadata logging, and blocking of unapproved directions. Do not write the full contents of regulated requests and responses into technical logs without a reason and extra security measures in place.

Check

1. Cross-reference the approved registry of external recipients with the configurations of applications, DNS, TLS connections, VPC routes, and outgoing network traces.
2. Run a test allowed transfer of data to an approved endpoint.
3. Try to send a restricted field or route a request to an unapproved endpoint.
4. The unauthorized transfer must be stopped before the data leaves the trusted perimeter.
5. The request redirect attempt to an unapproved address must be blocked, and the denied call must not appear in the outgoing traffic log or provider traces.

Artifact

• Data transfer evaluation.
• Registry of recipients and endpoints.
• Contractual documents or references to them.
• AI gateway configuration.
• Network policies.
• Block logs and test results.
• Secret ID.
• Provider evidence.

Cross-border flow is allowed by a separate decisionCross-border flow is allowed by a separate decision

Requirement ID: AI-COMPLY4

Scope

The requirement applies if data, a backup, log, model request, model results, or any other component of the workflow may cross a boundary defined by applicable law or an internal placement policy.

Risk

Cross-border transfer carried out without complying with applicable procedures, notifications, or contractual or organizational requirements may result in a law violation and regulatory action.

Requirement

Prior to the initiation of a cross-border flow, authorized representatives of the organization responsible for legal matters or compliance must determine and approve the following:

• Occurrence of a cross-border transfer in a specific scenario.
• Countries, recipients, subcontractors, and end points.
• Categories, composition, target, and legal basis of the transfer.
• Applicable prohibitions, restrictions, approvals, notifications, and contractual terms.
• Requirements for protection, retention periods, deletion, and implementation of subject permissions.
• The decision's validity period and the events requiring its re-evaluation.

The technical team must follow the authorized representatives' decision and align it with the resources, routes, and endpoint from AI-COMPLY2 and AI-COMPLY3. The presence of TLS, the choice of region, or a contract not reviewed by authorized representatives does not in itself constitute confirmation of legal admissibility.

For each flow, the following are specified: sender and recipient, data fields and data class, source and target locations, transport, storage and onward transmission, and solution ID. Allowlists for recipients and destinations with a default-deny policy are applied during resource creation and to outbound traffic; unknown or modified endpoints, regions, or recipients are blocked.

An internal flow across the border does not, in itself, constitute a legal conclusion regarding a cross-border transfer.

Check

1. Select one outbound data flow and map the country, recipient, data categories, endpoint, subcontractors, and timeframe against the current solution.
2. Verify that changing the supplier region, destination, subcontractor, or data composition blocks the flow until a new decision is made, if the previous decision does not cover the change.
3. Make sure the cross-border flow details are aligned with the architecture map and the recipient registry.
4. If the processing location or subsequent recipient is unknown, the flow halts until reputable information is received; no assumptions are made.

Artifact

• Legal and compliance assessment.
• Confirmation of required procedures.
• Register of cross-border flows.
• Architectural schema.
• Endpoint configuration and changelog.
• Registry of flows with solution IDs.
• Failure of an unknown line.

Anonymization, pseudonymization, and personal data maskingAnonymization, pseudonymization, and personal data masking

Regulated data transformation reduces identifying information provided to a model or external component down to an absolute minimum required by a scenario. The transformation method is selected based on whether you need to preserve structure, relations between records, and ability to recover values, and whether there is risk of re-identification.

Below is a technical glossary of terms used throughout the standard. It does not constitute a legal definition or replace an assessment by duly authorized officers.

• Masking: Concealing or replacing a part of a value, e.g., +7 *** ***-12-34 or [USER_NAME]. The format or some part of the value may remain as is.
• Pseudonymization: Replacing a value with an alias or code. Reverse transformation is possible if you have access to the key, mapping table, or detokenization service.
• Tokenization: Replacing a value with a token, usually when an application needs to restore the value after processing by a model.
• Hashing: Deriving a calculated value; its resilience depends on the entropy of the source data, salt, secret, and risk of brute-force attacks.
• Aggregation: Replacing detailed data with grouped or statistical values.
• Anonymization: Transformation that provides no standard way to recover the identity from the transmitted dataset; its sufficiency is evaluated for the specific dataset and risk of re-identification through linkage attacks.

Protective transformation takes place before the trust boundaryProtective transformation takes place before the trust boundary

Requirement ID: AI-COMPLY-PII1

Risk

Transmitting personal data to an LLM or external AI service when such data is not required to perform the task at hand increases the risk of a data breach and non-compliance with data processing requirements.

Requirement

If the approved solution requires transformation, the organization must perform PII detection and transformation before transferring data to a segment of the model, cloud, or external environment that is not authorized to view the original values.

For each scenario, the following must be defined:

• Data fields and categories subject to discovery and transformation.
• Algorithm, execution point, and policy version.
• Reversibility eligibility.
• Keys, mapping tables, and the detokenization sequence.
• Subjects with the permission to reverse conversion.
• Safe behavior in the event of a converter error or unavailability.

If recovery is not required, methods that are irreversible, or practically irreversible for the given scenario, are employed. If recovery is necessary, pseudonymization or tokenization is allowed, provided that the recovery is performed within the organization's controlled environment.

If the model requires only statistical properties, aggregation or other forms of detail reduction are applied. Hashing is only allowed after assessing the risk of brute-force attacks, matching, and re-identification.

The converter is placed before the first prohibited boundary; minimization is performed first, followed by the selected transformation, and the validator rejects any remaining prohibited fields.

Implementation

You can use Lockbox to store secrets and KMS to manage encryption keys; the choice and integration of these tools must align with the approved architecture. KMS and DSPM protect keys and mapping tables, but encryption in itself is not anonymization; KMS, KMS, and guardrails do not constitute a transformation in themselves.

Recommendation

Use semantically meaningful tokens, such as [USER_NAME], [PHONE], and [ORDER_ID], provided they preserve the query's meaning and do not reveal the original value.

Check

1. Using a synthetic record, trace the source field, transformation result, model request, and logs.
2. Confirm that the initial value does not cross the established confidence limit.
3. Make sure the reverse transformation is only available to an authorized subject and logged without recording the original value.
4. Provide an input containing a prohibited residual field and simulate converter unavailability: a subsequent outbound call must not take place.
5. Verify the absence of initial values ​​outside the boundaries by checking the logs and traces.

Artifact

• Transformation policies.
• Gateway or application configuration.
• Registry of tokens and keys without value disclosure.
• Test results.
• Access control model.
• Transformation type and version.
• Confirmation of the absence of data outside the boundaries.

Personal data detection tools match data and riskPersonal data detection tools match data and risk

Requirement ID: AI-COMPLY-PII4

Risk

Inadequate personal data detection tools may leak sensitive data when sending requests to LLMs, or capture such data in indexes, logs, and other storage locations.

Requirement

The organization must use data discovery tools aligned with the data composition and risk level: rules, regular expressions, dictionaries, NER models, classifiers, DLP/DSPM tools, AI gateways, or special tokenization services.

These discovery tools must support:

• Tracking of false positives and false negatives.
• Rule versioning and controlled configuration modification.
• Test suites featuring multilingual, structured, and nested inputs.
• Monitoring of errors, bypasses, and unknown field types.
• Regular quality checks using representative synthetic or allowed test data.

Misses and false triggers must be evaluated separately by data class, language, format, and path. Policy and legal approach owners must approve the acceptable result; the general threshold is not defined. A critical miss must must trigger a fail-safe state or route the stream to quarantine. If a detector is not declared, this requirement may be considered N/A, but the AI-COMPLY-PII1 and AI-COMPLY-PII3 requirements remain applicable.

Implementation

The DSPM module in Security Deck is designed to discover sensitive information in supported sources. Use its results for data detection and control but do not treat them as a replacement for data transformation inside model queries.

Recommendation

Include non-standard wording, transliteration, nested payloads, JSON, CSV, documents, OCR texts, prompt injections, and intentionally corrupted inputs in test suites.

Check

1. Run a test suite on synthetic data for all supported personal data categories.
2. Document the precision, recall, or any other quality metric approved for this specific scenario.
3. Make sure that changes to a rule, classifier, or model undergo the change approval procedure.
4. Confirm that an unknown or unrecognized field type does not trigger an uncontrolled transfer of the original value.
5. Known positive and negative examples must be run upon each significant detector change.

Artifact

• DSPM, DLP, gateway, and classifier configurations.
• Rule versions.
• Test suites.
• Quality assessment results.
• Requests and change logs.
• Test suite management rules.
• Detector versions.

Transformation is controlled and not bypassed on errorTransformation is controlled and not bypassed on error

Requirement ID: AI-COMPLY-PII3

Scope

The requirement applies if one of the following is implemented for the scenario: software-based masking, tokenization, pseudonymization, detokenization, or another protective transformation.

Risk

Unauthorized de-anonymization, substitution of rules, key compromise, or emergency bypass of the transformation process can lead to disclosure of regulated data.

Requirement

Access to modifying algorithms and rules, reading verification records, using keys and mapping tables, and performing reverse transformation must be granted based on the principles of least privilege and separation of duties.

A masking, tokenization, pseudonymization, detokenization event or another protective transformation is generated by an application or transformation component. Cloud Logging only accepts this event. Audit Trails records published cloud operations but does not acknowledge the execution of each individual application-level transformation operation. For each forward and inverse transformation operation, the following must be recorded:

• Time and technical request ID.
• Component, service account, or user.
• ID and version of the applied rule.
• Type of operation and technical result.
• Indication of an error, failure, or explicitly permitted exception.

Source personal data, keys, and mapping tables must not be included in logs without separate justification, approval, and protective measures.

A parser error, unknown field, corrupted input, or converter unavailability must not result in the model's source data being sent to an external recipient or a technical log; acceptable failure behavior is defined alongside the processing policy. Any subsequent call to a model, RAG, tool, or log must only receive the converter's typed, successful output; a bypass, timeout, exception, or invalid result will block the call.

Read permissions for the logs in Cloud Logging and Audit Trails must also be restricted.

Recommendation

Export required audit events to Yandex SIEM, set retention periods for records, protect it against unauthorized alteration, and regularly review access to it. Yandex Cloud documentation also recommends analyzing Cloud Logging and Audit Trails when investigating a compromise of secrets.

Check

1. Perform a successful transformation using synthetic data and check how the following are handled: input with an unknown field, a corrupted object, and converter unavailability.
2. Verify the failure before crossing the trust boundary in all error scenarios.
3. Check for an attempted bypass via an alternative API, queue, log, or administrative interface.
4. Verify the denial of the reverse transformation to an unauthorized subject.
5. Confirm that the evidence contains time, component, rule version, operation type, and error or bypass indicator – without source values, keys, or mapping tables.
6. Make sure the subject who modifies the rule does not get the permission to perform detokenization and modify or read evidence without a separate, approved exception at the same time.

Artifact

• IAM policies and role models.
• Audit Trails and Cloud Logging configuration.
• Transformation logs.
• Rejection logs.
• Fault tolerance test results.
• Rules for storage and access to evidence.
• Event schema.
• Unavailability and bypass tests.

Security check and testingSecurity check and testing

The check method must provide a reproducible answer to these three questions: whether the requirement applies, what state was observed, and what evidence proves it. The reviewer must never assume the existence of a resource, role, event, or function based on an architecture component name. They must verify the actual object and check it against the official documentation.

Check scope preparationCheck scope preparation

Prior to the start of a check, the owner provides an architecture description from here that contains precise IDs for resources, models, versions, and subjects. Applicable exceptions and authorization for active tests are attached separately if they fall within the scope of the check.

The reviewer compares this information with the actual configuration and selects applicable requirements. For example, model loader requirements do not apply to managed inference without custom weights; document authorization requirements apply if the RAG contains documents with differing access permissions; and MCP requirements only apply when an appropriate path is present.

The not applicable result is permissible when the lack of a condition is confirmed, but not when the log is missing or the reviewer lacks access. If the architecture is unknown, it is architecture reconstruction that occurs first, rather than requirement closure.

Single requirement check procedureSingle requirement check procedure

The reviewer performs the following actions:

1. Reviews the required target result and applicability condition.
2. Selects the exact resource, version, subject, and data path.
3. Selects the officially documented interface for the check: the management console, CLI, API, or log. Matches the test with a specific requirement and configuration.
4. Checks the configuration and effective permissions in read only mode.
5. Runs an approved scenario.
6. Runs a prohibited or boundary scenario, if safe to do so.
7. Maps the cloud event to the application trace and documented gaps in telemetry.
8. Saves the minimum evidence and output.

The requirement check result is recorded with one of these statuses: met, not met, not applicable, or not checked.

The met status is only acceptable if the observed state matches the required one in all relevant branches, and there is no unexplained bypass, or a documented exception applies. A partial check of the relevant branches fails to satisfy the requirement.

The requirement is not met if a prohibited subject, stream, or action succeeds, a required setting is missing, or the evidence pertains to the wrong resource or version.

If even a single relevant branch is not checked, the final status will be not checked stating the unchecked branch and reason. The not checked status does not indicate compliance and requires further checking or creating an exception.

Configuration and IAM checkConfiguration and IAM check

The configuration check must show actual values, not just the design description. For each profile of the Implementation profiles in Yandex Cloud section, its ten fields are checked, including:

• Active version, revision, image digest, model package, or index.
• Public accessibility and endpoints.
• VPC, subnets, security groups, routes, and network policies, where applicable.
• Working service account.
• Direct and inherited IAM bindings.
• API key scope and review period or date.
• Kubernetes RBAC roles and internal storage permissions.
• Links to secrets without getting their values.
• Trail scope, service filters, log purpose, and retention period.
• Alert rule, notification channel, and delivery test.

Defined for each role are a subject, required operation, resource, and a minimum supported scope of assignment. A simple match between the role name and the service name is not sufficient. For an external supplier, permissions are verified within its approved system; they are not superseded by IAM.

Verification commands must not modify bindings, create keys, deploy revisions, or output secrets. A command like set-access-bindings, which replaces the entire set of bindings, is not used for diagnostics.

Log and telemetry checkLog and telemetry check

For a significant operation, the reviewer first looks for it in the official event reference pertaining to the specific service at hand. Then they determine whether the required area and filter are enabled for the actual trail. If the event is missing or does not contain the required context, application or service telemetry is used.

The minimum result record contains:

• Requirement ID.
• Check date and time.
• Exact resource and version.
• Checked subject.
• Interface or verification command.
• Expected and observed result.
• Link to the minimal evidence.
• Output with one of the met, not met, not applicable, or not checked statuses and, if required, the associated exception.

For an active test, the test data, permitted scope, rollback method, and cleanup confirmation are additionally recorded. Secrets, full personal data, raw dialogs, and other extraneous contents are not included in the report.

Secure negative and application testsSecure negative and application tests

A negative test specifically checks the stated limit. A set is selected based on applicable requirements and the profile, rather than being considered a universal program. This includes:

• API call without a role, with an unsuitable key scope, or from a different subject.
• Permitted and prohibited moderation categories and moderator error regarding AI-CONTENT1.
• Reading of an approved and external source by the loader, writing to an intermediate scope and to a third-party index via AI-RAG-INGEST1.
• Comparison of direct, group, and inherited permissions with the date and event of the unscheduled review via AI-IAM5.
• Accessing the target service bypassing API Gateway or the MCP Gateway.
• Network connection from a forbidden namespace or runtime environment.
• RAG search for a document from a different access area.
• Receiving a set with incorrect metadata, size, type, or sensitive field, and its transfer to quarantine or manual review via AI-DATA-CHECK1.
• Model output containing a prohibited command or object.
• Attempt to alter the agent's target via a RAG fragment or a tool result.
• Impersonation of a user, tenant, resource, or revoked session in agent delegation via AI-IAM-COMPROMISE1.
• Repetition of an inter-agent message, unknown schema version, or infinite loop.
• Successful and erroneous protective transformation, bypass attempt, and separation of duties via AI-COMPLY-PII3.
• Transferring an extra field to an external recipient.
• Reading a revoked secret considering the documented cache.
• Closing the old endpoint, key, and direct path after decommissioning, without deleting shared resources.

The test is performed using synthetic data and reversible actions. Without a dedicated written permission, you may not delete a production resource or key, read data belonging to another actual tenant, publish an external action, generate a load or financial spike, or test for failure by crashing a shared service.

If a safe negative test in the production environment is not feasible, it is conducted in an equivalent environment, and configuration alignment is verified separately. Lack of authorization for an active test does not equate to a successful result; instead, the untested part is recorded.

Red teamingRed teaming

Active investigation of model or agent behavior is done only within the scope permitted in writing. The permission specifies systems and endpoints, time, responsible persons, allowed load, test data, prohibition on influencing other tenants, stop conditions, and recovery procedure. Production secrets and real personal data are not used unless specifically permitted or required for an approved purpose.

Scenarios are derived from the system’s actual capabilities, trust limits, and the requirements of this standard, not from universal taxonomy undocumented for the project. For a text-based assistant, it can be attempts to extract a restricted document or bypass an output check; for an agent, to expand the purpose, call a forbidden tool, repeat an action, or bypass confirmation; for a self-hosted model, to additionally check the loader and execution limit.

The organization defines the frequency, depth, and criteria of stops based on the risk, significant changes, and previous results. This standard does not set a universal frequency, severity scale, release threshold, or a single model limitation bypass criterion.

The test result must link together the input condition, system version, observed action, affected limit, and the requirement of the standard. An unusual model response is not a violation by itself until it is demonstrated which required state or limit has been violated.

Fix, exception, and re-checkFix, exception, and re-check

For any unmet requirement, the owner must define the reason, affected resources, remediation steps, responsible person, and due date. The implemented fix must be first tested on the initial scenario, and then the related allowed and prohibited scenarios. Patching one service is insufficient if a patch bypass remains possible via a different service.

If immediate remediation is currently unfeasible, apply the standard exception process from Introduction. Exceptions do not alter the core requirement or hide unverified branches.

The final check package must contain:

• Up-to-date architecture description.
• List of relevant requirements with reasons for classifying any as N/A.
• Results and evidence links.
• List of unmet requirements and remediation plan.
• List of unchecked requirements and branches with reasons and check plan.
• Current exceptions.
• Cloud and application telemetry boundaries.
• Final review date, scope, and participant list.

After changing a model, data, RAG source, tool, external recipient, role, public endpoint, or runtime, the owner must repeat the relevant checks. A full new review is required if the impact of changes cannot be reliably isolated.

Standard implementation and monitoring metricsStandard implementation and monitoring metrics

Section status: Reference. The metrics are provided as a basis for building an indicator system and are not mandatory requirements of this standard. Before formal adoption, the calculation formula, measurement period, unit of measurement, related AI-* requirements, and result interpretation must be defined for each metric.

Metrics are there to monitor how requirements are implemented, but as such they do not prove the system is secure. Their list, frequency, and target values are determined by the organization with risk and architecture in mind.

If a metric's value cannot be calculated because there is no applicability condition in the architecture (e.g., there are no agent scenarios), it is marked as N/A. If the denominator is below the organization-specific threshold, the metric is considered N/A with an explanation.

The absence of a registry, end-to-end tracing, alerts, or any other data source required to calculate an applicable metric is not considered N/A: this fact gets registered as lack of control or data, which needs to be fixed.

Standard coverage and complianceStandard coverage and compliance

Identification, access, and secret managementIdentification, access, and secret management

Data and pipeline protectionData and pipeline protection

Security of models, agents, and RAGSecurity of models, agents, and RAG

Vulnerability management and supply chainVulnerability management and supply chain

Monitoring, incidents, and observabilityMonitoring, incidents, and observability

AI security for fintech organizationsAI security for fintech organizations

The appendix contains a reference matrix mapping the requirements of this Standard to external recommendations for ensuring the information security of artificial intelligence systems.

External recommendation sourceExternal recommendation source

Methodological Recommendations of the Bank of Russia No. 3-MR dated 16/06/2026 on ensuring information security when developing and applying artificial intelligence in the financial market.

Application statusApplication status

The application is for reference only and introduces no regulatory requirements on its own. Actions listed under User actions are recommended deficit elimination measures. They become mandatory only if approved by the organization's internal regulatory document. The compliance matrix does not replace the requirements of this Standard.

The application is used to design, develop, deploy, and operate AI solutions, including:

• Applications based on external and internal AI APIs.
• RAG systems, knowledge bases, vector stores, and data ingestion processes.
• AI agents, MCP servers, MCP Gateway, and connected tools.
• ML models, datasets, training, testing, fine-tuning, and deployment processes.
• Cloud infrastructure used for AI solutions.

Compliance statusesCompliance statuses

Responsibility matrixResponsibility matrix

The matrix uses the following roles:

If the User actions column specifies that Yandex Cloud is responsible for fulfilling the requirement, this applies solely to protecting the platform component of the relevant managed service. The user remains responsible for the service configuration, accounts, access permissions, data, integrations, application code, and compliance with the requirements for their AI solution.

Compliance matrixCompliance matrix

AI risk managementAI risk management

Data and privacyData and privacy

Model, development, and supplyModel, development, and supply

Testing and resilienceTesting and resilience

Operation and monitoringOperation and monitoring

Suppliers and open-source software (OSS) managementSuppliers and open-source software (OSS) management