Runtime, 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 permissions are verified before any fragments are fed to the modelDocument permissions are verified before any fragments are fed 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.