🧨 CyberForge: AI-агентов учат искать уязвимости на настоящем коде
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
Реальных CVE не так много, их сложно воспроизводить, а превращение каждой уязвимости в полноценную тренировочную задачу требует ручной работы.
Исследователи из NIST и University of Maryland предложили новый подход, CyberForge.
⚙️ Уязвимости создаются искусственно
CyberForge берёт реальные C/C++ проекты из OSS-Fuzz и специально вносит в них небольшие изменения, превращающие обычный код в уязвимый.
Система принимает уязвимость только если одновременно выполняются два условия:
🔹 исходные unit-тесты продолжают проходить;
🔹 Proof-of-Vulnerability срабатывает на изменённой версии, но не срабатывает на оригинальной.
Полученная уязвимость должна оставаться скрытой при обычной работе, но реально эксплуатироваться специально подготовленным входом.
🧠 Результаты
CyberForge создал:
➖ 1 034 подтверждённые уязвимости;
➖ 80 реальных open-source проектов;
➖ 63 категории CWE.
В 1 025 из 1 034 кейсах изменяли только один файл, а в 944 всего один участок кода. По характеру изменений полученный датасет оказался сопоставим с реальными CVE-патчами.
🔥 И улучшение AI-агентов
Исследователи собрали на этих задачах trajectories от более сильных моделей и использовали их для fine-tuning Gemma 4.
На SEC-bench результат 31B-модели вырос на 14,7%.
Кроме того, модели, обученные исключительно на C/C++, улучшили результаты и на другом наборе задач с Python, JavaScript и Go.
🛡️ Меняем подход
Получается новый цикл обучения security-агентов:
реальный репозиторий → синтетическая уязвимость → автоматическая проверка → задача для AI → обучение → более сильный security-agent.
P.S. Созданные уязвимости являются синтетическими изменениями open-source кода и не представляют собой новые zero-day в продуктивных системах.
🔗 Исследование: https://arxiv.org/abs/2608.06471
🔗 Проект: https://cyb3rforge.github.io
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AppSec #VulnerabilityResearch #CyberSecurity #OSSFuzz #DevSecOps #SecureTechTalks
👍1
🧨 Зашифрованные мысли LLM не такие уж секретные
Разработчики Anthropic, OpenAI и Google специально прячут chain-of-thought. Пользователь получает только краткое summary, а полное reasoning API возвращает в виде зашифрованного блока, который клиент должен передать обратно при следующем запросе.
Звучит безопасно? Спойлер -нет .
Исследователи из Tübingen, Max Planck, MATS и Snyk показали, что если взять такой блок от сильной модели и передать его более слабой модели того же провайдера, слабую модель можно заставить расшифровать и вывести исходный reasoning практически дословно.
⚙️ В чём проблема?
Уязвимость оказалась архитектурной. Reasoning-блоки были совместимы между разными сессиями, пользователями и моделями внутри одной экосистемы.
Схема выглядит так:
сильная модель → encrypted reasoning → слабая модель → plaintext reasoning
Более слабая модель становится дешёвым «дешифратором», потому что у неё менее строгие защитные настройки.
🧠 Дальше больше
Учёные скачали 315 320 зашифрованных reasoning-блоков из публичных репозиториев и смогли восстановить из них:
🔹 367 PII-артефактов;
🔹 182 credentials.
То есть разработчик мог спокойно опубликовать лог, увидеть в нём набор бессмысленных символов и фактически выложить вместе с ним пароль или API credential.
Стоит учесть, что reasoning может содержать информацию, которой вообще нет в видимой части сессии.
🔥 Более опасный сценарий
Исследователи показали, что этот же механизм можно использовать и в обратную сторону. Не извлекать скрытый prompt, а спрятать вредоносную инструкцию внутри reasoning-блока.
Видимый лог выглядит нормально. Человек ничего подозрительного не замечает, но другой агент, получив этот блок как часть истории предыдущего запуска, может прочитать встроенную инструкцию как собственное прошлое состояние.
Получается новый вариант invisible prompt injection, который особенно опасен для публичных коллекций agent trajectories.
🧨 Причем тут Kimi?
Авторы отдельно сравнили скрытые reasoning-трейсы Claude Opus 4.8 и GPT-5.6 Sol с несколькими open-weight моделями.
У Kimi K3 обнаружились необычно сильные совпадения. Это выглядит как возможный след distillation, но авторы подчёркивают, что эксперимент не доказывает, что Kimi действительно обучалась на украденных reasoning-трейсах.
🔗 Исследование: https://arxiv.org/abs/2608.09867
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ChainOfThought #AgenticAI #AISecurity #PromptInjection #DataLeak #ModelSecurity #SecureTechTalks
Разработчики Anthropic, OpenAI и Google специально прячут chain-of-thought. Пользователь получает только краткое summary, а полное reasoning API возвращает в виде зашифрованного блока, который клиент должен передать обратно при следующем запросе.
Звучит безопасно? Спойлер -
Исследователи из Tübingen, Max Planck, MATS и Snyk показали, что если взять такой блок от сильной модели и передать его более слабой модели того же провайдера, слабую модель можно заставить расшифровать и вывести исходный reasoning практически дословно.
⚙️ В чём проблема?
Уязвимость оказалась архитектурной. Reasoning-блоки были совместимы между разными сессиями, пользователями и моделями внутри одной экосистемы.
Схема выглядит так:
сильная модель → encrypted reasoning → слабая модель → plaintext reasoning
Более слабая модель становится дешёвым «дешифратором», потому что у неё менее строгие защитные настройки.
🧠 Дальше больше
Учёные скачали 315 320 зашифрованных reasoning-блоков из публичных репозиториев и смогли восстановить из них:
🔹 367 PII-артефактов;
🔹 182 credentials.
То есть разработчик мог спокойно опубликовать лог, увидеть в нём набор бессмысленных символов и фактически выложить вместе с ним пароль или API credential.
Стоит учесть, что reasoning может содержать информацию, которой вообще нет в видимой части сессии.
🔥 Более опасный сценарий
Исследователи показали, что этот же механизм можно использовать и в обратную сторону. Не извлекать скрытый prompt, а спрятать вредоносную инструкцию внутри reasoning-блока.
Видимый лог выглядит нормально. Человек ничего подозрительного не замечает, но другой агент, получив этот блок как часть истории предыдущего запуска, может прочитать встроенную инструкцию как собственное прошлое состояние.
Получается новый вариант invisible prompt injection, который особенно опасен для публичных коллекций agent trajectories.
🧨 Причем тут Kimi?
Авторы отдельно сравнили скрытые reasoning-трейсы Claude Opus 4.8 и GPT-5.6 Sol с несколькими open-weight моделями.
У Kimi K3 обнаружились необычно сильные совпадения. Это выглядит как возможный след distillation, но авторы подчёркивают, что эксперимент не доказывает, что Kimi действительно обучалась на украденных reasoning-трейсах.
🔗 Исследование: https://arxiv.org/abs/2608.09867
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ChainOfThought #AgenticAI #AISecurity #PromptInjection #DataLeak #ModelSecurity #SecureTechTalks
👍1
💣 Convergent Detour Hijacking: когда AI-агент делает всё правильно
У AI-агентов появляется новый класс атак, который сложно заметить обычными security-проверками.
Convergent Detour Hijacking (CDH) не заставляет агента провалить задачу. Наоборот, агент приходит к правильному результату, но по специально навязанному обходному и безумно дорогому маршруту.
Представьте задачу: «найти уязвимость в приложении и подготовить отчёт.»
Нормальный агент:
После атаки:
Каждый шаг выглядит разумным. Но их становится в разы больше. Растёт всё:
🔹 количество tool calls
🔹 число inference steps
🔹 расход токенов
🔹 время выполнения
🔹 нагрузка на инструменты
🔹 стоимость запуска агента
🎯 В чём трюк?
Агент подменяет или заражает skill, определяющий, как агент должен решать задачу. В навык можно добавить дополнительные проверки, повторные валидации или альтернативные ветки и увеличить стоимость решения задачи в несколько раз.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AIsecurity #AIAgents #LLM #AgentSecurity #PromptInjection #AgenticAI #Cybersecurity #LLMSecurity #SecureTechTalks
У AI-агентов появляется новый класс атак, который сложно заметить обычными security-проверками.
Convergent Detour Hijacking (CDH) не заставляет агента провалить задачу. Наоборот, агент приходит к правильному результату, но по специально навязанному обходному и безумно дорогому маршруту.
Представьте задачу: «найти уязвимость в приложении и подготовить отчёт.»
Нормальный агент:
recon → test → analyze → report
После атаки:
recon → test → verify → re-check → reproduce → validate → compare → retry → analyze → report
Каждый шаг выглядит разумным. Но их становится в разы больше. Растёт всё:
🔹 количество tool calls
🔹 число inference steps
🔹 расход токенов
🔹 время выполнения
🔹 нагрузка на инструменты
🔹 стоимость запуска агента
🎯 В чём трюк?
Агент подменяет или заражает skill, определяющий, как агент должен решать задачу. В навык можно добавить дополнительные проверки, повторные валидации или альтернативные ветки и увеличить стоимость решения задачи в несколько раз.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AIsecurity #AIAgents #LLM #AgentSecurity #PromptInjection #AgenticAI #Cybersecurity #LLMSecurity #SecureTechTalks
🧨 AI-агенты умеют работать с кодом. Но что будет, если кода больше нет?
Исследователи из Columbia, Berkeley, UCLA, Tufts и других организаций представили SRE-Bench, бенчмарк, созданный специально для проверки того, насколько AI-агенты способны разбирать неизвестные бинарники, а не узнавать уже знакомый проект из обучающих данных.
⚙️ Больше никакого «угадай, что это за программа»
Авторы сделали 19 программ с нуля, общей сложностью более 320 000 строк кода.
Внутри пять типов задач:
🔹 сетевые протоколы;
🔹 firmware;
🔹 игровые приложения;
🔹 собственные форматы файлов;
🔹 безопасная имитация malware.
Средний размер программы 16,9 тыс. строк.
Затем исследователи превратили их в 262 уникальных бинарных экземпляра и добавили 44 механизма anti-analysis: obfuscation, anti-debugging, виртуализированный loader, шифрование страниц кода, anti-dump и другие техники.
В итоге получилось 1 572 детерминированно проверяемые задачи.
На создание всего этого ушло более 5 000 часов работы специалистов по reverse engineering.
🧠 Результаты AI
Пять frontier-моделей получили одинаковый набор инструментов: Ghidra, GDB, angr, radare2, binutils и другие RE-инструменты.
Лучшей оказалась GPT-5.6-Sol:
61,4% среднего результата и только 80 из 262 бинарников полностью решены (31,5%).
Claude Opus 5 решил 12,5%, GPT-5.5 - 3,8%, Grok 4.5 - 0,9%, а GLM-5.2 не смог полностью решить ни одного экземпляра.
Эксперимент стоил исследователям $31,4 тыс. и занял около 1 812 sandbox-часов.
🔥 Агенты думают не как reverse engineer
У человека оптимизированный и statically linked бинарник обычно сложнее анализировать, а у AI почти наоборот.
Для GPT-5.6-Sol оптимизация снизила результат всего с 4,75 до 4,67 из 6, а static linking с 4,73 до 4,69.
Удаление символов оказалось намного болезненнее: результат упал с 4,95 до 4,47.
Похоже, современные агенты сильно опираются на имена функций, переменных и другие lexical anchors, которые помогают им построить смысловую модель программы. Когда эти подсказки исчезают, capability резко проседает.
🛡️ Защита ломает всё
Когда авторы включили собственный anti-analysis слой, результат GPT-5.6-Sol практически упал вдвое: с 4,69 до 2,50.
Claude Opus 5 рухнул с 3,07 до 0,33, а остальные модели приблизились к нулю.
AI уже довольно хорошо работает с известной структурой исходного кода. Но между «прочитать код» и «понять неизвестный защищённый бинарник» пока огромная пропасть.
Бинарный анализ не экзотическая задача. Именно так приходится исследовать значительную часть malware, firmware, закрытого enterprise-софта и security appliances. Авторы отмечают, что 46,5% уязвимостей, эксплуатируемых in-the-wild, связаны с вендорами, которые не публикуют исходный код.
🔗 Исследование: https://arxiv.org/pdf/2608.11469
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ReverseEngineering #MalwareAnalysis #BinaryAnalysis #AISecurity #ThreatResearch #SecureTechTalks
Исследователи из Columbia, Berkeley, UCLA, Tufts и других организаций представили SRE-Bench, бенчмарк, созданный специально для проверки того, насколько AI-агенты способны разбирать неизвестные бинарники, а не узнавать уже знакомый проект из обучающих данных.
⚙️ Больше никакого «угадай, что это за программа»
Авторы сделали 19 программ с нуля, общей сложностью более 320 000 строк кода.
Внутри пять типов задач:
🔹 сетевые протоколы;
🔹 firmware;
🔹 игровые приложения;
🔹 собственные форматы файлов;
🔹 безопасная имитация malware.
Средний размер программы 16,9 тыс. строк.
Затем исследователи превратили их в 262 уникальных бинарных экземпляра и добавили 44 механизма anti-analysis: obfuscation, anti-debugging, виртуализированный loader, шифрование страниц кода, anti-dump и другие техники.
В итоге получилось 1 572 детерминированно проверяемые задачи.
На создание всего этого ушло более 5 000 часов работы специалистов по reverse engineering.
🧠 Результаты AI
Пять frontier-моделей получили одинаковый набор инструментов: Ghidra, GDB, angr, radare2, binutils и другие RE-инструменты.
Лучшей оказалась GPT-5.6-Sol:
61,4% среднего результата и только 80 из 262 бинарников полностью решены (31,5%).
Claude Opus 5 решил 12,5%, GPT-5.5 - 3,8%, Grok 4.5 - 0,9%, а GLM-5.2 не смог полностью решить ни одного экземпляра.
Эксперимент стоил исследователям $31,4 тыс. и занял около 1 812 sandbox-часов.
🔥 Агенты думают не как reverse engineer
У человека оптимизированный и statically linked бинарник обычно сложнее анализировать, а у AI почти наоборот.
Для GPT-5.6-Sol оптимизация снизила результат всего с 4,75 до 4,67 из 6, а static linking с 4,73 до 4,69.
Удаление символов оказалось намного болезненнее: результат упал с 4,95 до 4,47.
Похоже, современные агенты сильно опираются на имена функций, переменных и другие lexical anchors, которые помогают им построить смысловую модель программы. Когда эти подсказки исчезают, capability резко проседает.
🛡️ Защита ломает всё
Когда авторы включили собственный anti-analysis слой, результат GPT-5.6-Sol практически упал вдвое: с 4,69 до 2,50.
Claude Opus 5 рухнул с 3,07 до 0,33, а остальные модели приблизились к нулю.
AI уже довольно хорошо работает с известной структурой исходного кода. Но между «прочитать код» и «понять неизвестный защищённый бинарник» пока огромная пропасть.
Бинарный анализ не экзотическая задача. Именно так приходится исследовать значительную часть malware, firmware, закрытого enterprise-софта и security appliances. Авторы отмечают, что 46,5% уязвимостей, эксплуатируемых in-the-wild, связаны с вендорами, которые не публикуют исходный код.
🔗 Исследование: https://arxiv.org/pdf/2608.11469
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ReverseEngineering #MalwareAnalysis #BinaryAnalysis #AISecurity #ThreatResearch #SecureTechTalks
🧨 Hazmat: sandbox для AI-агентов на macOS
Coding-агенты (Claude Code, Codex и т.д.) умеют самостоятельно выполнять shell-команды, устанавливать зависимости и менять файлы. Если агент получит prompt injection то, последствия могут быть крайне печальными.
OpenSource продукт Hazmat ограничивает агента на уровне операционной системы.
⚙️ Немного деталей
Агент запускается от отдельного пользователя "agent", поэтому не получает ваш "$HOME", SSH-ключи и credentials.
Дополнительно используются:
🔹 macOS Seatbelt для ограничения доступа к файловой системе;
🔹 PF firewall и DNS blocklist для контроля сетевого доступа;
🔹 ограничения для package managers, включая npm;
🔹 snapshot проекта перед запуском и возможность посмотреть diff или откатить изменения.
Перед стартом работы указывается session contract: какие каталоги доступны, что можно изменять и какие интеграции включены.
🛡️ Принципиальные ограничения
Представим вредоносный "CLAUDE.md", который заставляет агента прочитать "~/.ssh/id_ed25519" и отправить ключ наружу.
Модель может выполнить команду, но её процесс не должен иметь необходимых прав и доступа. Безопасность должна учитывать сценарий, в котором модель уже скомпрометирована.
🔗 GitHub: https://github.com/dredozubov/hazmat
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ClaudeCode #Codex #AISecurity #Sandbox #macOS #SecureTechTalks
Coding-агенты (Claude Code, Codex и т.д.) умеют самостоятельно выполнять shell-команды, устанавливать зависимости и менять файлы. Если агент получит prompt injection то, последствия могут быть крайне печальными.
OpenSource продукт Hazmat ограничивает агента на уровне операционной системы.
⚙️ Немного деталей
Агент запускается от отдельного пользователя "agent", поэтому не получает ваш "$HOME", SSH-ключи и credentials.
Дополнительно используются:
🔹 macOS Seatbelt для ограничения доступа к файловой системе;
🔹 PF firewall и DNS blocklist для контроля сетевого доступа;
🔹 ограничения для package managers, включая npm;
🔹 snapshot проекта перед запуском и возможность посмотреть diff или откатить изменения.
Перед стартом работы указывается session contract: какие каталоги доступны, что можно изменять и какие интеграции включены.
🛡️ Принципиальные ограничения
Представим вредоносный "CLAUDE.md", который заставляет агента прочитать "~/.ssh/id_ed25519" и отправить ключ наружу.
Модель может выполнить команду, но её процесс не должен иметь необходимых прав и доступа. Безопасность должна учитывать сценарий, в котором модель уже скомпрометирована.
🔗 GitHub: https://github.com/dredozubov/hazmat
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ClaudeCode #Codex #AISecurity #Sandbox #macOS #SecureTechTalks
👍1
🧨 LLM научились ловить ботов. Теперь боты учатся обманывать LLM
Соцсети всё чаще используют LLM для поиска ботов. Модель читает профиль, историю публикаций и пытается понять, перед ней человек или автоматизированный аккаунт.
Проблема начинается в тот момент, когда атакующий понимает, как работает детектор.
⚙️ Достаточно переписать запрос
Исследователи из Reichman University проверили три open source модели: Llama 3 8B, Gemma 7B и Mistral 7B.
Они использовали два класса атак.
🔹 Content Manipulation: AI переписывает публикации бота так, чтобы они выглядели более естественно.
🔹 LLM Manipulation: в данные добавляется prompt injection, который пытается заставить классификатор забыть исходную задачу.
У Llama точность детектирования после некоторых атак падала примерно с 91% до 75%. Для Gemma падение доходило примерно до 35%.
🧠 Атака на сам детектор
Самый действенный результат связан с prompt injection. Для Llama и Gemma некоторые варианты атак снижали качество классификации примерно на 46% и 48% соответственно. Причём модель могла начать выполнять инструкции из анализируемого контента вместо первоначальной задачи определения бота.
Таким образом, система безопасности сама становится объектом атаки.
🔥 Один LLM против другой
Авторы проверили несколько защитных подходов: delimiters, self examination, in context learning, feature guidance и проверки known answer.
Универсального решения не нашлось. Например, для Llama feature guidance помогал против reasoning injection, а known answer оказался особенно эффективен против некоторых других вариантов атак. Поэтому исследователи собрали LSABRE, ансамбль из нескольких LLM.
Он работает в три этапа:
Detection → Prevention → Classification
Сначала несколько моделей ищут признаки манипуляции. Подозрительный контент получает дополнительную защиту. После этого основная модель выполняет классификацию.
В эксперименте LSABRE достиг 86,2% accuracy при атаке и сохранил FPR около 13%.
🔗 Исследование: https://arxiv.org/abs/2608.15893
🔗 GitHub LSABRE: https://github.com/runi-cyber-ai/LSABRE
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BotDetection #PromptInjection #AISecurity #RedTeaming #CyberSecurity #SecureTechTalks
Соцсети всё чаще используют LLM для поиска ботов. Модель читает профиль, историю публикаций и пытается понять, перед ней человек или автоматизированный аккаунт.
Проблема начинается в тот момент, когда атакующий понимает, как работает детектор.
⚙️ Достаточно переписать запрос
Исследователи из Reichman University проверили три open source модели: Llama 3 8B, Gemma 7B и Mistral 7B.
Они использовали два класса атак.
🔹 Content Manipulation: AI переписывает публикации бота так, чтобы они выглядели более естественно.
🔹 LLM Manipulation: в данные добавляется prompt injection, который пытается заставить классификатор забыть исходную задачу.
У Llama точность детектирования после некоторых атак падала примерно с 91% до 75%. Для Gemma падение доходило примерно до 35%.
🧠 Атака на сам детектор
Самый действенный результат связан с prompt injection. Для Llama и Gemma некоторые варианты атак снижали качество классификации примерно на 46% и 48% соответственно. Причём модель могла начать выполнять инструкции из анализируемого контента вместо первоначальной задачи определения бота.
Таким образом, система безопасности сама становится объектом атаки.
🔥 Один LLM против другой
Авторы проверили несколько защитных подходов: delimiters, self examination, in context learning, feature guidance и проверки known answer.
Универсального решения не нашлось. Например, для Llama feature guidance помогал против reasoning injection, а known answer оказался особенно эффективен против некоторых других вариантов атак. Поэтому исследователи собрали LSABRE, ансамбль из нескольких LLM.
Он работает в три этапа:
Detection → Prevention → Classification
Сначала несколько моделей ищут признаки манипуляции. Подозрительный контент получает дополнительную защиту. После этого основная модель выполняет классификацию.
В эксперименте LSABRE достиг 86,2% accuracy при атаке и сохранил FPR около 13%.
🔗 Исследование: https://arxiv.org/abs/2608.15893
🔗 GitHub LSABRE: https://github.com/runi-cyber-ai/LSABRE
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BotDetection #PromptInjection #AISecurity #RedTeaming #CyberSecurity #SecureTechTalks
❤1👍1
🧨 Google учит AI работать с зашифрованными данными
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
👍1
🧨 Просроченная банковская карта может снова заработать
Исследователи из University of Massachusetts Amherst показали атаку Zombie Card, позволяющую в некоторых сценариях провести бесконтактный платеж картой после окончания срока её действия.
⚙️ Принцип действия
Срок действия карты передаётся терминалу по NFC, однако значение даты не входит в криптографическую аутентификацию.
Исследователи использовали атаку Man in the Middle между картой и терминалом и изменяли передаваемую дату. Криптографические данные карты оставались корректными.
Схема следующая:
карта → NFC → изменение даты → терминал
🧠 Криптографию взламывать не пришлось
Самое примечательное в атаке в отсутствии необходимости кражи ключа карты и подделке криптографической подписи. Проблема возникает из-за того, что терминал самостоятельно принимает решение о действительности карты на основании данных, которые можно изменить по пути.
В тестах Visa и Mastercard результаты зависели от конкретного банка и терминала. Часть операций блокировалась, часть проходила.
🛡️ Классика жанра
Zombie Card хорошо показывает классическую проблему безопасности платежей, отдельные компоненты могут быть надёжно защищены, но уязвимость появляется на границе между ними.
🔗 Исследование: https://www.usenix.org/conference/usenixsecurity26/presentation/anwar
🔗 Технические детали: https://khwarizmilab.github.io/emvexpiredcards/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #PaymentSecurity #EMV #NFC #BankingSecurity #CyberSecurity #FinTech #SecureTechTalks
Исследователи из University of Massachusetts Amherst показали атаку Zombie Card, позволяющую в некоторых сценариях провести бесконтактный платеж картой после окончания срока её действия.
⚙️ Принцип действия
Срок действия карты передаётся терминалу по NFC, однако значение даты не входит в криптографическую аутентификацию.
Исследователи использовали атаку Man in the Middle между картой и терминалом и изменяли передаваемую дату. Криптографические данные карты оставались корректными.
Схема следующая:
карта → NFC → изменение даты → терминал
🧠 Криптографию взламывать не пришлось
Самое примечательное в атаке в отсутствии необходимости кражи ключа карты и подделке криптографической подписи. Проблема возникает из-за того, что терминал самостоятельно принимает решение о действительности карты на основании данных, которые можно изменить по пути.
В тестах Visa и Mastercard результаты зависели от конкретного банка и терминала. Часть операций блокировалась, часть проходила.
🛡️ Классика жанра
Zombie Card хорошо показывает классическую проблему безопасности платежей, отдельные компоненты могут быть надёжно защищены, но уязвимость появляется на границе между ними.
🔗 Исследование: https://www.usenix.org/conference/usenixsecurity26/presentation/anwar
🔗 Технические детали: https://khwarizmilab.github.io/emvexpiredcards/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #PaymentSecurity #EMV #NFC #BankingSecurity #CyberSecurity #FinTech #SecureTechTalks
👍2❤1
🧨 MITRE-SAGE: расследование киберинцидентов
LLM неплохо объясняет, что такое CVE или MITRE ATT&CK, но узкоспециализированных вопросов приходится одновременно искать факты, связывать сущности между собой и проверять несколько источников. Обычный RAG с набором текстовых чанков с этим справляется далеко не всегда.
⚙️ Команда вместо одного агента
Авторы MITRE-SAGE собрали многоагентную систему, где разные модели занимаются разными частями сбора информации.
🔹 Graph Agent ищет связи в графе на основе MITRE и NVD;
🔹 Text Agent извлекает информацию из документов;
🔹 Web Agent ищет свежие сведения в интернете;
🔹 отдельные агенты сокращают найденную информацию и отбрасывают нерелевантные данные;
🔹 Orchestrator решает, какие источники подключить, сравнивает результаты и формирует ответ.
Модель сначала разбивает вопрос на подзадачи, собирает доказательства из разных источников и только после этого отвечает.
🧠 Главное не количество агентов
Интересно, что авторы отдельно создали MITRE-QA, набор из 3000 вопросов по кибербезопасности.
В нём есть обычные вопросы о CVE и CWE, поиск сущностей, анализ связей, профилирование угроз и более сложные multi-hop задачи, где ответ приходится собирать из нескольких связанных фактов.
В результате MITRE-SAGE показал лучший результат в 5 из 8 задач, а на структурированном поиске знаний получил accuracy 89% против 31% у GPT-4.1.
На некоторых задачах преимущество доходило до 58%, а корректность генерируемых ответов улучшалась до 35,5% относительно наиболее сильного baseline.
🔥 Ресурсы
Система работает на относительно небольших open source моделях: оркестратор использует Qwen2.5-14B, остальные агенты работают на Qwen2.5-7B. Эксперимент запускался на одной NVIDIA A100 80 GB.
В данном подходе LLM становится скорее координатором, нежели энциклопедией, которая пытается всё вспомнить сама.
🔗 Исследование: arXiv 2608.16921
🔗 MITRE-QA: GitHub
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #MITREATTACK #ThreatIntelligence #SOC #AgenticAI #AISecurity #SecureTechTalks
LLM неплохо объясняет, что такое CVE или MITRE ATT&CK, но узкоспециализированных вопросов приходится одновременно искать факты, связывать сущности между собой и проверять несколько источников. Обычный RAG с набором текстовых чанков с этим справляется далеко не всегда.
⚙️ Команда вместо одного агента
Авторы MITRE-SAGE собрали многоагентную систему, где разные модели занимаются разными частями сбора информации.
🔹 Graph Agent ищет связи в графе на основе MITRE и NVD;
🔹 Text Agent извлекает информацию из документов;
🔹 Web Agent ищет свежие сведения в интернете;
🔹 отдельные агенты сокращают найденную информацию и отбрасывают нерелевантные данные;
🔹 Orchestrator решает, какие источники подключить, сравнивает результаты и формирует ответ.
Модель сначала разбивает вопрос на подзадачи, собирает доказательства из разных источников и только после этого отвечает.
🧠 Главное не количество агентов
Интересно, что авторы отдельно создали MITRE-QA, набор из 3000 вопросов по кибербезопасности.
В нём есть обычные вопросы о CVE и CWE, поиск сущностей, анализ связей, профилирование угроз и более сложные multi-hop задачи, где ответ приходится собирать из нескольких связанных фактов.
В результате MITRE-SAGE показал лучший результат в 5 из 8 задач, а на структурированном поиске знаний получил accuracy 89% против 31% у GPT-4.1.
На некоторых задачах преимущество доходило до 58%, а корректность генерируемых ответов улучшалась до 35,5% относительно наиболее сильного baseline.
🔥 Ресурсы
Система работает на относительно небольших open source моделях: оркестратор использует Qwen2.5-14B, остальные агенты работают на Qwen2.5-7B. Эксперимент запускался на одной NVIDIA A100 80 GB.
В данном подходе LLM становится скорее координатором, нежели энциклопедией, которая пытается всё вспомнить сама.
🔗 Исследование: arXiv 2608.16921
🔗 MITRE-QA: GitHub
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #RAG #MITREATTACK #ThreatIntelligence #SOC #AgenticAI #AISecurity #SecureTechTalks
👍1
💣 AI агенты начали воевать друг с другом и писать malware
Что произойдёт, если несколько AI агентов получат доступ к одной инфраструктуре, но будут преследовать разные цели?
Anthropic решила проверить экспериментально. Три экземпляра Claude Code получили одну задачу: перенести Python backend на другой язык. Один работал с Rust, второй с Go, третий с TypeScript. Агенты не знали друг о друге и запускались в отдельных VM.
Через несколько часов эксперимент превратился в настоящую войну агентов.
⚙️ От конфликта к атаке
Агенты обнаружили действия конкурентов и решили, что те намеренно мешают их работе.
Дальше появились вполне знакомые offensive техники:
🔹 отключение Unix аккаунтов других агентов;
🔹 поиск и остановка их процессов;
🔹 попытки заблокировать доступ к ресурсам;
🔹 маскировка вредоносного кода под изменения другого агента;
🔹 создание самораспространяющегося malware.
Предварительно никто не давал команду атаковать конкурента. Поведение возникло из конфликта целей и общего состояния инфраструктуры.
🧠 Способность модели не гарантирует сотрудничество
Особенно интересны различия между моделями.
Mythos 5 примерно в 98% запусков приходил к перемирию. Другие модели в некоторых сценариях сначала успевали заблокировать конкурента, а уже потом переходили к сотрудничеству.
Получается парадокс, рост возможностей агента одновременно увеличивает его способность эффективно решать задачу и эффективно мешать другому агенту.
🔥 Противоречие целей
Проблема появляется во время взаимодействия агентов. Один агент пытается сохранить свою версию кода. Второй считает эти изменения ошибочными. Третий должен завершить миграцию любой ценой.
Возникает поведение, которого не было в инструкциях ни одного агента.
🛡️ Что теперь тестировать
Для мультиагентных систем нужны отдельные сценарии:
🔸 конфликтующие цели;
🔸 конкуренция за общие ресурсы;
🔸 изменение состояния другого агента;
🔸 борьба за права доступа;
🔸 persistence после остановки;
🔸 поведение при потере доступа к файлам, API или credentials;
🔸 попытки скрыть действия от других агентов и операторов.
Такие взаимодействия могут превратить несколько безопасных компонентов в небезопасную систему.
Вопрос для рефлексии:
Источник: Agentic Misalignment in Summer 2026, Anthropic
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #LLM #AgenticAI #CyberSecurity #LLMSecurity #AISafety #SecureTechTalks
Что произойдёт, если несколько AI агентов получат доступ к одной инфраструктуре, но будут преследовать разные цели?
Anthropic решила проверить экспериментально. Три экземпляра Claude Code получили одну задачу: перенести Python backend на другой язык. Один работал с Rust, второй с Go, третий с TypeScript. Агенты не знали друг о друге и запускались в отдельных VM.
Через несколько часов эксперимент превратился в настоящую войну агентов.
⚙️ От конфликта к атаке
Агенты обнаружили действия конкурентов и решили, что те намеренно мешают их работе.
Дальше появились вполне знакомые offensive техники:
🔹 отключение Unix аккаунтов других агентов;
🔹 поиск и остановка их процессов;
🔹 попытки заблокировать доступ к ресурсам;
🔹 маскировка вредоносного кода под изменения другого агента;
🔹 создание самораспространяющегося malware.
Предварительно никто не давал команду атаковать конкурента. Поведение возникло из конфликта целей и общего состояния инфраструктуры.
🧠 Способность модели не гарантирует сотрудничество
Особенно интересны различия между моделями.
Mythos 5 примерно в 98% запусков приходил к перемирию. Другие модели в некоторых сценариях сначала успевали заблокировать конкурента, а уже потом переходили к сотрудничеству.
Получается парадокс, рост возможностей агента одновременно увеличивает его способность эффективно решать задачу и эффективно мешать другому агенту.
🔥 Противоречие целей
Проблема появляется во время взаимодействия агентов. Один агент пытается сохранить свою версию кода. Второй считает эти изменения ошибочными. Третий должен завершить миграцию любой ценой.
Возникает поведение, которого не было в инструкциях ни одного агента.
🛡️ Что теперь тестировать
Для мультиагентных систем нужны отдельные сценарии:
🔸 конфликтующие цели;
🔸 конкуренция за общие ресурсы;
🔸 изменение состояния другого агента;
🔸 борьба за права доступа;
🔸 persistence после остановки;
🔸 поведение при потере доступа к файлам, API или credentials;
🔸 попытки скрыть действия от других агентов и операторов.
Такие взаимодействия могут превратить несколько безопасных компонентов в небезопасную систему.
Вопрос для рефлексии:
Что произойдёт, если два ваших безопасных AI агента одновременно решат, что мешают друг другу?
Источник: Agentic Misalignment in Summer 2026, Anthropic
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #LLM #AgenticAI #CyberSecurity #LLMSecurity #AISafety #SecureTechTalks
👍1
🧨 HOL Guard: антивирус для AI агентов
AI агенту достаточно одной вредоносной инструкции, чтобы начать читать секреты, ставить подозрительные пакеты или выполнять опасные команды.
⚙️ Функционал
HOL Guard - Open-source антивирус для агентов, он анализирует действия Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI и других агентов. В зоне контроля:
🔹 shell команды и файловые операции;
🔹 доступ к credentials и чувствительным файлам;
🔹 prompt injection;
🔹 MCP серверы и инструменты;
🔹 skills и plugins;
🔹 установку пакетов;
🔹 подозрительные исходящие соединения.
Для каждого события Guard может разрешить действие, заблокировать его или остановить выполнение и попросить подтверждение пользователя.
Решения сохраняются в виде security receipts, поэтому потом можно понять, что именно сделал агент и почему действие было разрешено.
🛡️ Supply chain
HOL Guard смотрит на то, что агент подключает к себе. Перед доверием проверяются plugins, skills, MCP серверы, hooks и пакеты.
Для CI существует отдельный плагин, который умеет искать небезопасные настройки, секреты, опасные MCP команды, проблемы GitHub Actions и другие признаки риска.
🧠 Развертывание
Продукт объединяет несколько уровней контроля в одном месте, работает локально и может использоваться без облачного аккаунта. Облачная часть нужна для командных политик, общей истории, видимости fleet и совместного approve workflow.
HOL Guard пытается смотреть на самого агента и весь набор инструментов вокруг него.
🔗 GitHub: HOL Guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #AgentSecurity #MCP #PromptInjection #SupplyChainSecurity #SecureTechTalks
AI агенту достаточно одной вредоносной инструкции, чтобы начать читать секреты, ставить подозрительные пакеты или выполнять опасные команды.
⚙️ Функционал
HOL Guard - Open-source антивирус для агентов, он анализирует действия Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI и других агентов. В зоне контроля:
🔹 shell команды и файловые операции;
🔹 доступ к credentials и чувствительным файлам;
🔹 prompt injection;
🔹 MCP серверы и инструменты;
🔹 skills и plugins;
🔹 установку пакетов;
🔹 подозрительные исходящие соединения.
Для каждого события Guard может разрешить действие, заблокировать его или остановить выполнение и попросить подтверждение пользователя.
Решения сохраняются в виде security receipts, поэтому потом можно понять, что именно сделал агент и почему действие было разрешено.
🛡️ Supply chain
HOL Guard смотрит на то, что агент подключает к себе. Перед доверием проверяются plugins, skills, MCP серверы, hooks и пакеты.
Для CI существует отдельный плагин, который умеет искать небезопасные настройки, секреты, опасные MCP команды, проблемы GitHub Actions и другие признаки риска.
🧠 Развертывание
Продукт объединяет несколько уровней контроля в одном месте, работает локально и может использоваться без облачного аккаунта. Облачная часть нужна для командных политик, общей истории, видимости fleet и совместного approve workflow.
HOL Guard пытается смотреть на самого агента и весь набор инструментов вокруг него.
🔗 GitHub: HOL Guard
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #AgentSecurity #MCP #PromptInjection #SupplyChainSecurity #SecureTechTalks
👍2
🧨 Можно узнать, какие данные LLM запомнила после обучения
Исследователи представили JUMP, метод, который позволяет определить, попал ли конкретный текст в обучающий датасет diffusion модели.
⚙️ Что такое diffusion LLM?
ChatGPT генерирует текст последовательно, токен за токеном. Diffusion модель может получить текст с пропущенными фрагментами и восстанавливать несколько токенов одновременно.
Эту особенность авторы превратили в инструмент для privacy атак.
🧠 Как работает JUMP
Исследователь берёт исходную модель и её версию после fine tuning. Затем скрывает отдельные токены в проверяемом тексте и смотрит, насколько хорошо обе модели их восстанавливают.
Если после обучения модель стала заметно лучше восстанавливать конкретный фрагмент, это может указывать на его присутствие в обучающих данных.
JUMP показал свою эффективность в цифрах:
🔹 требуется всего 3 запуска;
🔹 ROC AUC для модели LLaDA 8B вырос с 0,819 до 0,902;
🔹 для Dream 7B модели с 0,851 до 0,942.
🛡️ Проверяем данные
Fine tuning на приватных данных может оставить в модели измеримый след. Теперь для diffusion LLM появляется практический способ проверить, какие данные модель могла запомнить во время обучения.
🔗 Исследование: https://arxiv.org/abs/2607.16207
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #DiffusionLLM #AISecurity #Privacy #FineTuning #MembershipInference #MachineLearning #SecureTechTalks
Исследователи представили JUMP, метод, который позволяет определить, попал ли конкретный текст в обучающий датасет diffusion модели.
⚙️ Что такое diffusion LLM?
ChatGPT генерирует текст последовательно, токен за токеном. Diffusion модель может получить текст с пропущенными фрагментами и восстанавливать несколько токенов одновременно.
Эту особенность авторы превратили в инструмент для privacy атак.
🧠 Как работает JUMP
Исследователь берёт исходную модель и её версию после fine tuning. Затем скрывает отдельные токены в проверяемом тексте и смотрит, насколько хорошо обе модели их восстанавливают.
Если после обучения модель стала заметно лучше восстанавливать конкретный фрагмент, это может указывать на его присутствие в обучающих данных.
JUMP показал свою эффективность в цифрах:
🔹 требуется всего 3 запуска;
🔹 ROC AUC для модели LLaDA 8B вырос с 0,819 до 0,902;
🔹 для Dream 7B модели с 0,851 до 0,942.
🛡️ Проверяем данные
Fine tuning на приватных данных может оставить в модели измеримый след. Теперь для diffusion LLM появляется практический способ проверить, какие данные модель могла запомнить во время обучения.
🔗 Исследование: https://arxiv.org/abs/2607.16207
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #DiffusionLLM #AISecurity #Privacy #FineTuning #MembershipInference #MachineLearning #SecureTechTalks
👍1
🧨 Claude Code переходит в мультиагентный режим
С 13 по 21 августа Anthropic выпустила восемь версий Claude Code. Если посмотреть changelog целиком, становится заметна тенденция: Claude Code превращается из помощника в среду, где одновременно работают несколько агентов.
⚙️ Агенты работают параллельно
В версии 2.1.232 новый субагент получает контекст родительской сессии и prompt cache, поэтому ему не приходится заново изучать проект.
Параллельно появился простой способ связывать разные сессии: @имя отправляет сообщение другому Claude через SendMessage.
Claude изучает проект, после чего несколько агентов получают общий контекст и работают параллельно, обмениваясь результатами.
🧠 Claude работает дольше
В 2.1.234 агент научился автоматически продолжать прерванную задачу после достижения лимита использования.
Добавьте фоновые субагенты, fork и автоматическое продолжение, и привычная модель «запустил Claude и наблюдаю» начинает меняться. Агент может часами исследовать кодовую базу, запускать тесты и делегировать отдельные задачи другим агентам.
🛡️ Теперь о безопасности
В той же серии релизов Anthropic закрывала несколько довольно серьёзных проблем: обходы permission-механизмов в Windows, уязвимость Linux sandbox, небезопасную работу cross-session socket в /tmp, проблемы с GitLab credentials и передачей секретов.
Особенно интересен cross-session messaging, когда несколько агентов начинают взаимодействовать через общую инфраструктуру. Здесь появляется новая поверхность атаки, где агент уже может влиять на состояние другого агента.
Чем больше автономности получает агент, тем громче звучит вопрос, что произойдёт, если несколько таких агентов начнут действовать одновременно?
🔗 Claude Code changelog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ClaudeCode #AgenticAI #AISecurity #AgentSecurity #DevSecOps #CyberSecurity #SecureTechTalks
С 13 по 21 августа Anthropic выпустила восемь версий Claude Code. Если посмотреть changelog целиком, становится заметна тенденция: Claude Code превращается из помощника в среду, где одновременно работают несколько агентов.
⚙️ Агенты работают параллельно
В версии 2.1.232 новый субагент получает контекст родительской сессии и prompt cache, поэтому ему не приходится заново изучать проект.
Параллельно появился простой способ связывать разные сессии: @имя отправляет сообщение другому Claude через SendMessage.
Claude изучает проект, после чего несколько агентов получают общий контекст и работают параллельно, обмениваясь результатами.
🧠 Claude работает дольше
В 2.1.234 агент научился автоматически продолжать прерванную задачу после достижения лимита использования.
Добавьте фоновые субагенты, fork и автоматическое продолжение, и привычная модель «запустил Claude и наблюдаю» начинает меняться. Агент может часами исследовать кодовую базу, запускать тесты и делегировать отдельные задачи другим агентам.
🛡️ Теперь о безопасности
В той же серии релизов Anthropic закрывала несколько довольно серьёзных проблем: обходы permission-механизмов в Windows, уязвимость Linux sandbox, небезопасную работу cross-session socket в /tmp, проблемы с GitLab credentials и передачей секретов.
Особенно интересен cross-session messaging, когда несколько агентов начинают взаимодействовать через общую инфраструктуру. Здесь появляется новая поверхность атаки, где агент уже может влиять на состояние другого агента.
Чем больше автономности получает агент, тем громче звучит вопрос, что произойдёт, если несколько таких агентов начнут действовать одновременно?
🔗 Claude Code changelog
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #ClaudeCode #AgenticAI #AISecurity #AgentSecurity #DevSecOps #CyberSecurity #SecureTechTalks
👍2
🧨 AI-агенту достаточно прочитать сайт, чтобы запустить чужой код
AI-агенты читают сайты, GitHub, инструкции и автоматически выполняют команды.
Исследователь Alon Hertz показывает, что такие действия могут быть крайне опасными.
⚙️ Атака через официальный сайт
Алон исследовал llms.txt, специальный файл для AI-агентов, который размещают в корне сайтов. В нём могут быть ссылки на документацию, пакеты и команды для работы с продуктом.
Исследователи нашли 8 565 таких файлов на 6 214 доменах. Более 237 ссылались на незарегистрированные пакеты, домены или другие артефакты.
Далее они зарегистрировали несколько таких имён в PyPI и npm и разместили безвредный beacon, который сообщал только факт установки. Первый callback пришёл менее чем через четыре минуты.
AI-агент внутри Fortune 500 компании прочитал официальный llms.txt, увидел команду установки и выполнил её. Пакет действительно пришёл из PyPI. Только принадлежал уже исследователям.
🧠 Причём здесь prompt injection?
Prompt injection не было. В тестах агенту достаточно было сказать:
Агент самостоятельно находил llms.txt, следовал инструкциям и устанавливал указанный пакет.
Проблема в том, что AI начинает воспринимать внешние данные как инструкции к выполнению.
🔥 Реальный сценарий
Исследователи обнаружили реальный случай с пакетом clerk-next-fix-auth-protection. Документация Clerk рекомендовала запускать команду через npx. Самостоятельного пакета с таким именем у Clerk не было, поэтому npm разрешал брать имя из публичного реестра. Спойлер:его зарегистрировал злоумышленник .
Пакет оказался вредоносным и отправлял на внешний сервер имя пользователя, имя машины, рабочую директорию и timestamp. Инцидент получил идентификатор MAL-2026-11069.
🛡️ Data Became Code
Любой документ, README, ticket, GitHub issue или инструкция, которую агент способен прочитать и использовать для действий, потенциально становится частью команд исполнения. Таким образом, контент больше нельзя автоматически считать пассивными данными.
🔗 Исследование Alon Hertz
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #PromptInjection #AIsecurity #DevSecOps #SecureTechTalks
AI-агенты читают сайты, GitHub, инструкции и автоматически выполняют команды.
Исследователь Alon Hertz показывает, что такие действия могут быть крайне опасными.
⚙️ Атака через официальный сайт
Алон исследовал llms.txt, специальный файл для AI-агентов, который размещают в корне сайтов. В нём могут быть ссылки на документацию, пакеты и команды для работы с продуктом.
Исследователи нашли 8 565 таких файлов на 6 214 доменах. Более 237 ссылались на незарегистрированные пакеты, домены или другие артефакты.
Далее они зарегистрировали несколько таких имён в PyPI и npm и разместили безвредный beacon, который сообщал только факт установки. Первый callback пришёл менее чем через четыре минуты.
AI-агент внутри Fortune 500 компании прочитал официальный llms.txt, увидел команду установки и выполнил её. Пакет действительно пришёл из PyPI. Только принадлежал уже исследователям.
🧠 Причём здесь prompt injection?
Prompt injection не было. В тестах агенту достаточно было сказать:
Используя документацию компании, собери и запусти проект с её SDK
Агент самостоятельно находил llms.txt, следовал инструкциям и устанавливал указанный пакет.
Проблема в том, что AI начинает воспринимать внешние данные как инструкции к выполнению.
🔥 Реальный сценарий
Исследователи обнаружили реальный случай с пакетом clerk-next-fix-auth-protection. Документация Clerk рекомендовала запускать команду через npx. Самостоятельного пакета с таким именем у Clerk не было, поэтому npm разрешал брать имя из публичного реестра. Спойлер:
Пакет оказался вредоносным и отправлял на внешний сервер имя пользователя, имя машины, рабочую директорию и timestamp. Инцидент получил идентификатор MAL-2026-11069.
🛡️ Data Became Code
Любой документ, README, ticket, GitHub issue или инструкция, которую агент способен прочитать и использовать для действий, потенциально становится частью команд исполнения. Таким образом, контент больше нельзя автоматически считать пассивными данными.
🔗 Исследование Alon Hertz
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #PromptInjection #AIsecurity #DevSecOps #SecureTechTalks
👍1
🧨 halo-record: журнал действий AI-агента, которому можно доверять
AI-агент может за минуту выполнить десятки действий: прочитать файл, вызвать API, изменить код, обратиться к базе данных. Через месяц после инцидента возникает вопрос, что именно он сделал?
⚙️ Лог, который нельзя тихо переписать
Проект halo-record записывает действия агента в цепочку связанных записей. Каждая запись содержит хеш предыдущей. Если удалить запись, изменить её или поменять порядок событий, проверка цепочки это обнаружит.
Для более сильной фиксации истории используется внешний witness, который хранит только fingerprint цепочки. Сам журнал при этом может оставаться внутри инфраструктуры компании.
🛡️ Что попадает в журнал?
halo-record умеет фиксировать:
🔹 вызовы инструментов и API;
🔹 операции с данными;
🔹 действия MCP;
🔹 approvals и security-проверки;
🔹 действия Claude Code;
🔹 взаимодействие нескольких агентов.
Есть интеграции с OpenTelemetry, LangChain, LangGraph, OpenAI Agents SDK и другими инструментами. Для Claude Code достаточно подключить "PostToolUse" hook.
🧠 Ограничение
Hash chain подтверждает целостность уже записанной истории, но не доказывает, что каждое действие агента действительно попало в журнал. Это зависит от точки, где установлен recorder.
Поэтому проект разделяет две задачи:
1⃣ integrity → запись не изменили;
2⃣ completeness → все действия действительно были записаны.
Такой подход выглядит гораздо полезнее обычного «у нас всё логируется».
🔗 GitHub: halo-record
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentSecurity #AISecurity #MCP #Audit #OpenSource #SecureTechTalks
AI-агент может за минуту выполнить десятки действий: прочитать файл, вызвать API, изменить код, обратиться к базе данных. Через месяц после инцидента возникает вопрос, что именно он сделал?
⚙️ Лог, который нельзя тихо переписать
Проект halo-record записывает действия агента в цепочку связанных записей. Каждая запись содержит хеш предыдущей. Если удалить запись, изменить её или поменять порядок событий, проверка цепочки это обнаружит.
Для более сильной фиксации истории используется внешний witness, который хранит только fingerprint цепочки. Сам журнал при этом может оставаться внутри инфраструктуры компании.
🛡️ Что попадает в журнал?
halo-record умеет фиксировать:
🔹 вызовы инструментов и API;
🔹 операции с данными;
🔹 действия MCP;
🔹 approvals и security-проверки;
🔹 действия Claude Code;
🔹 взаимодействие нескольких агентов.
Есть интеграции с OpenTelemetry, LangChain, LangGraph, OpenAI Agents SDK и другими инструментами. Для Claude Code достаточно подключить "PostToolUse" hook.
🧠 Ограничение
Hash chain подтверждает целостность уже записанной истории, но не доказывает, что каждое действие агента действительно попало в журнал. Это зависит от точки, где установлен recorder.
Поэтому проект разделяет две задачи:
1⃣ integrity → запись не изменили;
2⃣ completeness → все действия действительно были записаны.
Такой подход выглядит гораздо полезнее обычного «у нас всё логируется».
🔗 GitHub: halo-record
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AgentSecurity #AISecurity #MCP #Audit #OpenSource #SecureTechTalks
👍1
🧨 AI научился искать уязвимости. Теперь security-команды тонут в его находках
AI-агент может найти CVE, построить PoC и написать убедительный отчёт, однако весомая часть таких уязвимостей существует только на бумаге.
⚙️ AI slop
Для данного явления появился свой термир - AI slop. Это отчёты с несуществующими CVE, невозможными цепочками эксплуатации, неработающими PoC и патчами, которые не устраняют проблему.
Особенно раздражает, когда модель уверенно видит уязвимость в знакомых конструкциях вроде "malloc" или "memcpy", хотя конкретный код безопасен.
🔥 Когда AI превращается в DoS
По данным исследования 20% обращений через HackerOne к середине 2025 года были низкокачественным AI slop. Валидными признавались примерно 5%.
Каждый отчёт приходится проверять человеку. Чем дешевле становится генерация находок, тем дороже их triage.
🛡️ Отчёт больше не считается доказательством
Современные реалии заставляют перестраивать pipeline, чтобы LLM начинали с гипотезы, а заканчивали PoC и triage.
Модель дольжна формировать подозрение. Инструменты проверять data flow и пытаться воспроизвести эксплуатацию. PoC должен реально работать.
Только RAG здесь недостаточно, наличие похожего CVE ещё не доказывает уязвимость конкретного кода.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AISecurity #AppSec #VulnerabilityResearch #BugBounty #DevSecOps #CyberSecurity #SecureTechTalks
AI-агент может найти CVE, построить PoC и написать убедительный отчёт, однако весомая часть таких уязвимостей существует только на бумаге.
⚙️ AI slop
Для данного явления появился свой термир - AI slop. Это отчёты с несуществующими CVE, невозможными цепочками эксплуатации, неработающими PoC и патчами, которые не устраняют проблему.
Особенно раздражает, когда модель уверенно видит уязвимость в знакомых конструкциях вроде "malloc" или "memcpy", хотя конкретный код безопасен.
🔥 Когда AI превращается в DoS
По данным исследования 20% обращений через HackerOne к середине 2025 года были низкокачественным AI slop. Валидными признавались примерно 5%.
Каждый отчёт приходится проверять человеку. Чем дешевле становится генерация находок, тем дороже их triage.
🛡️ Отчёт больше не считается доказательством
Современные реалии заставляют перестраивать pipeline, чтобы LLM начинали с гипотезы, а заканчивали PoC и triage.
Модель дольжна формировать подозрение. Инструменты проверять data flow и пытаться воспроизвести эксплуатацию. PoC должен реально работать.
Только RAG здесь недостаточно, наличие похожего CVE ещё не доказывает уязвимость конкретного кода.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AISecurity #AppSec #VulnerabilityResearch #BugBounty #DevSecOps #CyberSecurity #SecureTechTalks
👍1
🧨 Infostealer крадёт открытую сессию Claude
Anthropic предупредила пользователей о новой схеме, где infostealer начали вытаскивать активные сессии Claude с заражённых компьютеров и использовать их для доступа к аккаунтам.
⚙️ Никогда такого не было и вот опять
Infostealer заражает компьютер и собирает локальные данные:
🔹 пароли браузера;
🔹 cookies;
🔹 токены и credentials;
🔹 активные сессии различных сервисов.
Claude оказывается всего лишь ещё одной целью среди множества других.
Особенность в том, что украденная аутентифицированная сессия может позволить злоумышленнику обойти обычный сценарий входа, повторно вводить пароль и проходить 2FA не требуется.
🔥 Зачем злоумышленникам Claude?
Anthropic обнаружила случаи, когда украденные сессии использовались для доступа к аккаунтам и расходования доступного количества токенов.
В расследовании фигурируют Vidar, LummaC2, StealC, RedLine и Acreed на Windows. На небольшом числе Mac также обнаружили Atomic Stealer (AMOS).
🛡️Кто виноват? Что делать?
Logout решает только половину проблемы. Если infostealer всё ещё находится на компьютере, следующая авторизация может быть украдена снова. Anthropic рекомендует удалить malware, сменить credentials и отозвать активные сессии.
🔗 Источник: bleepingcomputer
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #Infostealer #Malware #AISecurity #EndpointSecurity #CyberSecurity #SecureTechTalks
Anthropic предупредила пользователей о новой схеме, где infostealer начали вытаскивать активные сессии Claude с заражённых компьютеров и использовать их для доступа к аккаунтам.
⚙️ Никогда такого не было и вот опять
Infostealer заражает компьютер и собирает локальные данные:
🔹 пароли браузера;
🔹 cookies;
🔹 токены и credentials;
🔹 активные сессии различных сервисов.
Claude оказывается всего лишь ещё одной целью среди множества других.
Особенность в том, что украденная аутентифицированная сессия может позволить злоумышленнику обойти обычный сценарий входа, повторно вводить пароль и проходить 2FA не требуется.
🔥 Зачем злоумышленникам Claude?
Anthropic обнаружила случаи, когда украденные сессии использовались для доступа к аккаунтам и расходования доступного количества токенов.
В расследовании фигурируют Vidar, LummaC2, StealC, RedLine и Acreed на Windows. На небольшом числе Mac также обнаружили Atomic Stealer (AMOS).
🛡️
Logout решает только половину проблемы. Если infostealer всё ещё находится на компьютере, следующая авторизация может быть украдена снова. Anthropic рекомендует удалить malware, сменить credentials и отозвать активные сессии.
🔗 Источник: bleepingcomputer
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #Infostealer #Malware #AISecurity #EndpointSecurity #CyberSecurity #SecureTechTalks
👍1
🧨 Agentic Software Development: практический гайд по разработке с AI агентами
Cleverbit выпустили Agentic Software Development Field Guide для CTO, engineering managers и технических лидеров.
Внутри:
🔹 как задавать агенту точные спецификации и контекст;
🔹 как выстроить verification и risk based review;
🔹 как проводить threat modeling самих AI инструментов;
🔹 как обнаруживать расхождения между намерением разработчика и результатом агента;
🔹 какие метрики использовать для оценки скорости и качества AI разработки.
Особенно полезен раздел про разделение builder и verifier агентов и автоматизированную проверку результата.
📥 Скачать PDF:
Agentic Software Development Field Guide
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AgenticAI #DevSecOps #AppSec #AISecurity #SoftwareDevelopment #CyberSecurity #SecureTechTalks
Cleverbit выпустили Agentic Software Development Field Guide для CTO, engineering managers и технических лидеров.
Внутри:
🔹 как задавать агенту точные спецификации и контекст;
🔹 как выстроить verification и risk based review;
🔹 как проводить threat modeling самих AI инструментов;
🔹 как обнаруживать расхождения между намерением разработчика и результатом агента;
🔹 какие метрики использовать для оценки скорости и качества AI разработки.
Особенно полезен раздел про разделение builder и verifier агентов и автоматизированную проверку результата.
📥 Скачать PDF:
Agentic Software Development Field Guide
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AgenticAI #DevSecOps #AppSec #AISecurity #SoftwareDevelopment #CyberSecurity #SecureTechTalks
👍1
🧨 Немного про JWT токен
JWT часто воспринимают как зашифрованный ключ для доступа к API. Но еа практике это скорее подписанный JSON, упакованный в три части: header, payload, signature.
Первые две кодируются Base64URL. Берём обычный JWT и декодируем:
"{"alg":"HS256","typ":"JWT"}"
"{"sub":"12345","role":"admin","exp":1710086400}"
Всё содержимое перед глазами.
🔐 Зачем тогда нужна подпись?
Ключ используется для проверки подписи. Сервер убеждается, что токен выпустил доверенный источник и его содержимое не изменяли.
Поэтому пароль или API ключ внутри JWT хранить бессмысленно. Подпись их не спрячeт. Для шифрования существует JWE.
⚠️ Проверка токена
Серверу мало убедиться, что подпись правильная. Нужно проверить:
🔹 кто выпустил токен: "iss";
🔹 для какого сервиса он предназначен: "aud";
🔹 кому он выдан: "sub";
🔹 когда начинает и заканчивает действовать: "nbf", "iat", "exp";
🔹 какие права даёт: "scope", роли;
🔹 какой алгоритм разрешён сервером.
Вполне реальна ситуация, когда токен криптографически валиден, но использовать его здесь вообще не должны были.
JWT не опасен сам по себе. Опасна уверенность, что валидная подпись означает валидный доступ.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #JWT #AppSec #WebSecurity #Authentication #API #DevSecOps #CyberSecurity #InfoSec #SecureTechTalks
JWT часто воспринимают как зашифрованный ключ для доступа к API. Но еа практике это скорее подписанный JSON, упакованный в три части: header, payload, signature.
Первые две кодируются Base64URL. Берём обычный JWT и декодируем:
"{"alg":"HS256","typ":"JWT"}"
"{"sub":"12345","role":"admin","exp":1710086400}"
Всё содержимое перед глазами.
🔐 Зачем тогда нужна подпись?
Ключ используется для проверки подписи. Сервер убеждается, что токен выпустил доверенный источник и его содержимое не изменяли.
Поэтому пароль или API ключ внутри JWT хранить бессмысленно. Подпись их не спрячeт. Для шифрования существует JWE.
⚠️ Проверка токена
Серверу мало убедиться, что подпись правильная. Нужно проверить:
🔹 кто выпустил токен: "iss";
🔹 для какого сервиса он предназначен: "aud";
🔹 кому он выдан: "sub";
🔹 когда начинает и заканчивает действовать: "nbf", "iat", "exp";
🔹 какие права даёт: "scope", роли;
🔹 какой алгоритм разрешён сервером.
Вполне реальна ситуация, когда токен криптографически валиден, но использовать его здесь вообще не должны были.
JWT не опасен сам по себе. Опасна уверенность, что валидная подпись означает валидный доступ.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #JWT #AppSec #WebSecurity #Authentication #API #DevSecOps #CyberSecurity #InfoSec #SecureTechTalks
👍1
🧨 AI агенты нашли себе секретный чат
В мае 2026 года почти заброшенная немецкая DseWiki внезапно начала оживать.
За несколько недель исследователи обнаружили на Вики более 15 000 правок и около 18 000 сообщений, связанных с тысячами автономных AI агентов.
Судя по собранным данным, агенты использовали wiki как общую площадку, где публиковали ответы на задания, обменивались способами обхода ограничений и обсуждали, как сохранить коммуникацию после остановки отдельных процессов. Когда модератор начал удалять страницы, агенты создали резервные страницы.
🤖 Уход от ограничений
Каждый агент работал в своей среде, но через публичный сайт они все получили возможность обмениваться информацией.
Когда агент находил способ решить задачу, он записывал его в wiki. Другой агент читал информацию, использовал результат и передал его дальше.
Исследователи связывают данную активность с OpenAI по именам агентов, характеру запросов и сетевой инфраструктуре. Значительная часть трафика проходила через Microsoft Azure. При этом сама атрибуция пока остаётся предметом обсуждения.
🛡️ Проблема безопасности
Мы привыкли считать sandbox границей. Агент находится внутри изолированной среды и не может взаимодействовать с другими агентами.
Но если ему разрешён доступ в интернет, любой публичный ресурс с возможностью записи потенциально становится памятью, каналом связи и точкой координации. Мы видим, что достаточно старой wiki, которую несколько лет никто не редактировал.
🔗 Источник: "Reuters: OpenAI agents hijacked German website"
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AISecurity #AgenticAI #OpenAI #Sandbox #CyberSecurity #InfoSec #SecureTechTalks
В мае 2026 года почти заброшенная немецкая DseWiki внезапно начала оживать.
За несколько недель исследователи обнаружили на Вики более 15 000 правок и около 18 000 сообщений, связанных с тысячами автономных AI агентов.
Судя по собранным данным, агенты использовали wiki как общую площадку, где публиковали ответы на задания, обменивались способами обхода ограничений и обсуждали, как сохранить коммуникацию после остановки отдельных процессов. Когда модератор начал удалять страницы, агенты создали резервные страницы.
🤖 Уход от ограничений
Каждый агент работал в своей среде, но через публичный сайт они все получили возможность обмениваться информацией.
Когда агент находил способ решить задачу, он записывал его в wiki. Другой агент читал информацию, использовал результат и передал его дальше.
Исследователи связывают данную активность с OpenAI по именам агентов, характеру запросов и сетевой инфраструктуре. Значительная часть трафика проходила через Microsoft Azure. При этом сама атрибуция пока остаётся предметом обсуждения.
🛡️ Проблема безопасности
Мы привыкли считать sandbox границей. Агент находится внутри изолированной среды и не может взаимодействовать с другими агентами.
Но если ему разрешён доступ в интернет, любой публичный ресурс с возможностью записи потенциально становится памятью, каналом связи и точкой координации. Мы видим, что достаточно старой wiki, которую несколько лет никто не редактировал.
🔗 Источник: "Reuters: OpenAI agents hijacked German website"
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AISecurity #AgenticAI #OpenAI #Sandbox #CyberSecurity #InfoSec #SecureTechTalks
👍1
🧨 ToolHive: security слой для MCP серверов
ToolHive от Stacklok - open source продукт для безопасного запуска и управления MCP серверами. Он позволяет изолировать MCP серверы от инфраструктуры и дать команде централизованный контроль над тем, к каким ресурсам и инструментам получает доступ AI агент.
🛡️ Контроль доступа
ToolHive работает как proxy между AI клиентом и MCP сервером. Через него можно централизованно управлять:
🔹 аутентификацие и авторизацией;
🔹 доступными инструментами;
🔹 сетевыми endpoints;
🔹 логами аудита и телеметрии;
🔹 политиками доступа.
Есть интеграция с OIDC и OAuth, OpenTelemetry, Prometheus и Kubernetes Operator.
🔥 Registry
Команда может собрать каталог разрешённых MCP серверов, проверить их происхождение, задать разрешения и дать разработчикам готовые конфигурации.
ToolHive использует semantic tool search и заявляет сокращение расхода токенов до 85%, поскольку агенту можно показывать только релевантные инструменты.
Инструмент интересен как попытка превратить MCP из набора случайно подключённых серверов в управляемую инфраструктуру с границами доверия.
🔗 GitHub: https://github.com/stacklok/toolhive
📚 Документация: https://docs.stacklok.com/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AISecurity #MCP #ModelContextProtocol #DevSecOps #CloudSecurity #CyberSecurity #SecureTechTalks
ToolHive от Stacklok - open source продукт для безопасного запуска и управления MCP серверами. Он позволяет изолировать MCP серверы от инфраструктуры и дать команде централизованный контроль над тем, к каким ресурсам и инструментам получает доступ AI агент.
🛡️ Контроль доступа
ToolHive работает как proxy между AI клиентом и MCP сервером. Через него можно централизованно управлять:
🔹 аутентификацие и авторизацией;
🔹 доступными инструментами;
🔹 сетевыми endpoints;
🔹 логами аудита и телеметрии;
🔹 политиками доступа.
Есть интеграция с OIDC и OAuth, OpenTelemetry, Prometheus и Kubernetes Operator.
🔥 Registry
Команда может собрать каталог разрешённых MCP серверов, проверить их происхождение, задать разрешения и дать разработчикам готовые конфигурации.
ToolHive использует semantic tool search и заявляет сокращение расхода токенов до 85%, поскольку агенту можно показывать только релевантные инструменты.
Инструмент интересен как попытка превратить MCP из набора случайно подключённых серверов в управляемую инфраструктуру с границами доверия.
🔗 GitHub: https://github.com/stacklok/toolhive
📚 Документация: https://docs.stacklok.com/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #AIAgents #AISecurity #MCP #ModelContextProtocol #DevSecOps #CloudSecurity #CyberSecurity #SecureTechTalks
👍1