Система, которую называют автономной, сначала старается не показывать языковой модели большую часть свидетельств.

Система, которую называют автономной, сначала старается не показывать языковой модели большую часть свидетельств.

В предлагаемой архитектуре данные поступают в Splunk, затем проходят через автоэнкодер, оценивающий аномальность, и политику на основе глубокого обучения с подкреплением. Только потоки с высоким приоритетом передаются большой языковой модели для контекстного анализа. Причина сформулирована прямо: так авторы хотят снизить вычислительную нагрузку и риск галлюцинаций. (Rishikesh Sahay и др., март 2026, [arXiv](https://arxiv.org/html/2603.23966v1))

На рекламном уровне это похоже на цифрового аналитика SOC: он принимает поток событий, решает, что важно, строит запросы к Splunk, сопоставляет активность с MITRE ATT&CK и предлагает дальнейшие действия. На уровне схемы порядок другой. Первое решение принимает не LLM.

Это различие определяет весь разговор об автономности. В исследовательском пакете есть препринты, документация и материалы поставщика, но нет названных инцидентов из работающих корпоративных SOC. Поэтому ниже речь пойдёт о конструкции, заявленных результатах и её ограничениях, а не о выдуманных историях взломов.

Сначала была проблема перегруза

Операционный центр безопасности редко страдает от недостатка событий. Он страдает от их избытка.

Авторы фреймворка связывают его появление с двумя обстоятельствами: постоянным изменением продвинутых устойчивых угроз и огромным объёмом журналов от множества устройств. В такой среде аналитики должны одновременно замечать необычное, проверять гипотезы и не утонуть в повторяющихся действиях. (Sahay и др., март 2026, [arXiv](https://arxiv.org/abs/2603.23966))

Threat hunting в классическом смысле — не просто автоматический разбор предупреждений. Splunk описывает его как работу, которая должна создавать «гипотезы, проактивные и воспроизводимые процессы». Аналитик заранее формулирует, что ищет, проверяет это гибкими запросами и сравнивает поведение с базовыми линиями. ([Splunk Threat Hunting](https://www.splunk.com/en_us/solutions/threat-hunting.html), 2026)

Splunk удобен для такого подхода, потому что собирает журналы в одном месте и позволяет строить поисковые запросы, поведенческие профили и проверки. Но единое хранилище не уменьшает автоматически сложность материала. Оно делает доступным ещё больше данных, которые нужно правильно нормализовать, сопоставить и истолковать. ([Splunk Threat Hunting](https://www.splunk.com/en_us/solutions/threat-hunting.html), 2026)

Отсюда возникла привлекательная мысль: если аналитик не справляется с потоком, его можно заменить моделью, работающей на машинной скорости. Она классифицирует события, сама составляет SPL-запросы, пересказывает контекст и оставляет человеку только вывод.

Это объяснение кажется почти очевидным.

«Интеграция LLM в рабочий процесс SIEM может автоматизировать анализ»

Но ускорение анализа и повышение качества обнаружения — разные вещи. Быстрый неверный запрос остаётся неверным запросом.

Что происходит до разговора с моделью

Посмотрим не на интерфейс, а на последовательность решений.

Splunk принимает и приводит телеметрию к рабочему виду. Автоэнкодер реконструирует наблюдаемые данные и оценивает, насколько исходный паттерн отличается от того, что система способна восстановить. Затем двухслойная политика на основе глубокого обучения с подкреплением занимается первичной сортировкой и приоритизацией. Только после этих этапов выбранный поток попадает к LLM. (Sahay и др., март 2026, [полный текст arXiv](https://arxiv.org/html/2603.23966v1); [PDF версии 2](https://arxiv.org/pdf/2603.23966v2.pdf))

У каждого звена свой вопрос. Автоэнкодер спрашивает: «Что выглядит необычно?» Политика решает: «Что заслуживает внимания раньше другого?» Языковая модель получает более узкую задачу: «Как это можно объяснить и исследовать?» Самое consequential решение, таким образом, возникает до появления связного текста.

Это не обязательно слабость. Ограничение доступа к событиям снижает расходы на вычисления и уменьшает число случаев, когда модель может уверенно сочинить объяснение для шума. Авторы прямо связывают передачу только высокоприоритетных потоков с попыткой избежать лишней нагрузки и галлюцинаций. (Sahay и др., март 2026, [полный текст arXiv](https://arxiv.org/html/2603.23966v1))

Однако есть и более скептическое чтение. Если именно автоэнкодер и политика решают, какие события вообще увидит LLM, то заявленная «интеллектуальность» системы может в значительной степени исходить из классического машинного обучения и настройки политики. LLM тогда отвечает за объяснение, обогащение контекста и подготовку следующего шага, но не за первичное обнаружение.

Это уже интерпретация: пакет подтверждает порядок компонентов, а вывод о том, где находится основная аналитическая ценность, остаётся гипотезой. Проверить его можно только сравнением: что даёт одна политика без LLM, что даёт LLM без неё и как меняются пропущенные угрозы.

Сам механизм здесь прост. Телеметрия сужается в несколько проходов: сначала система отбрасывает то, что не выглядит необычным, затем поднимает наверх то, что считает приоритетным, потом просит модель объяснить выбранное и возвращает её запросы в Splunk для проверки. (Sahay и др., март 2026, [PDF версии 2](https://arxiv.org/pdf/2603.23966v2.pdf))

Каждый фильтр экономит ресурсы. Каждый фильтр также может скрыть событие.

Почему простая теория так убедительна

У сторонников LLM есть сильный аргумент: SOC не может ждать идеальной автоматизации, пока атаки и объём данных растут.

В материалах Splunk языковая модель выступает как поздний слой предварительной классификации. Поставщик сообщает, что такая схема способна сократить время первоначальной классификации «до 99%». Это важная цифра для очереди аналитика, но она измеряет скорость рабочего процесса, а не полноту обнаружения или устойчивость к обману. ([Splunk Security Research, апрель 2025](https://www.splunk.com/en_us/blog/security/defending-machine-speed-threat-hunting-open-weight-llms.html))

В той же линии находятся задачи по классификации PowerShell. Splunk сообщал примерно о восьми процентных пунктах прироста точности и шести — прироста правильности при добавлении контекста безопасности. Но речь шла о конкретной задаче и условиях, а не о доказательстве превосходства во всех видах охоты за угрозами. ([Splunk Security Research, апрель 2025](https://www.splunk.com/en_us/blog/security/defending-machine-speed-threat-hunting-open-weight-llms.html))

Быстрее обработать очередь — уже полезный результат. Во время всплеска предупреждений он может освободить внимание человека для сложных расследований. Нельзя требовать от каждого инструмента сразу доказать, что он самостоятельно обнаруживает неизвестные атаки.

Так выглядит лучший аргумент в пользу системы. Её ценность может заключаться не в замене аналитика, а в том, что она распределяет его внимание и сокращает механическую часть работы. Сложная оркестрация не становится бесполезной лишь потому, что её нельзя честно назвать автономным аналитиком.

Но у этой позиции есть условие. Снижение времени классификации должно сопровождаться проверкой качества: сколько угроз пропущено, сколько событий ошибочно поднято наверх, как часто запросы модели обращаются не к тем данным и что происходит при изменении телеметрии.

Иначе измеряется удобство, а не безопасность.

Момент, когда слово «автономный» начинает мешать

«Театр автономии» — это система, в которой видимая интеллектуальность создаётся разговорным интерфейсом, а надёжные полномочия распределены между оценкой риска, политиками, проверочными запросами и человеком. В ней модель объясняет и предлагает, но не получает полного права решать, что расследовать и какие действия разрешены.

«Мы предлагаем автоматизированную и динамическую систему охоты за угрозами»

«Интегрируя агентный искусственный интеллект с устоявшейся SIEM-платформой Splunk, мы разработали уникальную систему охоты за угрозами»

— в связке, где политики выделяют внимание, а Splunk остаётся местом, возвращающим предложение модели к данным.

«кто выбирает события, которые аналитик и LLM вообще увидят?»

Под этой оптикой ограничения перестают быть досадными оговорками вокруг искусственного интеллекта. Они становятся условием его использования. Автоэнкодер, политика приоритетов, нормализация телеметрии и проверка SPL — не закулисные детали, а распределённая система полномочий. LLM делает её понятной и удобной для разговора, но не является единственным источником решения.

Термин полезен именно потому, что возвращает скрытую инженерию в кадр. Автономность здесь не исчезает полностью, но становится постановкой: система показывает самостоятельное рассуждение, хотя её надёжность зависит от заранее заданных границ.

Цена красивого объяснения

После такого поворота особенно важным становится не текст отчёта, а качество ворот, через которые событие прошло.

Если автоэнкодер плохо описывает нормальное поведение, а политика неверно расставляет приоритеты, LLM не получит шанс исправить первичную ошибку. Она сможет убедительно объяснить только отобранный материал. Это следует из самой последовательности, описанной в препринте: контекстный анализ начинается после аномального и приоритетного отбора. (Sahay и др., март 2026, [полный текст arXiv](https://arxiv.org/html/2603.23966v1))

Другая проблема возникает на следующем шаге. Модель может создавать контекстные резюме, сопоставления с MITRE ATT&CK и SPL-запросы, после чего Splunk возвращает результаты для проверки аналитиком. Такая схема разумнее безусловного исполнения, но она превращает правильность запроса в отдельную точку отказа. (Sahay и др., март 2026, [PDF версии 2](https://arxiv.org/pdf/2603.23966v2.pdf))

Исследование об использовании LLM неспециалистами в threat hunting даёт здесь неприятную проверку реальностью. Авторы сообщали, что сгенерированные запросы часто оказывались неуспешными: ошибки касались синтаксиса, индексов, таблиц и источников данных. В эксперименте запросы Splunk не дали успешных результатов. ([Leveraging LLMs for Non-Security Experts in Threat Hunting](https://pdfs.semanticscholar.org/b760/f9d59a1204e6d785afc7e72a87807bbff4ae.pdf), 2025)

Причина важна. Запрос к SIEM — не универсальная фраза на естественном языке. Он зависит от того, как конкретная организация называет поля, где хранит события и какие источники действительно подключены. Ошибка в такой детали может выглядеть как отсутствие подозрительной активности.

В этом месте узкая лабораторная схема сталкивается с неоднородной корпоративной средой. Препринт описывает тщательно собранную цепочку от оценки аномальности к политике, а затем к LLM; независимая работа показывает, насколько чувствительными бывают модели к платформенным и источниковым предположениям. Переносимость такой конструкции на другую телеметрию нельзя считать само собой разумеющейся. (Sahay и др., март 2026, [PDF версии 2](https://arxiv.org/pdf/2603.23966v2.pdf); [Leveraging LLMs for Non-Security Experts in Threat Hunting](https://pdfs.semanticscholar.org/b760/f9d59a1204e6d785afc7e72a87807bbff4ae.pdf), 2025)

Человек в контуре помогает, но не превращает систему в безопасную автоматически. Убедительное резюме может создать избыточное доверие, а сама LLM-связка имеет собственные угрозы: внедрение инструкций в запрос, небезопасную обработку вывода, раскрытие чувствительных данных и чрезмерно широкие полномочия. ([Splunk и OWASP, 2024](https://www.splunk.com/en_us/blog/security/llm-defense-owasp-top-10.html))

Проверка нужна не потому, что человек всегда лучше модели. Она нужна потому, что модель и SIEM видят разные части ошибки.

Три материала, три разных обещания

Первый артефакт — сам препринт *Policy-Guided Threat Hunting: An LLM enabled Framework with Splunk SOC Triage*. Его наиболее важная деталь — не наличие LLM, а порядок: автоэнкодер, двухслойная политика глубокого обучения с подкреплением, затем анализ моделью только высокоприоритетных потоков. Это пример системы, где внимание сначала распределяется правилами и оценками риска, а уже потом получает языковое оформление. (Sahay и др., март 2026, [полный текст arXiv](https://arxiv.org/html/2603.23966v1))

Второй материал — публикация Splunk об ускоренной охоте за угрозами с открытыми LLM. В ней заявлено сокращение времени первоначальной классификации до 99%; для узкой задачи классификации PowerShell приводятся примерно восемь процентных пунктов прироста точности и шесть пунктов прироста правильности при добавлении контекста безопасности. Это убедительный довод в пользу производительности и гораздо более осторожный довод в пользу качества обнаружения. ([Splunk Security Research, апрель 2025](https://www.splunk.com/en_us/blog/security/defending-machine-speed-threat-hunting-open-weight-llms.html))

Третий — исследование *Leveraging LLMs for Non-Security Experts in Threat Hunting*. Оно показывает обратную сторону обещания «модель сама напишет расследование»: запросы сталкивались с синтаксическими ошибками и неправильными предположениями об индексах, таблицах и источниках. В этой работе LLM предстаёт не автономным охотником, а хрупким помощником, которому нужны знания платформы и экспертная проверка. ([Leveraging LLMs for Non-Security Experts in Threat Hunting](https://pdfs.semanticscholar.org/b760/f9d59a1204e6d785afc7e72a87807bbff4ae.pdf), 2025)

Эти материалы нельзя смешивать. Первый описывает архитектуру. Второй показывает заявленный выигрыш в скорости на конкретных задачах. Третий ограничивает ожидания от генерации запросов. Ни один из них не является названным случаем успешного предотвращения реальной корпоративной атаки.

Их общая картина всё же ясна. LLM может ускорить передачу контекста человеку, но при этом политика решает, на что будет потрачено внимание, а SIEM проверяет, соответствует ли предложенный запрос данным.

Что остаётся от автономности

Самый сильный контраргумент не требует защищать громкое слово «автономный». Даже если LLM не является главным детектором, она может быть полезным слоем в сложном процессе: сокращать очередь, собирать контекст и помогать аналитику начинать расследование с более содержательной точки. (Sahay и др., март 2026, [полный текст arXiv](https://arxiv.org/html/2603.23966v1))

Но тогда успех нужно связывать с калибровкой порогов, качеством телеметрии, проверкой запросов под конкретную платформу и числом пропущенных угроз. Скорость сама по себе не отвечает ни на один из этих вопросов. Исследование неудачных SPL-запросов делает это условие практическим, а не риторическим. ([Leveraging LLMs for Non-Security Experts in Threat Hunting](https://pdfs.semanticscholar.org/b760/f9d59a1204e6d785afc7e72a87807bbff4ae.pdf), 2025)

Человеческая проверка сохраняет ответственность, но её недостаточно просто пообещать. Её нужно строить вокруг явных полномочий, видимых исходных данных и запрета на опасные автоматические действия. Иначе внедрение инструкций или ошибочный вывод модели могут пройти дальше, чем предполагал разработчик. ([Splunk и OWASP, 2024](https://www.splunk.com/en_us/blog/security/llm-defense-owasp-top-10.html))

Как проверять следующий «автономный» SOC

Начинать стоит не с демонстрации чата. Нужно попросить показать ворота.

Какая система выбирает события? Где задаются пороги? Кто может изменить приоритет? Что происходит с потоком, который автоэнкодер признал обычным? Какие данные доступны LLM, а какие она никогда не видит? Ответы на эти вопросы раскрывают реальную архитектуру лучше, чем описание модели.

Затем нужно проверить полномочия. Модель предлагает SPL-запрос или запускает его сама? Splunk только возвращает результаты или также подтверждает корректность источника, индекса и таблицы? Какие действия требуют одобрения аналитика? Такой аудит отделяет помощника от агента, которому фактически передали управление.

Наконец, следует требовать метрики не только скорости. Сокращение классификации на 99% важно для пропускной способности, но его нужно сопоставлять с ложными отрицаниями, ошибочными приоритетами, устойчивостью к изменению данных и качеством решений аналитика. Заявленный результат на PowerShell не следует автоматически распространять на охоту за угрозами в целом. ([Splunk Security Research, апрель 2025](https://www.splunk.com/en_us/blog/security/defending-machine-speed-threat-hunting-open-weight-llms.html))

Парадокс этой архитектуры в том, что она сильнее именно там, где не позволяет модели действовать свободно. Её наиболее правдоподобное описание — управляемый политиками помощник и конвейер распределения риска, а не самостоятельный аналитик SOC.

Следующее поколение защитных систем будут оценивать не по тому, насколько автономно они звучат. Его будут оценивать по тому, насколько честно они показывают механизм театра автономии.