[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 > Monitoring and incident response

# Monitoring and incident response

{#monitoring-incident-response}

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

## Signals and alerts {#signals-alerts}

### Atypical use of APIs and resources is detected {#atypical-api-resource-usage-detected}

{#ai-mon-anomaly2-id}

Requirement ID: `AI-MON-ANOMALY2`

{#ai-mon-anomaly2-requirement}

**Requirement**

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

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

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

{#ai-mon-anomaly2-implementation}

**Implementation**

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

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

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

{#ai-mon-anomaly2-check}

**Check**

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

{#ai-mon-anomaly2-artifacts}

**Artifact**

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

## End-to-end application trace {#end-to-end-trace}

### Model and agent request is traced without excess content {#model-agent-request-traced-no-excess-content}

{#ai-mon-trace1-id}

Requirement ID: `AI-MON-TRACE1`

{#ai-mon-trace1-requirement}

**Requirement**

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

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

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

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

{#ai-mon-trace1-check}

**Check**

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

{#ai-mon-trace1-artifacts}

**Artifact**

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

### Each agent loop iteration is linked to a task and an action {#agent-loop-iteration-linked-to-task-action}

{#ai-mon-trace2-id}

Requirement ID: `AI-MON-TRACE2`

{#ai-mon-trace2-applicability}

**Scope**

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

{#ai-mon-trace2-requirement}

**Requirement**

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

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

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

{#ai-mon-trace2-check}

**Check**

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

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

{#ai-mon-trace2-artifacts}

**Artifact**

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

## Preservation of investigation materials {#forensic-preservation}

### Dialog content archive has approved scope and controlled access {#dialog-archive-approved-scope-controlled-access}

{#ai-forensic2-id}

Requirement ID: `AI-FORENSIC2`

{#ai-forensic2-applicability}

**Scope**

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

{#ai-forensic2-requirement}

**Requirement**

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

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

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

{#ai-forensic2-check}

**Check**

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

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

{#ai-forensic2-artifacts}

**Artifact**

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

### Investigation materials are protected from tampering {#forensic-materials-protected-from-tampering}

{#ai-forensic3-id}

Requirement ID: `AI-FORENSIC3`

{#ai-forensic3-requirement}

**Requirement**

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

{#ai-forensic3-implementation}

**Implementation**

For a secure Audit Trails destination, you can use [audit log](../standard/audit-logs.md) based recommendations.

In Object Storage, versioning and [Object Lock](../../storage/concepts/object-lock.md) can support immutability if configured correctly, but indefinite lock hold and retention period require separate management.

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

{#ai-forensic3-check}

**Check**

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

{#ai-forensic3-artifacts}

**Artifact**

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

## Response procedure {#response-procedure}

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

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

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