[Yandex Cloud documentation](../../index.md) > [Security in Yandex Cloud](../index.md) > Security standard for implementing and operating AI systems in Yandex Cloud, version 1.0.0 > IAM, network, encryption, secrets, and audit

# IAM, network, encryption, secrets, and audit

{#iam-network-crypto-secrets-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 access {#rights-access}

### Intercomponent connections are limited by the actual topology {#intercomponent-connections-limited-by-topology}

{#ai-net2-id}

Requirement ID: `AI-NET2`

{#ai-net2-requirement}

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

{#ai-net2-implementation}

**Implementation**

[VPC security groups](../../vpc/concepts/security-groups.md) 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](../../serverless-containers/index.md) and [Cloud Functions](../../functions/index.md) 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](../../iam/index.md) does not replace the internal Kubernetes or OpenSearch RBAC at the data level.

{#ai-net2-check}

**Check**

1. Map the rules to the stream diagram and execute an allowed and a denied connection for each boundary.
1. Pay special attention to broad access rules, shared service accounts, and paths bypassing the gateway.
1. 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.

{#ai-net2-artifacts}

**Artifact**

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

### Workload identities have minimal effective permissions {#workload-identities-minimal-effective-rights}

{#ai-iam-leastpriv1-id}

Requirement ID: `AI-IAM-LEASTPRIV1`

{#ai-iam-leastpriv1-requirement}

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

{#ai-iam-leastpriv1-implementation}

**Implementation**

The check takes into account direct, group, and inherited bindings. The resource and role model principles are described in [this IAM guide](../../iam/concepts/access-control/index.md).

If the organization uses [IAM access policies](../../iam/concepts/access-control/access-policies.md), this feature complements roles with explicit prohibitions.

The whole of the CIEM (Cloud Infrastructure Entitlement Management) module, as part of [Yandex Security Deck](../../security-deck/index.md), 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](../../security-deck/concepts/ciem.md) and [Viewing a list of a subject's accesses](../../security-deck/operations/ciem/view-permissions.md). [Access revocation](../../security-deck/operations/ciem/revoke-permissions.md) 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.

{#ai-iam-leastpriv1-check}

**Check**

1. For each production subject, export effective direct and inherited permissions in the cloud, folders, and target resources.
1. Map each role to an operation.
1. For Kubernetes, additionally check `RoleBinding` and `ClusterRoleBinding`.
1. 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.

{#ai-iam-leastpriv1-artifacts}

**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 method {#ai-studio-call-uses-documented-auth}

{#ai-iam4-id}

Requirement ID: `AI-IAM4`

{#ai-iam4-requirement}

**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](https://aistudio.yandex.ru/docs/en/ai-studio/api-ref/authentication.html).

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](../../iam/operations/authentication/manage-api-keys.md).

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.

{#ai-iam4-implementation}

**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](../../iam/operations/authentication/manage-api-keys.md) or the management interface.

{#ai-iam4-check}

**Check**

```bash
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.
1. 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.

{#ai-iam4-artifacts}

**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 changes {#effective-rights-reviewed-on-schedule-and-change}

{#ai-iam5-id}

Requirement ID: `AI-IAM5`

{#ai-iam5-requirement}

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

{#ai-iam5-check}

**Check**

1. Select a workload identity, a user with group access, and a subject with an inherited role.
1. 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.

{#ai-iam5-artifacts}

**Artifact**

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

### Privileged user accounts use MFA {#privileged-users-use-mfa}

{#ai-iam-mfa1-id}

Requirement ID: `AI-IAM-MFA1`

{#ai-iam-mfa1-applicability}

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

{#ai-iam-mfa1-requirement}

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

{#ai-iam-mfa1-implementation}

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

{#ai-iam-mfa1-check}

**Check**

1. Get a list of role bindings at the organization, cloud, folder, and critical resource levels for the AI system.
1. Expand groups to individual users and identify users with privileged roles.
1. 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.

{#ai-iam-mfa1-artifacts}

**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 default {#runtime-administrative-bypass-channels-disabled}

{#ai-infra-console1-id}

Requirement ID: `AI-INFRA-CONSOLE1`

{#ai-infra-console1-applicability}

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

{#ai-infra-console1-requirement}

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

{#ai-infra-console1-implementation}

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

{#ai-infra-console1-check}

**Check**

1. For each VM in the AI system, check that serial console access is disabled in the VM settings.
1. If the serial console is on, check that there is a valid exception stating the VM, reason, owner, approval, and duration.
1. 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.

{#ai-infra-console1-artifacts}

**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 protection {#storage-crypto}

### Model and data storages have no unaccounted for public access {#model-data-stores-no-unaccounted-public-access}

{#ai-net5-id}

Requirement ID: `AI-NET5`

{#ai-net5-requirement}

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

{#ai-net5-implementation}

**Implementation**

For Object Storage, you need to check IAM, the ACLs, and the access policy in line with the [service access model](../../storage/security/index.md).

You should not consider roles assigned to [Managed Service for OpenSearch](../../managed-opensearch/index.md) and [YDB](../../ydb/index.md) 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](https://aistudio.yandex.ru/docs/en/ai-studio/concepts/search/) public network path is specified, and no private endpoint is assigned to the service.

{#ai-net5-check}

**Check**

1. Check the effective bindings, ACLs, policies, and network accessibility of each storage.
1. 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.

{#ai-net5-artifacts}

**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 service {#encryption-chosen-by-service-capabilities}

{#ai-crypt1-id}

Requirement ID: `AI-CRYPT1`

{#ai-crypt1-requirement}

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

{#ai-crypt1-implementation}

**Implementation**

Object Storage supports documented [server encryption](../../storage/concepts/encryption.md) 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](../../compute/concepts/encryption.md).

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](../../lockbox/index.md) 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.

{#ai-crypt1-check}

**Check**

1. For every storage, record the encryption mode, relevant key, and subjects with a permission to use the key.
1. 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.

{#ai-crypt1-artifacts}

**Artifact**

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

## Secrets {#secrets}

### A secret has an owner and a managed lifecycle {#secret-has-owner-managed-lifecycle}

{#ai-secret1-id}

Requirement ID: `AI-SECRET1`

{#ai-secret1-requirement}

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

{#ai-secret1-implementation}

**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](../../functions/operations/function/lockbox-secret-transmit.md) gets the link to the secret in the function configuration. The integration is at the Preview stage.
* [Serverless Containers](../../lockbox/operations/serverless/containers.md) uses the integration at the Preview stage.
* [Managed Service for Kubernetes](../../managed-kubernetes/tutorials/kubernetes-lockbox-secrets.md) uses External Secrets Operator.
* In [Compute Cloud](../../compute/operations/vm-create/create-with-lockbox-secret.md), 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.

{#ai-secret1-check}

**Check**

1. Map each secret and its active version to consumers, delivery method, and permissions.
1. 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.
1. 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.

{#ai-secret1-artifacts}

**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 content {#audit-logs}

### Each significant operation has an event source specified {#material-operation-has-event-source}

{#ai-audit1-id}

Requirement ID: `AI-AUDIT1`

{#ai-audit1-requirement}

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

{#ai-audit1-implementation}

**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](../../audit-trails/concepts/trail.md) and [event reference](../../audit-trails/concepts/events.md). The preset should not be treated as an exhaustive configuration; verify the actual configuration using [this Audit Trails guide](../../audit-trails/quickstart.md).

Only events listed in the [Audit Trails reference for Lockbox](../../lockbox/at-ref.md) must be used for accessing values and managing secrets. AI Search and MCP only use published [AI Studio events](https://aistudio.yandex.ru/docs/en/ai-studio/at-ref.html); 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.

{#ai-audit1-check}

**Check**

1. For each significant operation, perform a safe test action and find the associated record.
1. Record the resource, subject, timestamp, event type, and correlation ID, if available.
1. If the cloud event is not documented, provide the application record and evidence of its delivery.
1. 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.

{#ai-audit1-artifacts}

**Artifact**

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

### Logs do not collect sensitive content without a purpose {#logs-no-sensitive-content-without-purpose}

{#ai-audit2-id}

Requirement ID: `AI-AUDIT2`

{#ai-audit2-requirement}

**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](../../logging/security/index.md), and the retention period must align with the approved policy and actual [retention period configuration](../../logging/operations/retention-period.md).

{#ai-audit2-check}

**Check**

1. Review a sample of successful, failed, and denied requests.
1. Check that there are no API keys, Lockbox values, or unapproved content.
1. 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](compliance-pii.md).
1. Additionally, send synthetic markers for secrets and personal data: events must preserve correlation but not the marker values.
1. Also check log reader bindings.

{#ai-audit2-artifacts}

**Artifact**

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