Forwarded from white2hack 📚
SOC PLAYBOOK 2026 ATTACKER STEPS.pdf
1.7 MB
SOC PLAYBOOK 2026 ATTACKER STEPS (WHAT THEY DO) AND DEFENDER STEPS
Forwarded from Похек AI (Сергей Зыбнев)
ADLC: жизненный цикл разработки для AI-агентов
ADLC — Agentic Development Lifecycle, подход к разработке систем с AI-агентами. Главная мысль простая: классический SDLC хорошо работает там, где поведение продукта можно заранее описать, реализовать и проверить через понятные pass/fail тесты. С агентами так получается не всегда. Изначально идей для поста послужило это видео.
Поведение агента зависит от промпта, контекста, выбранной модели, памяти, доступных инструментов и состояния внешней среды. Один и тот же запрос может привести к разным траекториям действий, поэтому «написали код, прогнали тесты, выкатили» быстро становится слабой моделью управления.
ADLC предлагает начинать не с разработки, а с гипотезы: какой реальный рабочий процесс ломается, какую ручную работу агент должен забрать, где остаётся человек и по каким метрикам понятно, что система полезна. Дальше идут границы задачи, архитектура, выбор агентного паттерна, источники данных, интеграции, управление контекстом и оценка стоимости.
Самая практичная часть — proof of value до полноценной разработки. Нужны эталонные данные, прототип, оценка точности, качества ответа, частоты галлюцинаций, задержки и стоимости результата. Иначе легко построить дорогого агента, который красиво демонстрируется, но плохо живёт в реальном процессе.
Для Claude Code это особенно показательно: по документации Anthropic, инструмент читает кодовую базу, правит файлы, запускает команды, работает с dev-инструментами и может действовать на уровне проекта. Значит, оценивать нужно весь контур, а не один финальный diff: reasoning, tool use, безопасность, права доступа, контроль стоимости и качество обратной связи.
Вывод: agentic-разработка требует отдельного цикла управления. Сначала формулируем поведение и границы ответственности, затем доказываем ценность на данных, строим eval-систему, выкатываем через controlled rollout и продолжаем мониторить качество после релиза. Для агентов maintenance — это постоянный feedback loop, а не редкий проверка после деплоя.
🌚 @poxek_ai / Чат канала
ADLC — Agentic Development Lifecycle, подход к разработке систем с AI-агентами. Главная мысль простая: классический SDLC хорошо работает там, где поведение продукта можно заранее описать, реализовать и проверить через понятные pass/fail тесты. С агентами так получается не всегда. Изначально идей для поста послужило это видео.
Поведение агента зависит от промпта, контекста, выбранной модели, памяти, доступных инструментов и состояния внешней среды. Один и тот же запрос может привести к разным траекториям действий, поэтому «написали код, прогнали тесты, выкатили» быстро становится слабой моделью управления.
ADLC предлагает начинать не с разработки, а с гипотезы: какой реальный рабочий процесс ломается, какую ручную работу агент должен забрать, где остаётся человек и по каким метрикам понятно, что система полезна. Дальше идут границы задачи, архитектура, выбор агентного паттерна, источники данных, интеграции, управление контекстом и оценка стоимости.
Самая практичная часть — proof of value до полноценной разработки. Нужны эталонные данные, прототип, оценка точности, качества ответа, частоты галлюцинаций, задержки и стоимости результата. Иначе легко построить дорогого агента, который красиво демонстрируется, но плохо живёт в реальном процессе.
Для Claude Code это особенно показательно: по документации Anthropic, инструмент читает кодовую базу, правит файлы, запускает команды, работает с dev-инструментами и может действовать на уровне проекта. Значит, оценивать нужно весь контур, а не один финальный diff: reasoning, tool use, безопасность, права доступа, контроль стоимости и качество обратной связи.
Вывод: agentic-разработка требует отдельного цикла управления. Сначала формулируем поведение и границы ответственности, затем доказываем ценность на данных, строим eval-систему, выкатываем через controlled rollout и продолжаем мониторить качество после релиза. Для агентов maintenance — это постоянный feedback loop, а не редкий проверка после деплоя.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Искусство. Код... ИИ?
SECURITY.md — простой путь к безопасному gen-AI кодуЗайду, как водится, издалека. На работе я сейчас вожусь со штукой, для тестирования которой нужно заставить LLM, работающую с кодинг-агентом, генерировать уязвимый код. И это, должен заметить, оказалось не так уж и легко, что навело на весьма очевидную мысль.
LLM, в массе своей, вполне способны писать безопасный код. Знаний на эту тему у них — уж точно больше, чем у любого среднестатистического эксперта в этой области. Но скажите на милость, когда разработчик пишет агенту:
Эй, /explore, давай спроектируем крутую фичу feat-XXX для <бла-бла-бла>!
— какая из букв в этом промпте означает security? Может быть, про неё упоминается в скилле? Да тоже нет. В куче же скиллов для secure-кодинга буквально каждый — представляет собой перечень избитых (плюс и так известных моделям) правил, поверх «усредненных» моделей угроз.
А весь мой опыт, полученный за полтора десятка лет работы в области безопасности кода, говорит о том, что работая с усредненной моделью угроз, нельзя рассчитывать на что-либо, кроме усредненных результатов.
Так может, модели нужна подсказка о том, чем именно является безопасность в данном конкретном проекте и как применять к ней имеющиеся у модели знания? GitHub уже предлагает иметь в корне проекта SECURITY.md, с поддерживаемыми версиями проекта и процедурой репортинга уязвимостей, называя это «политикой безопасности». Так может, стоит её там таки описать?
Так и родился скилл security-policy-generator, генерирующий SECURITY.md, включающий в себя модель угроз и правила secure-кодинга, построенные относительно конкретного проекта со всей его спецификой. Ну и, скилл также добавляет референс на созданный файл в AGENTS.md с инструкцией по использованию, чтобы агент уж точно его не пропустил. Коль скоро SECURITY.md создан, обновлять его можно простым «
Update SECURITY.md to reflect the latest changes.», отдельный скилл для этого не требуется.Посмотреть результаты работы скилла на конкретном проекте можно здесь.
Бенчи не проводил (в планах это есть), но достаточно плотно потестировал результаты работы скилла на нескольких проектах под Qoder, OpenCode и собственным кодинг-агентом. Рассуждения вида «
This [won't] become a vulnerability because <здесь реф на модель угроз>» появляются, что как бы намекает на правильную работу всей задумки.P.S: отдельно порадовало, что мой кодинг-агент (по ссылке выше — результаты именно его работы) самоотверженно включил самого себя в потенциальные threat-actors модели угроз. Это так мило...
А вы говорите, AI-агенты в безопасности не шарят))
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Makrushin
Архитектура платформы для автоматизации SOC с помощью ИИ-агентов
Всегда интересно прочитать истории, как LLM самостоятельно находит уязвимости в популярном продукте. Как крупные вендоры вроде Mozilla патчат 271 уязвимость, которую обнаружил Mythos. Или как ИИ-агент за 3 минуты без подсказок смог самостоятельно скомпрометировать облачную инфраструктуру. Среди подобных материалов часто остаются незаметны идеи, которые нужны специалистам по защите. На прошлой неделе бот закрыл этот пробел и принес исследование, которое будет интересно Blue Team.
В статье описана архитектура системы ИИ-агентов для автоматизации работы центров мониторинга. Ключевую идею этой платформы можно описать одним словом: проактивность. Чтобы не ждать очередных пентестов и проверок Red Team, аналитики могут самостоятельно построить систему непрерывного прогнозирования и обновления детекторов. Ключевая особенность платформы AgentSOC заключается в движке анализа гипотез. Этот модуль отвечает за творческую часть, которая часто остается без внимания загруженного рутиной аналитика. В нем LLM строит ветки возможного развития атак на основе имеющегося контекста из систем мониторинга. Затем привязывает эти ветки к матрице атак MITRE. То есть система постоянно рассуждает над вопросом «что, если», присваивает ответу индекс уверенности и повторяет упражнение.
Второй движок структурного моделирования выступает в роли критика и проверяет теоретические рассуждения модели на основе фактического состояния инфраструктуры. Графовая валиадация атак, проверка достижимости, фильтрация галлюцинаций — все это его задачи.
В итоге, вся система работает в автономном цикле «Sense-Reason-Act» и выбирает наиболее подходящее действие для защиты менее чем за 1 секунду.
@makrushin l MAX l VK l Сетка l Дзен
Всегда интересно прочитать истории, как LLM самостоятельно находит уязвимости в популярном продукте. Как крупные вендоры вроде Mozilla патчат 271 уязвимость, которую обнаружил Mythos. Или как ИИ-агент за 3 минуты без подсказок смог самостоятельно скомпрометировать облачную инфраструктуру. Среди подобных материалов часто остаются незаметны идеи, которые нужны специалистам по защите. На прошлой неделе бот закрыл этот пробел и принес исследование, которое будет интересно Blue Team.
В статье описана архитектура системы ИИ-агентов для автоматизации работы центров мониторинга. Ключевую идею этой платформы можно описать одним словом: проактивность. Чтобы не ждать очередных пентестов и проверок Red Team, аналитики могут самостоятельно построить систему непрерывного прогнозирования и обновления детекторов. Ключевая особенность платформы AgentSOC заключается в движке анализа гипотез. Этот модуль отвечает за творческую часть, которая часто остается без внимания загруженного рутиной аналитика. В нем LLM строит ветки возможного развития атак на основе имеющегося контекста из систем мониторинга. Затем привязывает эти ветки к матрице атак MITRE. То есть система постоянно рассуждает над вопросом «что, если», присваивает ответу индекс уверенности и повторяет упражнение.
Второй движок структурного моделирования выступает в роли критика и проверяет теоретические рассуждения модели на основе фактического состояния инфраструктуры. Графовая валиадация атак, проверка достижимости, фильтрация галлюцинаций — все это его задачи.
В итоге, вся система работает в автономном цикле «Sense-Reason-Act» и выбирает наиболее подходящее действие для защиты менее чем за 1 секунду.
@makrushin l MAX l VK l Сетка l Дзен
Forwarded from AISecHub
PromptShield: Prompt-Injection Detection with Wazuh SIEM Integration
Useful pattern: treat prompt-injection attempts as security telemetry—detect and route them into SIEM workflows (alerts, triage, correlation) instead of relying on prompt-only mitigations inside the model.
#PromptInjection #LLMSecurity #AISecurity #Tool
https://github.com/nourSOC/PromptShield
Useful pattern: treat prompt-injection attempts as security telemetry—detect and route them into SIEM workflows (alerts, triage, correlation) instead of relying on prompt-only mitigations inside the model.
#PromptInjection #LLMSecurity #AISecurity #Tool
https://github.com/nourSOC/PromptShield
GitHub
GitHub - nourSOC/PromptShield: AI Prompt Injection Detection & Wazuh SIEM Integration
AI Prompt Injection Detection & Wazuh SIEM Integration - nourSOC/PromptShield
Forwarded from OK ML
Мультиагентные системы, роевой интеллект и эпоха AI-агентов
Индустрия постепенно движется к мультиагентным системам🤩 — архитектурам, где работает не один AI, а сразу несколько агентов, взаимодействующих между собой. Уже настоящая команда 🫱🫲 .
Особенно интересно наблюдать, как в AI оживают идеи роевого интеллекта🐟 🐟 🐟 — те самые принципы, которые мы видим у муравьев, пчел, косяка рыб или стай птиц. У них ведь нет центрального мозга, который управляет каждым движением, но за счет постоянного обмена сигналами и локальных взаимодействий возникает удивительно сложное коллективное поведение. Сейчас похожие вещи начинают происходить и в системах AI-агентов. Отдельный агент может ошибаться, терять контекст, галлюцинировать или заходить в тупик. Но когда агентов несколько, они начинают компенсировать слабости друг друга. Один замечает ошибку второго. Второй предлагает гипотезу, третий пытается ее опровергнуть. Четвертый собирает дополнительные данные. Итог получается заметно сильнее, чем если бы задачу решала одна большая модель.
👽 Мне кажется, это важный сдвиг в самом понимании AI. Раньше основное внимание было сосредоточено на размерах моделей и качестве промптов. Теперь все чаще становится важна именно архитектура взаимодействия, как агенты координируются, как обмениваются памятью, как принимают коллективные решения, как проверяют выводы друг друга.
💐 Возможно, если когда-нибудь появится настоящий AGI, он будет больше похож как раз на сложный коллективный интеллект?
Но это были мои мысли, а что же почитать про МАС, АИ-агентов и роевой интеллект?
Если хочется нормально погрузиться в тему, то сейчас знания разбросаны между несколькими областями: МАС, роевой интеллект, распределенные системы RL и современными LLM-агентными фреймворками (шерсти этот канал!). Но есть несколько работ и направлений, с которых действительно стоит начать и про которые мы не говорили.
Важной стала статья "ReAct: Synergizing Reasoning and Acting in Language Models". Она сильно повлияла на современную архитектуру агентов, где модель не просто отвечает текстом, а чередует reasoning и actions. Многие современные автономные агенты — это развитие ReAct.
Еще одна интересная работа — "CAMEL: Communicative Agents for Mind Exploration". Она исследует, как агенты могут общаться между собой для решения задач. Сейчас это направление развивается очень быстро: agent-to-agent протоколы, self-play (без шуток, пошерсти канал!), collaborative reasoning.
Делаю ставку на репу Generative Agents: Interactive Simulacra of Human Behavior — 🦾! Там моделируются целые общества AI-агентов с памятью, социальным и эмерджентными поведением. Насколько быстро агенты вообще могут эволюционировать в сложные автономные среды…
База! Читаем!
И вообще есть ощущение, что в ближайшие годы разработчику AI-систем придется понимать не только модели, но и распределенные системы, теорию игр, отказоустойчивость, графы, координацию, память и самоорганизующиеся системы.
Все!
🦔
Индустрия постепенно движется к мультиагентным системам
Особенно интересно наблюдать, как в AI оживают идеи роевого интеллекта
Но это были мои мысли, а что же почитать про МАС, АИ-агентов и роевой интеллект?
Если хочется нормально погрузиться в тему, то сейчас знания разбросаны между несколькими областями: МАС, роевой интеллект, распределенные системы RL и современными LLM-агентными фреймворками (шерсти этот канал!). Но есть несколько работ и направлений, с которых действительно стоит начать и про которые мы не говорили.
Важной стала статья "ReAct: Synergizing Reasoning and Acting in Language Models". Она сильно повлияла на современную архитектуру агентов, где модель не просто отвечает текстом, а чередует reasoning и actions. Многие современные автономные агенты — это развитие ReAct.
Еще одна интересная работа — "CAMEL: Communicative Agents for Mind Exploration". Она исследует, как агенты могут общаться между собой для решения задач. Сейчас это направление развивается очень быстро: agent-to-agent протоколы, self-play (без шуток, пошерсти канал!), collaborative reasoning.
Делаю ставку на репу Generative Agents: Interactive Simulacra of Human Behavior — 🦾! Там моделируются целые общества AI-агентов с памятью, социальным и эмерджентными поведением. Насколько быстро агенты вообще могут эволюционировать в сложные автономные среды…
База! Читаем!
И вообще есть ощущение, что в ближайшие годы разработчику AI-систем придется понимать не только модели, но и распределенные системы, теорию игр, отказоустойчивость, графы, координацию, память и самоорганизующиеся системы.
Все!
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡1
Forwarded from AISecHub
О построении МАС - требования к модулю-оркестратору и к мультиагентскому взаимодействию в Cisco Foundry Security Spec
5.1 Orchestrator
8.3 Inter-agent communication
5.1 Orchestrator
8.3 Inter-agent communication
GitHub
foundry-security-spec/spec.md at main · CiscoDevNet/foundry-security-spec
An open specification for agentic AI security evaluation and testing, from Cisco. - CiscoDevNet/foundry-security-spec