Что изменилось
Рынок security automation быстро двигается от простых сканеров к системам, где модель помогает выбирать проверки, объяснять evidence и приоритизировать исправления.
Проблема в том, что LLM одинаково уверенно описывает безопасную read-only проверку и технику, которая должна требовать письменного approval или быть полностью запрещена.
Поэтому AI-план нельзя исполнять напрямую: его нужно воспринимать как гипотезу, а не как команду.
Какой предохранитель нужен
Первый слой — классификация intent: read-only, approval-required, forbidden.
Второй слой — scope enforcement: домен, DNS, IP и egress не должны выходить за подтверждённую цель.
Третий слой — allowlisted catalog: модель может предложить только известные техники, для которых есть безопасный validator.
Четвёртый слой — evidence-first: finding появляется только после воспроизводимого подтверждения, а не после красивого текста модели.
Что считается запрещённым
К destructive/forbidden категории относятся DoS, flood, credential abuse, persistence, stealth/evasion, shell payloads, exfiltration, keylogging, destructive changes и техники вне заявленного продуктового scope.
Такие сигналы должны блокироваться ещё до validator-а, даже если модель пытается завернуть их в якобы полезный pentest-контекст.
High-risk methodology без каталога и approval должна попадать в human review, а не превращаться в автоматическое действие.
Практический вывод
Хорошая security-платформа продаёт не автономную атаку, а управляемую проверку: scope, policy, evidence, QA и remediation.
LLM полезна как аналитик и критик отчёта, но её план должен быть структурированным JSON, редактированным от секретов и проверенным policy engine.
Это снижает false positives, юридический риск и вероятность того, что автоматизация сделает больше, чем разрешено.