Yandex Cloud explains how to deploy AI agents in security without false lockouts and outages

Yandex Cloud has examined how AI agents can relieve pressure on a SOC, and where they become dangerous without limits. In the good scenario, the agent quickly gathers context and hands the decision to an analyst. In the bad one, it wrongly isolates a domain controller because of a false event correlation. The conclusion is simple: AI is needed in information security, but only with guardrails, an abstain policy and human-in-the-loop.

AI-processed from Habr AI; edited by Hamidun News
Yandex Cloud explains how to deploy AI agents in security without false lockouts and outages
Source: Habr AI. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceHabr AI ↗
Editor-in-Chief
Key metric #1input filtering and protection against prompt injection
Key metric #2RAG with an up-to-date knowledge base, RBAC, reranking and conflict checking
Reasoning firewalla supervisor, task decomposition, cross-checking and confidence estimation

Yandex Cloud has described how AI agents can become useful helpers for a SOC, but should not be given the right to take critical actions without human oversight. In a write-up on Habr, the team presented two scenarios: in one, the agent saves an analyst tens of minutes; in the other, it wrongly isolates a domain controller and halts the company's operations.

Why the SOC is overloaded

A modern SOC lives in constant noise: a single analyst can face up to 1000 alerts a day, and up to 95% of them turn out to be false positives. Against that backdrop, handing initial triage and correlation to AI looks almost inevitable. An agent can quickly parse logs, decode commands, pull context from the SIEM and map events to MITRE ATT&CK. Where a human spends tens of minutes of focused work, a model can produce a draft answer in seconds.

But Yandex Cloud warns that the potential for automation is higher than the real reliability of such systems. The author cites a March Anthropic study in which, for computer science and mathematics occupations, theoretical task automation reaches 94%, while observed automation is only about 33%. That gap shows the key point: AI is already useful, but it cannot be treated as a mature, autonomous employee. This is especially true in information security, where a misread event can cost more than a false alert: it can shut down key services.

Where the agent goes wrong

The article's central example is built around an alert on the domain controller DC01. In the safe scenario, the agent receives a signal about a suspicious PowerShell launch, decodes the Base64 command, recognizes that it enumerates members of Domain Admins, and links this to a privilege reconnaissance technique. It then checks internal policies, notes that DC01 belongs to Tier-0, collects additional events only within a narrow time window, and, instead of acting automatically, produces a report for the SOC analyst that requires mandatory HITL confirmation.

In the bad scenario, things break not at input but in reasoning. The agent correlates events too coarsely, by time and host rather than by session identifiers and process chain. As a result, it ties an unrelated DNS request to the PowerShell activity, interprets the picture as C2 or exfiltration, and decides to isolate DC01. For a domain controller, that is a disaster: Kerberos and LDAP go down, dependent services stop, and the business suffers downtime because of a model's false conclusion.

"We have to accept that models hallucinate and can make mistakes," writes

Sergey Nesteruk.

What guardrails are needed

The article's main idea is that the goal is not to eliminate the possibility of hallucination but to contain the consequences of an error. An LLM does not handle truth the way an analyst does, and under uncertainty it is more likely to guess than to honestly say "I don't know." So a trustworthy AI agent in security is not a single model but a set of external constraints around it: input validation, memory control, strict tool permissions, audit, and a layer of human approval wherever the cost of error is too high.

  • input filtering and protection against prompt injection
  • RAG with an up-to-date knowledge base, RBAC, reranking and conflict checking
  • reasoning firewall: a supervisor, task decomposition, cross-checking and confidence estimation
  • restricted actions on Tier-0, an abstain policy and mandatory human-in-the-loop

Yandex Cloud recommends rolling out such systems in stages. As a practical reference, the team uses AI-SAFE, a threat-modeling framework for agentic systems with five layers: user input, context orchestration, model reasoning, tools and knowledge bases. First comes an assistant that looks up data, gathers context and reduces the cognitive load on the team. Then partial automation with human confirmation. Only after logs, quality metrics, well-understood failure scenarios and stable operation have accumulated can the agent be given broader authority.

What this means

The market is moving toward AI becoming the norm in the SOC, but the winners will not be those who put an agent into production first. They will be those who wrap it in guardrails and leave the final decision at critical points to a human. For companies, this is a useful guide: routine work can already be automated, but trust cannot yet be.

Story

Key Questions Answered

Why the SOC is overloaded?

A modern SOC lives in constant noise: a single analyst can face up to 1000 alerts a day, and up to 95% of them turn out to be false positives. Against that backdrop, handing initial triage and correlation to AI looks almost inevitable. An agent can quickly parse logs, decode commands, pull context from the SIEM and map events to MITRE ATT&CK. Where a human spends tens of minutes of focused work, a model can produce a draft answer in seconds. But Yandex Cloud warns that the potential for automation is higher than the real reliability of such systems. The author cites a March

Where the agent goes wrong?

The article's central example is built around an alert on the domain controller DC01. In the safe scenario, the agent receives a signal about a suspicious PowerShell launch, decodes the Base64 command, recognizes that it enumerates members of Domain Admins, and links this to a privilege reconnaissance technique. It then checks internal policies, notes that DC01 belongs to Tier-0, collects additional events only within a narrow time window, and, instead of acting automatically, produces a report for the SOC analyst that requires mandatory HITL confirmation. In the bad scenar

What guardrails are needed?

The article's main idea is that the goal is not to eliminate the possibility of hallucination but to contain the consequences of an error. An LLM does not handle truth the way an analyst does, and under uncertainty it is more likely to guess than to honestly say "I don't know." So a trustworthy AI agent in security is not a single model but a set of external constraints around it: input validation, memory control, strict tool permissions, audit, and a layer of human approval wherever the cost of error is too high. input filtering and protection against prompt injection RAG

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
What do you think?
Loading comments…