С 5 часов до 7 минут. Это не маркетинговый слоган — это реальная цифра из кейса eSentire, которые натравили AI-агента на анализ киберугроз и получили ускорение в 43 раза. Валидировали на тысяче реальных расследований. 95% совпадение с решениями старших аналитиков SOC. Я наткнулся на этот кейс, когда изучал AI-агентов в продакшене, и он зацепил не громкими числами, а тем, как именно они это построили.
Потому что архитектура — это не «подключили ChatGPT к логам». Полноценный агент, который формулирует гипотезы, выбирает инструменты, собирает доказательства и сам себя проверяет. Воспроизвели логику старшего аналитика, который расследует инцидент. Только аналитик делает это за смену, а агент — за семь минут.
AI-агент в кибербезопасности — это не чат-бот, который отвечает на вопросы про фишинг. Это автономная система, которая сама ведёт расследование: собирает улики, строит картину атаки, оценивает риски, предлагает решение. Человек подключается на финальном этапе, чтобы проверить выводы и нажать кнопку.
Зачем eSentire понадобился AI-агент для анализа угроз
eSentire — это Managed Detection and Response (MDR). Они мониторят безопасность для 2000+ организаций в 80+ странах, 35 отраслей. Когда прилетает алерт — «на такой-то машине подозрительная активность» — старший аналитик SOC садится и разбирается: реальная атака или ложное срабатывание. Смотрит телеметрию с эндпоинтов, сетевой трафик, логи, облачные среды, данные об уязвимостях. Каждое расследование — это детективная работа: собрать улики из десятка источников, сложить картину и принять решение.
Проблема: таких алертов — тысячи в день. Экспертный анализ каждого занимал до 5 часов. Старших аналитиков не наберёшься на такой объём. Джуниоры не тянут — не хватает опыта, чтобы собрать разрозненные сигналы в целостную картину.
Знакомая боль для любого SOC. AI тут помогает ровно так: берёт на себя рутину, которая съедает часы экспертного времени. Полностью заменить аналитика? Нет, финальное решение остаётся за человеком. Но автоматизировать разбор алертов, на который уходит 90% рабочего дня, вполне реально. eSentire это доказали не на презентации, а на боевых данных.
Инфо
SOC (Security Operations Center) — это команда, которая 24/7 мониторит кибербезопасность. Аналитики разбирают алерты, расследуют инциденты и принимают решения: блокировать, эскалировать или закрыть как ложное срабатывание.
Архитектура: Claude + Amazon Bedrock + LangGraph
Вот где становится интересно для тех, кто строит свои агентные системы.
Стек: Claude Sonnet через Amazon Bedrock, агентная оркестрация на LangGraph, всё это интегрировано в Atlas XDR Platform — собственную платформу eSentire для обнаружения угроз. Данные приходят отовсюду: endpoint telemetry, сетевой трафик, логи, облачные среды, identity-системы, фиды уязвимостей. Агент работает со всем этим одновременно.
Агент работает циклом. Получает алерт → формулирует гипотезу («это может быть lateral movement после компрометации учётных данных») → динамически выбирает инструменты для проверки → собирает доказательства → оценивает результат → корректирует гипотезу → повторяет. И так до тех пор, пока не достигнет уверенного заключения.
Это классический контекст-инжиниринг в промптах: модель не просто получает данные на вход, а сама решает, какие данные ей нужны, в каком порядке их собирать и как интерпретировать. Claude тут выбрали именно за reasoning. Управление мышлением модели позволяет агенту выстраивать цепочки рассуждений, а не просто классифицировать алерты.
Отдельно цепляет деталь про выбор модели. Команда eSentire начинала с open-source. Не хватило reasoning-возможностей: агент не мог выстроить многоступенчатое расследование, терялся на втором-третьем шаге. Перешли на Claude Sonnet 3.5, потом 3.7, сейчас на четвёрке. Каждое обновление модели давало ощутимый прирост качества.
Совет
Если строите своего AI-агента — не начинайте с самой дешёвой модели. eSentire потратили время на open-source, поняли, что reasoning слабый, и перешли на Claude. Для задач, где нужно многоступенчатое рассуждение, экономия на модели выходит боком.
С 5 часов до 7 минут — как AI ускорил расследование угроз в 43 раза
Теперь к цифрам.
До внедрения: экспертный анализ одного инцидента занимал до 5 часов. Вдумчивая работа: просмотр телеметрии, корреляция событий из разных источников, проверка гипотез, документирование. После: 7 минут. Агент делает всё то же самое, только быстро и без перерывов на кофе.
Меня тут больше всего впечатлило не само ускорение, понятно, что автоматизация быстрее ручной работы. Впечатлило, что качество при этом не просело (про это ниже). И ещё: циклы разработки самой системы сжались с месяцев до дней. Появляется новый тип атаки — команда адаптирует агента за дни, а не месяцы. Для кибербезопасности, где угрозы меняются постоянно, это критично.
За счёт чего скорость? Агент не ждёт, пока человек решит, что проверять дальше. Сам формулирует следующий шаг, вызывает нужный инструмент, получает данные и тут же анализирует. Параллелит там, где аналитик действовал бы последовательно. Человек смотрит лог, потом идёт проверять сетевой трафик, потом возвращается к логу, потом пьёт кофе, потом вспоминает, что забыл проверить identity-систему. Агент проходит тот же путь, но без пауз и без кофе. Семь минут — не потому что задача простая. Просто нет простоев между шагами.
95% точность на тысяче реальных расследований
Скорость без точности — ерунда. Если агент быстро принимает неправильные решения, он опаснее, чем медленный аналитик.
eSentire валидировали агента на 1000 реальных кейсах. Результат: 95% совпадение с решениями старших экспертов SOC. Не джуниоров — старших. Тех самых, которых не хватает и которые стоят дорого.
Пять процентов расхождений — не ошибки в чистом виде. Часть из них — случаи, где агент перестраховался. В кибербезопасности лучше лишний раз дёрнуть аналитика, чем пропустить реальную атаку. Часть — действительно сложные кейсы, где нужен контекст, которого у агента нет: переговоры с клиентом, специфика конкретной организации, интуиция, наработанная годами. Такие кейсы всё равно уходят к старшим аналитикам, но теперь вместо тысячи расследований в день им остаётся разобрать пятьдесят.
Ещё одна цифра: 99.3% угроз остановлены на первой машине. Containment rate — процент атак, которые не вышли за пределы первого заражённого узла. Если атакующий проник на один компьютер и начинает двигаться по сети (lateral movement), каждая минута промедления — это ещё несколько скомпрометированных машин. Одна непроверенная рабочая станция может превратиться в полноценный breach с утечкой данных, шифрованием и выкупом. Когда агент реагирует за минуты вместо часов, атака просто не успевает распространиться.
Внимание
95% точность не означает, что человек больше не нужен. eSentire используют агента как первую линию: он делает анализ, а аналитик проверяет выводы. AI ускоряет работу, но не принимает финальное решение на блокировку в одиночку.
Почему Claude, а не GPT и не open-source
Вопрос, который мне был интересен больше всего: почему именно Claude?
eSentire перебрали несколько вариантов. Сначала open-source модели — не хватило reasoning. Агент должен выстраивать цепочку из десятков шагов: гипотеза → проверка → уточнение → новая гипотеза. Open-source модели теряли нить на третьем-четвёртом шаге.
Amazon Bedrock выбрали из-за enterprise-требований: compliance, масштабируемость, интеграция с существующей AWS-инфраструктурой, SLA. Для компании, которая мониторит безопасность двух тысяч организаций, «упало на час» не вариант. А Claude Sonnet — за соотношение качества reasoning и стоимости. Opus слишком дорогой, если гонять тысячи алертов в день. Haiku недостаточно умный для многоступенчатых расследований. Sonnet попал в точку: хватает мозгов вести расследование и хватает скорости делать это тысячи раз в сутки.
Интересная деталь: команда прошла через три версии Claude — 3.5 Sonnet, 3.7, четвёрка. По словам eSentire, разница между 3.5 и 4 в качестве расследований заметная. Четвёрка стала лучше удерживать контекст длинных цепочек и реже «забывала», что проверяла тремя шагами ранее.
Вот так Claude используется в enterprise. Не в режиме «спроси-ответь», а как движок внутри автономной системы на тысячи запросов в сутки.
Что можно взять себе из этого кейса
Окей, мы не строим SOC. Аудитория блога — AI-энтузиасты, а не безопасники. Но архитектурные принципы тут универсальные. Вот что я выписал для себя.
Главное — цикл «гипотеза, проверка, коррекция». Не давайте агенту задачу «проанализируй всё». Пусть сначала сформулирует предположение, потом проверит его конкретным инструментом, потом скорректирует. Этот цикл работает одинаково хорошо что в анализе угроз, что в генерации контента.
Второе — динамический выбор инструментов. Агент eSentire сам решает, какой инструмент использовать на каждом шаге. Не жёсткий pipeline «шаг 1, шаг 2, шаг 3», а гибкая логика. Тот же принцип работает в команде AI-агентов для разработки: агент сам выбирает, когда читать код, когда писать, когда тестировать.
Про выбор модели я уже говорил выше, но повторю: начинайте с сильной. eSentire потратили время на open-source и вернулись к Claude. Если задача требует reasoning на 10+ шагов, берите лучшую модель, какую можете позволить. Оптимизировать стоимость будете потом.
И обязательно валидируйте на реальных данных. Тысяча кейсов, сравнение с экспертами — а не «попробовали на пяти примерах и выглядит нормально». Если ваш агент принимает решения с последствиями, валидируйте жёстко.
Для оркестрации eSentire используют LangGraph. Если ваш агент сложнее одного вызова API — посмотрите в сторону фреймворков. LangGraph, CrewAI, AutoGen. LangGraph сейчас выглядит зрелее остальных для production-нагрузок, но выбор есть.
Ну и не путайте скорость с качеством. 43x — красивая цифра, но eSentire сначала добились 95% точности, а потом оптимизировали скорость. Быстрый агент, который ошибается в каждом пятом случае — это не автоматизация, это генератор проблем.
43x ускорение, 95% точность, 99.3% угроз на первой машине. Цифры красивые. Но для меня главный вывод другой: enterprise уже строит агентов, которые реально работают в проде. Не демки, не прототипы — боевые системы на тысячах инцидентов в день.
Гипотетико-дедуктивный цикл, динамические инструменты, сильная модель, жёсткая валидация — это не рецепт конкретно для SOC. Это рецепт для любого агента, который принимает решения с последствиями. Паттерн один, домен — на ваш выбор.
Источники: AWS Case Study, Anthropic Customer Story, eSentire Blog, VentureBeat.
