Security check and security testing

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

Check scope preparationCheck scope preparation

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

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

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

Single requirement check procedureSingle requirement check procedure

The reviewer performs the following actions:

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

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

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

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

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

Configuration and IAM checkConfiguration and IAM check

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

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

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

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

Log and telemetry checkLog and telemetry check

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

The minimum result record contains:

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

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

Secure negative and application testsSecure negative and application tests

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

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

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

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

Red teamingRed teaming

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

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

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

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

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

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

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

The final check package must contain:

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

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