Implementation profiles in Yandex Cloud

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.

Requirement ID	Applicable profiles	What to check	Artifact
AI-SDLC1	All profiles	Architecture description, trust boundaries, relationship between risks and measures	Architecture description, data flow diagram, mapping to actual resources, inventory version differences, test records, sign-off document
AI-APP-WAF1	Any profile with a public HTTP(S) access, e.g.: Managed inference via AI Studio Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Application-level input validation prior to model invocation; API Gateway + Smart Web Security with public access	Rejection records, OpenAPI specification configuration and hash, Smart Web Security profile ID, test requests and their results, subsequent call absence confirmation
AI-CONTENT1	Managed inference via AI Studio	Guardrails as a configuration object, ai.guardrails.editor role, incomplete/content_filter status	Rule version and exported configuration, model instance and guardrail IDs, blocking test, management event or application record
AI-CONTENT2	Managed inference via AI Studio Agent with MCP Gateway and tools Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Deterministic output validator, rejection of prohibited action	Model test responses, rejection records, validator code, schema hash and policy version, confirmation that there is no call for the target system.
AI-CORE5	Managed inference via AI Studio AI Search-powered RAG Runtime on Compute Cloud with a self-hosted model	Separate storage of system instructions, versions, and read/write subjects	Active configuration version, release notes, Spoofing test result, instruction artifact hash, deployment event, current version log
AI-APP-INJECT1	Managed inference via AI Studio AI Search-powered RAG Agent with MCP Gateway and tools	Separation of data and instructions, fail-safety, connection to the source	Test document with instructions, policy decision trace, search result IDs, quarantine or reindexing record
AI-NET3	Calling an external model API from Yandex Cloud	Approved endpoints, service identity, route, timeouts, log	Proxy and firewall configuration, allowed and denied call record, secret ID, call correlation log
AI-NET7	Any profile with a public HTTP(S) access, e.g.: Managed inference via AI Studio Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Domain, route, authentication, limits, backend connection	OpenAPI specification, unauthenticated requests, backend bypass test, Smart Web Security specification and profile IDs, bindings, HTTP test results
AI-DATA1	AI Search-powered RAG Own storage-powered RAG Training and experiments in DataSphere	Registry of source, owner, target, and link to model or index	Registry record, tracing up to object and version, card version, object version or hash, approver
AI-RAG-INGEST1	AI Search-powered RAG Own storage-powered RAG	Loader separation, staging area, target index	Successful upload of an approved object, rejection of an unapproved source, loader version, acceptance and rejection events, reindexing record
AI-DATA3	AI Search-powered RAG Own storage-powered RAG Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Stage separation, write permissions, progression rules	Bucket/prefix access policies, record test from the production environment, stage schema, input and output versions, transition log
AI-DATA4	AI Search-powered RAG Training and experiments in DataSphere Calling an external model API from Yandex Cloud	Classification, minimization, reversibility, keys or mapping table	Field schema, post-transformation selection, rejection of prohibited fields, field mapping by destination, record of copy deletion
AI-DATA5	AI Search-powered RAG Training and experiments in DataSphere	Input versions, metrics, thresholds, data splitting	Saved report with version, criteria, and result, code version for checks and tests, dataset hashes, independent reviewer
AI-DATA6	AI Search-powered RAG Own storage-powered RAG Training and experiments in DataSphere	Checksums, trusted identity, admission procedure	Version-to-source mapping, check bypass test, release manifest with hashes, change event, recovery test
AI-DATA7	Training and experiments in DataSphere	Generator registration, share, separate valuation	Synthetic portion record, Share and control sample report, generator version, unlabeled data rejection test result
AI-TRAIN1	Training and experiments in DataSphere Runtime in Managed Service for Kubernetes Runtime on Compute Cloud with a self-hosted model	Separation of projects, identities, storages, and network paths	Contour mapping, unauthorized secret read and production write test, hashes of job input and output objects
AI-MODEL1	Managed inference via AI Studio Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Source, version, checksum, admission status	Provenance record, mapping to a running instance, model card, hashes, and versions of objects in storage
AI-MODEL2	Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Format, loader, isolated execution, checksum	Isolated execution result, activity monitoring, format and loader versions, isolated environment configuration, admission decision
AI-REL1	All profiles	Exact versions of data, models, instructions, configurations, and images	Release decision, comparison with production revision, release manifest hash, deployment event
AI-REL2	All profiles	Compatibility, replacement procedure, rollback criteria, revocation method	Replacement and rollback test, initiator log, revoked version unavailability, rollback target IDs, return approval
AI-NET2	All profiles	Allowed inbound, outbound, and inter-component connections	Flow diagram, security group rules, allowed and denied connection, connection results from allowed and denied sources
AI-IAM-MFA1	All profiles	Enhanced authentication for privileged users	List of privileged roles and groups, export of effective permissions, confirmation of MFA status or federation policy, exception duration
AI-INFRA-CONSOLE1	Runtime on Compute Cloud with a self-hosted model and any profiles with VM components	Serial console disabled by default, emergency activation only upon exception	VM configuration or serial console policies, access denial, emergency access request and duration (if applicable), activation and deactivation events, OS logs or compensating logs
AI-IAM-LEASTPRIV1	All profiles	Distinct work identity, minimum role, scope of assignment	Effective direct and inherited permissions, role-to-operation mapping, subject → operation → resource → role or scope → binding level matrix, masked key scopes
AI-IAM4	Managed inference via AI Studio Agent with MCP Gateway and tools	IAM token or API key, role, scopes, duration or revision	Key metadata (excluding the value), owner and API mapping, service account bindings, key lifecycle in Audit Trails, results of allowed and denied calls
AI-IAM5	All profiles	Review frequency, scope of direct, group, and inherited permissions	Dated revision record, decisions on excessive permissions, origin of permissions, exception period, repeated negative test
AI-NET5	AI Search-powered RAG Own storage-powered RAG Runtime on Compute Cloud with a self-hosted model	Storage visibility, precise IDs, subjects, network path	Effective bindings, ACLs, read tests from authorized and unauthorized subject, public access and network configuration
AI-CRYPT1	AI Search-powered RAG Own storage-powered RAG Runtime on Compute Cloud with a self-hosted model	Encryption mode, key, key permissions, read test using the native environment	Encryption configuration, permitted read and unauthorized access denial, key ID and bindings, recovery rehearsal
AI-SECRET1	All profiles	Owner, ID, version, consumers, delivery, timeframe, replacement and revocation	Mapping a secret to a consumer, revocation and replacement test, IAM and KMS bindings, value retrieval event in Audit Trails, rotation record
AI-AUDIT1	All profiles	List of operations, event source, trail scope, filters	Trail configuration, safe test action and found record, event map, trail specification, missing event test
AI-AUDIT2	All profiles	Deletion or transformation of secrets and personal data prior to writing	Logging schema, record selection, storage purpose confirmation, test events with synthetic markers, log reader bindings
AI-INFRA6	Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Separation of identities, network paths, state, and permissions	Test of cross-tenant access to file, secret, cache, and endpoint, topology and map of resources and tenants
AI-INFRA-ISOL2	Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Creation and cleanup of a temporary state, process or instance boundary	Synthetic marker, unavailability after task completion, state map with lifespans, cleanup event
AI-INFRA-ISOL3	Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	Separate environment, minimal identity, limits, network control	Permitted operation, boundary tests, process termination, list of permitted operations, confirmation of absence of side effects
AI-RAG-ACL2	AI Search-powered RAG Own storage-powered RAG	Document authorization prior to the transfer of a model fragment	Authorized search, attempt to get another user's document, model context, policy version, actual request context manifest
AI-DECOM1	All profiles	Complete inventory of active and reserved assets, output method	Inventory version, completion report, call test using the same method, pre- and post-inventory, result of search for residual objects
AI-MON-ANOMALY2	All profiles	Signals, source, window, channel, action	Alert configuration, delivery test, logging of the responsible party's action, dashboard and alert IDs, event timeline, incident response ticket
AI-MON-TRACE1	All profiles	Correlation ID, identity, model version, policy decision, tool	End-to-end trace from input to result, no secrets, mapping of platform and application IDs
AI-MON-TRACE2	Agent with MCP Gateway and tools	Task and session IDs, step, tool, result	Trace of a multi-step workflow with a successful and rejected call, task state machine version, acknowledgment record, target system event
AI-FORENSIC2	All profiles	Composition, purpose, timeframe, location, owner, target audience	Saved session, test of permitted and prohibited reading, case scope, result of deletion or deletion prohibition
AI-FORENSIC3	All profiles	Separation from active administrators, segregation of permissions, integrity	Log permissions, only copy modification test, bucket, policy, ACL, versioning, lock, and encryption configuration, object version and hash
AI-AGENT1	Agent with MCP Gateway and tools	List of tools, data, and recipients, maximum consequences	Feature registry, configuration mapping, registry version, test events
AI-AGENT2	Agent with MCP Gateway and tools	Limits, control point, safe state, stop conditions	Cyclic response, recurring error, and limit exhaustion test, policy version and counter configuration, final reason for stopping
AI-AGENT-GOAL1	Agent with MCP Gateway and tools	Trusted source of target, separation of facts, proposals, and instructions	Test of target expansion via user, RAG, or tool, target version and delegation, confirmation of lack of call to the target system
AI-IAM-LEASTPRIV3	Agent with MCP Gateway and tools	Separate tool identity, minimal permissions, backend verification	Backend, service account, and role mapping, spoofing test, tool matrix, secret IDs
AI-IAM-COMPROMISE1	Agent with MCP Gateway and tools	User, session, and tenant validation, delegation context	User/tenant spoofing and session revocation test, delegation record, token metadata (excluding secrets), revocation event
AI-AGENT-HITL1	Agent with MCP Gateway and tools	Actions with significant consequences, display of the target and parameters	Unconfirmed action test, post-confirmation parameter change, confirmation ID and hash, target system event
AI-MCP1	Agent with MCP Gateway and tools	Invocation, management, bindings, service account, target service	Gateway configuration, allowed and denied call, backend bypass, GET result and gateway bindings, complete tool specification, public access status, API key scope
AI-APP-INJECT2	Agent with MCP Gateway and tools	Verifiable sender, schema version, expiration, replay protection	Tests involving incorrect schemas, expired validity, duplicates, sender spoofing, sender identity and binding, schema and policy versions
AI-SUPPLY1	Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Source, author, date, version, conditions, checksum	Acceptance record, repeated retrieval and checksum comparison, source and internal hashes, quarantine test
AI-DATA-CHECK1	AI Search-powered RAG Own storage-powered RAG Training and experiments in DataSphere	Automatic and manual checks, quarantine, manual resolution	Test error set, link between the report and the input version, validator versions, confirmation of the object's absence from the index
AI-SUPPLY2	Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Source, checksums, format, loader, isolated execution	Package with the source, action monitoring during ingestion, configuration of the initial check environment
AI-SUPPLY3	Training and experiments in DataSphere Runtime on Compute Cloud with a self-hosted model	Application, source verification, integrity, behavioral tests, decision	Acceptance record, checksum spoofing test, acceptance package and its hash, confirmation or exclusion
AI-SUPPLY4	All container runtimes: Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	List of dependencies, vulnerability information, fix date	Image digest, latest scan results, release test, dependency report, redeployment event
AI-SUPPLY5	All container runtimes: Runtime in Managed Service for Kubernetes Runtime in Serverless Containers or Cloud Functions Runtime on Compute Cloud with a self-hosted model	SBOM or manifest, composition, checksums	Saved manifest, comparison with actual objects, manifest hash, component cards
AI-SUPPLY6	All profiles	Notification channels, procedure for identifying affected releases	Test notification, search for systems, restriction decision, affected release manifests, ticket
AI-COMPLY1	All profiles	Approved solution, coverage of all data types and recipients	Legal and compliance approach, scenario register, data flow diagram, flow IDs, trace example
AI-COMPLY2	All profiles	Lifecycle map, components, regions, copies, recipients	Flow map, component registry, resource inventory, unregistered copy test, resource exports, migration or deletion record
AI-COMPLY3	Calling an external model API from Yandex Cloud	Recipient, jurisdiction, endpoint, size, terms, timeframe	Recipient registry, gateway configuration, prohibited transmission test, secret ID, provider evidence, redirection test
AI-COMPLY4	Calling an external model API from Yandex Cloud	Decision by authorized representatives, comparison with resources and routes	Legal and compliance assessment, flow registry, architectural chart, solution IDs, unknown edge failure
AI-COMPLY-PII1	Any profile with a flow of adjustable data, e.g.: Managed inference via AI Studio Calling an external model API from Yandex Cloud	Detection and transformation up to the boundary, reversibility, safe behavior	Transformation policies, confidence boundary test, reverse transformation permissions, transformation type and version, residual field and unavailability tests
AI-COMPLY-PII4	Any profile with a flow of adjustable data, e.g.: Managed inference via AI Studio Training and experiments in DataSphere Calling an external model API from Yandex Cloud	Detection tools, versioning, test kits, monitoring	DSPM/DLP configuration, rule versions, quality assessment results, set management rules, detector versions
AI-COMPLY-PII3	Any profile with protective transformation of regulated data, e.g.: Managed inference via AI Studio Training and experiments in DataSphere Calling an external model API from Yandex Cloud	Minimal privileges, separation of duties, logging without personal data	IAM policies, transformation logs, fault-tolerance tests, event schema, unavailability and bypass tests

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

Tool	Verification target	Beyond the tool
Smart Web Security	Documented HTTP(S), WAF, and bot rules and rate limiting	Semantic prompt validation and document authorization
Guardrails	Moderation of supported input and output. This feature is at the Preview stage.	Response schema, IAM, masking, or legal framework
Audit Trails	Published events for selected services and operations	Full application tracing and undocumented data events
Cloud Logging	Receipt and storage of submitted records with configured access and retention periods	Universal removal of secrets or personal data from any application content
Monitoring	Metric, alert condition, and notification	Automatic shutdown of high-risk workloads
Container Registry vulnerability scanner	Docker image vulnerabilities within the scanner scope	Model behavior, weights, dataset, complete SBOM, and release provenance
DSPM	Detection of supported categories in connected sources	Source data transformation and legal approach
CIEM	Viewing direct, group, and inherited assignments, and revoking access within published limits. CIEM as a whole is at the Preview stage.	Determining which permission is excessive according to the organization's policy and ensuring the Preview feature's availability.
YCDR	Preview service signals after access approval, installation of a dedicated cloud collector, and source configuration. ycdr.admin is required to work with investigations.	Guaranteed telemetry availability and completeness

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.