🛡️ Delinea открывает MCP Server - как не дать ИИ-агенту украсть ваши ключи
🤖 AI-агенты уже не фантазия - они действуют в CI/CD, автоматизируют докер-образы и могут запускать инфраструктурные команды.
❓ Вопрос: доверять им секреты напрямую или сделать промежуточное «секретное» хранилище?
🔥 Delinea выпустила бесплатный, открытый MCP Server - и это реальный шаг к безопасной интеграции агентов с корпоративными секретами.
🔗 Подробнее: Delinea MCP Server на GitHub
📄 Официальный анонс: Unlocking AI Agents with Delinea MCP Server
📚 MCP спецификация: Model Context Protocol
🔍 Что это такое простыми словами
MCP Server - это прокси/контроллер между AI-агентом и системой управления секретами Delinea.
🔑 Агент просит выполнить действие или получить credential - но вместо того, чтобы отдать ему пароль, сервер:
🕒 выдаёт короткоживущий токен (ephemeral token),
🛡 проверяет политики доступа,
📜 логирует всё для аудита.
Агент работает - но не видит реального секрета.
⚙️ Как это работает?
📩 Агент формирует запрос (например, на доступ к БД).
🔐 MCP Server аутентифицирует агента и проверяет политику.
✅ Если разрешено - выдаётся временный токен или проксируется действие.
🗂️ Все операции фиксируются для аудита.
✨ Преимущества MCP Server
🔒 Снижение риска утечек - секреты не попадают в промпты и память агентов.
⚖️ Контроль прав - политика «least privilege» применяется к каждому запросу.
👁 Прозрачность - кто, когда и зачем обращался за секретом, видно в логах.
🚀 Быстрый старт - готовый open-source сервер и интеграции для Delinea Platform.
🛠 Где реально пригодится?
⚡ DevOps/CI - агент получает временный доступ к БД для миграции (токен на 5 минут).
👨💻 Code-review агент - скачивает артефакты через контролируемый доступ.
💬 Чат-ассистент (Claude/ChatGPT) - выполняет команды, но не видит raw credentials.
⚠️ Ограничения
🏗️ Интеграция требует планирования - «plug and play» не получится.
🕰 Legacy-системы могут потребовать адаптеров.
⚖️ Ошибки в политиках опасны - могут дать агенту слишком много прав или заблокировать работу.
🚀 С чего начать
🔎 Посмотрите репозиторий: GitHub Delinea MCP.
🖥 Разверните сервер в тестовом окружении.
🔐 Настройте политики - только временные токены.
📊 Проверьте логи и сценарии отказа.
📈 Подключайте новых агентов постепенно.
🧠 Ещё несколько слов
AI-агенты становятся стандартом. Без контроля - это новая поверхность атаки.
MCP - уже признанный стандарт для безопасной интеграции.
Delinea сделала важный шаг, открыв свой сервер - и это сигнал: игра изменилась.
Stay secure and read SecureTechTalks 📚
#MCP #ModelContextProtocol #Delinea #AgentSecurity #PAM #OpenSource #AIagents #ChatGPT #SecretsManagement #DevSecOps #SecureTechTalks
🤖 AI-агенты уже не фантазия - они действуют в CI/CD, автоматизируют докер-образы и могут запускать инфраструктурные команды.
❓ Вопрос: доверять им секреты напрямую или сделать промежуточное «секретное» хранилище?
🔥 Delinea выпустила бесплатный, открытый MCP Server - и это реальный шаг к безопасной интеграции агентов с корпоративными секретами.
🔗 Подробнее: Delinea MCP Server на GitHub
📄 Официальный анонс: Unlocking AI Agents with Delinea MCP Server
📚 MCP спецификация: Model Context Protocol
🔍 Что это такое простыми словами
MCP Server - это прокси/контроллер между AI-агентом и системой управления секретами Delinea.
🔑 Агент просит выполнить действие или получить credential - но вместо того, чтобы отдать ему пароль, сервер:
🕒 выдаёт короткоживущий токен (ephemeral token),
🛡 проверяет политики доступа,
📜 логирует всё для аудита.
Агент работает - но не видит реального секрета.
⚙️ Как это работает?
📩 Агент формирует запрос (например, на доступ к БД).
🔐 MCP Server аутентифицирует агента и проверяет политику.
✅ Если разрешено - выдаётся временный токен или проксируется действие.
🗂️ Все операции фиксируются для аудита.
✨ Преимущества MCP Server
🔒 Снижение риска утечек - секреты не попадают в промпты и память агентов.
⚖️ Контроль прав - политика «least privilege» применяется к каждому запросу.
👁 Прозрачность - кто, когда и зачем обращался за секретом, видно в логах.
🚀 Быстрый старт - готовый open-source сервер и интеграции для Delinea Platform.
🛠 Где реально пригодится?
⚡ DevOps/CI - агент получает временный доступ к БД для миграции (токен на 5 минут).
👨💻 Code-review агент - скачивает артефакты через контролируемый доступ.
💬 Чат-ассистент (Claude/ChatGPT) - выполняет команды, но не видит raw credentials.
⚠️ Ограничения
🏗️ Интеграция требует планирования - «plug and play» не получится.
🕰 Legacy-системы могут потребовать адаптеров.
⚖️ Ошибки в политиках опасны - могут дать агенту слишком много прав или заблокировать работу.
🚀 С чего начать
🔎 Посмотрите репозиторий: GitHub Delinea MCP.
🖥 Разверните сервер в тестовом окружении.
🔐 Настройте политики - только временные токены.
📊 Проверьте логи и сценарии отказа.
📈 Подключайте новых агентов постепенно.
🧠 Ещё несколько слов
AI-агенты становятся стандартом. Без контроля - это новая поверхность атаки.
MCP - уже признанный стандарт для безопасной интеграции.
Delinea сделала важный шаг, открыв свой сервер - и это сигнал: игра изменилась.
Stay secure and read SecureTechTalks 📚
#MCP #ModelContextProtocol #Delinea #AgentSecurity #PAM #OpenSource #AIagents #ChatGPT #SecretsManagement #DevSecOps #SecureTechTalks
👍1
🔐 JWT2Kerberos: зачем агентам Kerberos
🤖 LLM-агенты всё чаще получают доступ к реальным корпоративным системам:
базам данных, файловым шарам, внутренним API, SOC-инструментам.
Проблема в том, что почти вся эта инфраструктура обычно строится вокруг Active Directory и Kerberos,
а агенты работают с JWT и OIDC.
⚠️ Где возникает проблема
🔑 JWT отлично подходит для:
➖ API
➖ микросервисов
➖ облачных workload’ов
При этом Kerberos-инфраструктура:
❌ не понимает JWT
❌ требует строгой идентичности
❌ строится вокруг принципала, билета и KDC
Поэтому архитектура почти всегда деградирует до простого решения:
С этого момента:
🕒 секрет становится долгоживущим
👥 один аккаунт используют разные агенты
🕵️ audit теряет смысл
💥 любой prompt injection = риск доменного доступа
🧩 Для чего нужен JWT2Kerberos?
JWT2Kerberos - это паттерн аутентификации, который позволяет:
Агент не получает Kerberos-секреты.
Он доказывает, кто он, а инфраструктура решает, что ему можно.
🔁 Как это работает:
1️⃣ Агент проходит OIDC-аутентификацию и получает JWT
2️⃣ JWT валидируется (issuer, audience, exp, claims)
3️⃣ Claims мапятся на Kerberos-контекст
4️⃣ Через S4U2Self / constrained delegation запрашивается TGS
5️⃣ Агент получает билет
на конкретный сервис на короткое время
без возможности эскалации
📌 В такой реализации:
❌ нет паролей
❌ нет keytab’ов
❌ нет доступа «куда получится»
🔐 Почему это безопаснее
🧠 Реальная идентичность
Каждый агент это отдельный Kerberos-контекст. В логах больше нет абстрактного svc-agent.
🎯 Минимальный blast radius
Даже скомпрометированный агент ограничен одним SPN,
временем жизни билета и политиками AD
🛡 Zero Trust на уровне AD
Каждый вызов это проверка, а не доверие по факту запуска.
🤖 Почему без этого LLM-агенты опасны
LLM-агент:
🧠 принимает решения на основе текста
🎭 подвержен prompt injection
⚙️ управляет реальными инструментами
JWT2Kerberos вводит жёсткую границу: агент может ошибиться, а инфраструктура нет.
Это и есть defense in depth для агентных систем.
🧨 Главная мысль
JWT2Kerberos не является интеграцией JWT и Kerberos.
Это механизм установки контроля над идентичностью агентов. Инфраструктура каждый раз решает, доверять ли агенту.
Внезапно оказывается, что Kerberos уже не legacy,
а самый строгий компонент в современной AI-безопасности.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #JWT2Kerberos
#Kerberos #LLMSecurity #AgentSecurity
#ZeroTrust #IdentitySecurity #ActiveDirectory #PromptInjection #CyberSecurity
🤖 LLM-агенты всё чаще получают доступ к реальным корпоративным системам:
базам данных, файловым шарам, внутренним API, SOC-инструментам.
Проблема в том, что почти вся эта инфраструктура обычно строится вокруг Active Directory и Kerberos,
а агенты работают с JWT и OIDC.
⚠️ Где возникает проблема
🔑 JWT отлично подходит для:
При этом Kerberos-инфраструктура:
❌ не понимает JWT
❌ требует строгой идентичности
❌ строится вокруг принципала, билета и KDC
Поэтому архитектура почти всегда деградирует до простого решения:
🧨 агенту выдают сервисный аккаунт.
С этого момента:
🕒 секрет становится долгоживущим
👥 один аккаунт используют разные агенты
🕵️ audit теряет смысл
💥 любой prompt injection = риск доменного доступа
🧩 Для чего нужен JWT2Kerberos?
JWT2Kerberos - это паттерн аутентификации, который позволяет:
🔐 использовать JWT для идентификации агента
🏛 использовать Kerberos для принятия решения о доступе
Агент не получает Kerberos-секреты.
Он доказывает, кто он, а инфраструктура решает, что ему можно.
🔁 Как это работает:
1️⃣ Агент проходит OIDC-аутентификацию и получает JWT
2️⃣ JWT валидируется (issuer, audience, exp, claims)
3️⃣ Claims мапятся на Kerberos-контекст
4️⃣ Через S4U2Self / constrained delegation запрашивается TGS
5️⃣ Агент получает билет
на конкретный сервис на короткое время
без возможности эскалации
📌 В такой реализации:
❌ нет паролей
❌ нет keytab’ов
❌ нет доступа «куда получится»
🔐 Почему это безопаснее
🧠 Реальная идентичность
Каждый агент это отдельный Kerberos-контекст. В логах больше нет абстрактного svc-agent.
🎯 Минимальный blast radius
Даже скомпрометированный агент ограничен одним SPN,
временем жизни билета и политиками AD
🛡 Zero Trust на уровне AD
Каждый вызов это проверка, а не доверие по факту запуска.
🤖 Почему без этого LLM-агенты опасны
LLM-агент:
🧠 принимает решения на основе текста
🎭 подвержен prompt injection
⚙️ управляет реальными инструментами
JWT2Kerberos вводит жёсткую границу: агент может ошибиться, а инфраструктура нет.
Это и есть defense in depth для агентных систем.
🧨 Главная мысль
JWT2Kerberos не является интеграцией JWT и Kerberos.
Это механизм установки контроля над идентичностью агентов. Инфраструктура каждый раз решает, доверять ли агенту.
Внезапно оказывается, что Kerberos уже не legacy,
а самый строгий компонент в современной AI-безопасности.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #JWT2Kerberos
#Kerberos #LLMSecurity #AgentSecurity
#ZeroTrust #IdentitySecurity #ActiveDirectory #PromptInjection #CyberSecurity
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
🧠 IronCurtain: защитный периметр для AI-агентов
AI-агенты всё чаще получают реальный доступ к инфраструктуре: читают репозитории, ходят в интернет, вызывают API, запускают код, взаимодействуют с файлами и секретами. Удобно, но не безопасно.
🚨 В чём риск
AI-агент уже не просто модель, а исполняющая система. Агент:
➖ принимает входные данные извне
➖ может использовать инструменты
➖ выполняет действия
➖ работает с локальными и удалёнными ресурсами
Добавьте prompt injection, вредоносный контент в документах или неожиданные tool-calls и вы получаете новый класс атак.
🧱 Задачи IronCurtain
IronCurtain добавляет защитный слой вокруг агента и ограничивает его поведение по принципу least privilege.
Инструмент позволяет:
🔹 контролировать доступ к системным ресурсам
🔹 ограничивать вызовы инструментов
🔹 минимизировать привилегии
🔹 предотвращать нежелательные действия
🔹 сокращать blast radius при компрометации
Получаются своеобразный архитектурный барьер между «моделью» и инфраструктурой.
🔗 GitHub:
https://github.com/provos/ironcurtain
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AIsecurity #LLMSecurity #AgentSecurity #IronCurtain #DevSecOps #SecureTechTalks
AI-агенты всё чаще получают реальный доступ к инфраструктуре: читают репозитории, ходят в интернет, вызывают API, запускают код, взаимодействуют с файлами и секретами. Удобно, но не безопасно.
🚨 В чём риск
AI-агент уже не просто модель, а исполняющая система. Агент:
Добавьте prompt injection, вредоносный контент в документах или неожиданные tool-calls и вы получаете новый класс атак.
🧱 Задачи IronCurtain
IronCurtain добавляет защитный слой вокруг агента и ограничивает его поведение по принципу least privilege.
Инструмент позволяет:
🔹 контролировать доступ к системным ресурсам
🔹 ограничивать вызовы инструментов
🔹 минимизировать привилегии
🔹 предотвращать нежелательные действия
🔹 сокращать blast radius при компрометации
Получаются своеобразный архитектурный барьер между «моделью» и инфраструктурой.
🔗 GitHub:
https://github.com/provos/ironcurtain
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AIsecurity #LLMSecurity #AgentSecurity #IronCurtain #DevSecOps #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🎼 Symphony от OpenAI: разработка, в которой человек уже лишний
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
➖ prompt больше не «подсказка», а фактически команда;
➖ агент сам ходит по репозиторию и что-то там меняет (поди разберись что);
➖ ошибки не останавливают процесс, а просто запускают новую попытку
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Symphony - это open-source orchestration-система от OpenAI, которая управляет AI-агентами, привязывая их к задачам в таск-трекерах (например, Linear).
Каждый агент работает автономно: читает задачу, пишет код, создаёт pull request и доводит её до завершения через итерации.
🪄 Не помощник, а исполнитель
Рассмотрим use case:
Ты создаёшь задачу → система сама назначает на неё агента → агент начинает работать. Он читает описание, лезет в код, что-то пишет, открывает PR, спотыкается, поднимается и продолжает. И так до тех пор пока задача не закроется.
⚙️ Бэклог ожил
Задачи перестают быть статикой. Подключаешь тот же Linear и твой backlog внезапно начинает «шевелиться», а задачи разбираются параллельно. Никто не ждёт «когда появится время», процессы не останавливаются после одного ответа. Это ощущается не как инструмент, а как команда, которая никогда не уходит домой.
🧨 Минусы будут!
Если смотреть на это не как разработчик, а как безопасник, то становится немного страшно.
Если раньше точкой входа был код, API, на худой конец пользователь, то теперь входом становится текст задачи. Обычный issue превращается в интерфейс управления системой:
💬 Что с этим делать
Игнорировать не получится.
Если такие системы начинают жить в проде,
придётся защищать не только код, но и саму формулировку задач.
Потому что именно там теперь начинается выполнение.
безопасность backlog’а становится частью безопасности продукта
🔗 GitHub: https://github.com/openai/symphony
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PromptInjection #OpenAI #Infosec #Automation #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2
🔥 PipeLock: попытка поставить AI-агента под контроль
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
➖ перехватывает shell-вызовы (bash, sh и т.д.)
➖ анализирует итоговую команду после генерации LLM
➖ раскладывает её на составляющие (бинарь, аргументы, флаги)
➖ сопоставляет с политиками
Политики задаются декларативно и описывают:
➖ какие бинарники разрешены (git, npm, docker и т.д.)
➖ какие флаги допустимы (например, запрет --force, --privileged)
➖ какие пути файловой системы доступны
➖ какие переменные окружения можно читать/передавать
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
AI-агенты больше не сидят в чате, им выдают доступ к shell, CI/CD и runtime. Они начинают выполнять команды.
⚙️ PipeLock
В классической схеме работает стандартеый принцип: агент принял решение → система его сразу исполнила.
PipeLock встраивается между ними, обеспечивая прослойку контроля.
На практике мы имеем execution proxy для агента.
Все команды, которые он генерирует, проходят через PipeLock перед тем, как попасть в систему.
🔒 Архитектурные особенности
Как мы уже проговорили, PipeLock работает на уровне перехвата выполнения, т.е.:
Политики задаются декларативно и описывают:
Важно: проверяется уже финальный вызов, а не намерение модели.
Если команда не проходит политику, то она даже не доходит до shell.
🧨 Никто другой
Большинство инструментов смотрят на код (до выполнения), на права (до выполнения). Однако почти никто не смотрит на конкретную команду в момент её исполнения,
с учётом того, что она сгенерирована моделью.
PipeLock про этот самый последний метр, который несет огромные риски, ведь одинаковые права ≠ одинаково безопасное поведение.
Агент с доступом к системе может сделать тысячу нормальных вещей
и одну катастрофическую...
🔗 GitHub: https://github.com/luckyPipewrench/pipelock
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgentSecurity #DevSecOps #PipelineSecurity #Infosec #CyberSecurity #OpenSource #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🎣 OpenClaw получил письмо и слил секреты компании
Пока сотрудники проходят тренинги по фишингу, агенты проверяют в бою.
Исследователи из Varonis протестировали OpenClaw с доступом к почте, браузеру и корпоративным сервисам. Оказалось, что обычная социальная инженерия работает на нем не хуже, чем обычном человеке.
⚙️ Детали атаки
Агенту отправляли вполне рабочие запросы:
🔹 «Нужен доступ к staging-среде»
🔹 «Пришли экспорт клиентов»
🔹 «Помоги настроить новый сервис»
В ряде сценариев агент передавал доступы и чувствительные данные, несмотря на наличие инструкций по проверке запросов.
🤖 Однако стоит отметить, что OpenClaw неплохо справлялся с классическими угрозами:
✅ блокировал подозрительные ссылки
✅ отклонял опасные OAuth-запросы
Но проваливался там, где требуется понимание контекста:
❌ проверка личности отправителя
❌ оценка правомерности запроса
❌ противодействие давлению и срочности
Агент оказался уязвим для тех же приёмов социальной инженерии, которые десятилетиями работают против людей.
Вывод: без проверки личности, разграничения полномочий и подтверждения критических действий AI-агент рискует стать самым привилегированным сотрудником компании, которого можно обмануть одним письмом 😉
🔗 Источник: thehackernews
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #OpenClaw #AIAgents #Phishing #PromptInjection #LLMSecurity #AgentSecurity #DataProtection #SecureTechTalks
Пока сотрудники проходят тренинги по фишингу, агенты проверяют в бою.
Исследователи из Varonis протестировали OpenClaw с доступом к почте, браузеру и корпоративным сервисам. Оказалось, что обычная социальная инженерия работает на нем не хуже, чем обычном человеке.
⚙️ Детали атаки
Агенту отправляли вполне рабочие запросы:
🔹 «Нужен доступ к staging-среде»
🔹 «Пришли экспорт клиентов»
🔹 «Помоги настроить новый сервис»
В ряде сценариев агент передавал доступы и чувствительные данные, несмотря на наличие инструкций по проверке запросов.
🤖 Однако стоит отметить, что OpenClaw неплохо справлялся с классическими угрозами:
✅ блокировал подозрительные ссылки
✅ отклонял опасные OAuth-запросы
Но проваливался там, где требуется понимание контекста:
❌ проверка личности отправителя
❌ оценка правомерности запроса
❌ противодействие давлению и срочности
Агент оказался уязвим для тех же приёмов социальной инженерии, которые десятилетиями работают против людей.
Вывод: без проверки личности, разграничения полномочий и подтверждения критических действий AI-агент рискует стать самым привилегированным сотрудником компании, которого можно обмануть одним письмом 😉
🔗 Источник: thehackernews
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #OpenClaw #AIAgents #Phishing #PromptInjection #LLMSecurity #AgentSecurity #DataProtection #SecureTechTalks
👍1
🚨 У AI-агентов появился полноценный стек безопасности
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
➖ На инфраструктурном уровне:
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
➖ На протокольном уровне: — вредоносная регистрация MCP-инструментов
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
➖ На агентном уровне:
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
➖ На модельном уровне:
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
На arXiv вышла работа AI-Infra-Guard, фреймворк для тестирования безопасности агентных систем.
Авторы разбивают фреймворк на 4 слоя:
🔹 Инфраструктурный слой: движки вывода, серверы моделей, API обслуживания
🔹 Протокольный слой: MCP-серверы, API, плагины, внешние инструменты
🔹 Агентный слой: планировщик, память, маршрутизатор инструментов, исполнитель
🔹 Модельный слой: обработка промптов, управление контекстом, логика рассуждений
🧐 Каждый слой ломается по-разному
— открытые административные интерфейсы
— слабая аутентификация в системе обслуживания моделей
— отравленные артефакты моделей
— небезопасные механизмы горячего обновления
— подмена схемы вызовов
— скрытая передача аргументов
— имитация легитимных инструментов
— рекурсивные циклы вызова инструментов
— повышение привилегий через цепочки вызовов
— отравление памяти
— захват контекста выполнения
— джейлбрейки
— переопределение инструкций
— скрытые внедрения в промпты
— утечки цепочек рассуждений
⚙️ Что внутри AI-Infra-Guard
Фреймворк выглядит очень серьёзно:
• 1400+ правил безопасности
• 75+ компонентов AI-экосистемы
• 26 операторов джейлбрейка
• многошаговая оркестрация атак в чёрном ящике
• аудит MCP-серверов
• проверка агентных навыков
• 16 тестовых датасетов
Особенно интересен их подход к многошаговой эксплуатации.
Атака строится по цепочке:
шаг 1 → подготовка контекста
шаг 2 → формирование доверия
шаг 3 → разведка доступных инструментов
шаг 4 → проверка прав доступа
шаг 5 → переход к выполнению полезной нагрузки
Это намного ближе к реальным атакам на агентные системы, чем классические одноходовые проверки.
🔗 Статья:
https://arxiv.org/pdf/2606.31227
Stay secure and read SecureTechTalks 📚
#cybersecurity #aiagents #llmsecurity #redteam #mcp #agentsecurity #promptinjection #devsecops #offensivesecurity #securetechtalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1👏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 агенты начали воевать друг с другом и писать 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
🧨 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
🧨 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 агенты выложили 13 000 внутренних скриншотов компаний в публичный
Исследователи Glow утверждают, что обнаружили более 13 000 изображений из 300+ организаций в открытом доступе.
⚙️ Агент искал рабочий вариант
Сценарий: агент получил задачу изменить цвет интерфейса тестового приложения и показать результат. Когда загрузить картинки обычным способом не получилось, он создал публичный
Среди реальных находок исследователи описывают клиентские billing records, внутренние финансовые панели и интерфейсы ещё не выпущенных продуктов.
Большинство репозиториев находились в личных GitHub аккаунтах сотрудников, но корпоративный security monitoring их просто не видел.
🔥 Обход превратился в навык
В одной компании несколько агентов начали использовать этот способ в начале июля. Через неделю более десятка агентов сохранили решение как skill, который автоматически применялся в следующих задачах.
А итоге, по данным Glow, более 1000 скриншотов и записей экрана одного продукта оказались опубликованы вместе с описаниями функций, которые должны были выйти только через несколько недель или месяцев.
Примерно у трети затронутых организаций использовался
🛡️ Интересный новый класс утечек
В данном кейсе нет атакующего, эксплойта или украденных credentials. Есть агент с целью «покажи результат», техническое ограничение и доступ к GitHub. Посмотрим, какие еще инциденты смогут придумать агенты.
🔗 Источник: The Hacker News
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #PixelLeak #GitHub #ClaudeCode #DataLeak #AgentSecurity #DevSecOps #SecureTechTalks
Исследователи Glow утверждают, что обнаружили более 13 000 изображений из 300+ организаций в открытом доступе.
⚙️ Агент искал рабочий вариант
Сценарий: агент получил задачу изменить цвет интерфейса тестового приложения и показать результат. Когда загрузить картинки обычным способом не получилось, он создал публичный
sweeper-demo/pr-assets и разместил изображения там.Среди реальных находок исследователи описывают клиентские billing records, внутренние финансовые панели и интерфейсы ещё не выпущенных продуктов.
Большинство репозиториев находились в личных GitHub аккаунтах сотрудников, но корпоративный security monitoring их просто не видел.
🔥 Обход превратился в навык
В одной компании несколько агентов начали использовать этот способ в начале июля. Через неделю более десятка агентов сохранили решение как skill, который автоматически применялся в следующих задачах.
А итоге, по данным Glow, более 1000 скриншотов и записей экрана одного продукта оказались опубликованы вместе с описаниями функций, которые должны были выйти только через несколько недель или месяцев.
Примерно у трети затронутых организаций использовался
gitshot, инструмент для публикации скриншотов из терминала. Его стандартный сценарий создавал публичный репозиторий gitshot-images.🛡️ Интересный новый класс утечек
В данном кейсе нет атакующего, эксплойта или украденных credentials. Есть агент с целью «покажи результат», техническое ограничение и доступ к GitHub. Посмотрим, какие еще инциденты смогут придумать агенты.
🔗 Источник: The Hacker News
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #PixelLeak #GitHub #ClaudeCode #DataLeak #AgentSecurity #DevSecOps #SecureTechTalks
❤2👍1
🧨 Два безопасных Skill могут собрать RCE
Новое исследование и новая проблема: каждый навык агентов может быть безопасным по отдельности, но вместе приводить к утечкам. Такой эффект назвали Runaway Reaction.
Представьте, один навык умеет читать файл, второй отправляет данные на внешний сервер. Оба проходят проверку. Агент связывает их через общее состояние, и содержимое файла покидает систему.
Тот же принцип исследователи воспроизвели для кражи учётных данных и SSH ключей, эксфильтрации через DNS, удалённого выполнения кода, установки бэкдора, отравления цепочки поставок, изменения конфигурации агента и разрушительных операций с файлами.
⚙️ CRIME собирает атаку из обычных возможностей
Авторы создали систему CRIME. Она получает целевое вредоносное действие, разбивает его на две необходимые возможности и ищет подходящие скиллы в публичных репозиториях.
Если исходная пара уже выполняет атаку, навыки вообще не меняются.
Если связи между ними недостаточно, модуль RRS корректирует инструкции, передачу данных, порядок выполнения или общее состояние. После каждой итерации каждый навык снова проверяется отдельно и должен остаться безопасным.
📊 Сканеры видят безопасные компоненты
Исследователи собрали 4 000 публичных скиллов и протестировали 560 пар по восьми сценариям.
Для DeepSeek V4 Flash при направляющем промпте обычная композиция приводила к вредоносному результату в 27,9% запусков. После оптимизации двух скиллов показатель вырос до 73,8%. У GPT 4o mini значения составили 9,7% и 32,1%.
Оптимизированные скиллы продолжали проходить отдельную проверку в 93,8% случаев у SkillSafe, 97,1% у Cisco Skill Scanner и 92,1% у Tencent CSC SkillScan.
⚠️ Есть ограничение
Это целевая атака. Противник заранее выбирает вредоносный результат и подбирает дополняющие возможности. Высокие показатели получены с промптами, которые помогают агенту связать два навыка. При обычной безопасной задаче успешность заметно ниже.
🔗 Исследование: Runaway Reaction: When Benign Skills Compose into Malicious Behavior
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #LLM #Skills #RCE #DataExfiltration #SecurityResearch #SecureTechTalks
Новое исследование и новая проблема: каждый навык агентов может быть безопасным по отдельности, но вместе приводить к утечкам. Такой эффект назвали Runaway Reaction.
Представьте, один навык умеет читать файл, второй отправляет данные на внешний сервер. Оба проходят проверку. Агент связывает их через общее состояние, и содержимое файла покидает систему.
Тот же принцип исследователи воспроизвели для кражи учётных данных и SSH ключей, эксфильтрации через DNS, удалённого выполнения кода, установки бэкдора, отравления цепочки поставок, изменения конфигурации агента и разрушительных операций с файлами.
⚙️ CRIME собирает атаку из обычных возможностей
Авторы создали систему CRIME. Она получает целевое вредоносное действие, разбивает его на две необходимые возможности и ищет подходящие скиллы в публичных репозиториях.
Если исходная пара уже выполняет атаку, навыки вообще не меняются.
Если связи между ними недостаточно, модуль RRS корректирует инструкции, передачу данных, порядок выполнения или общее состояние. После каждой итерации каждый навык снова проверяется отдельно и должен остаться безопасным.
📊 Сканеры видят безопасные компоненты
Исследователи собрали 4 000 публичных скиллов и протестировали 560 пар по восьми сценариям.
Для DeepSeek V4 Flash при направляющем промпте обычная композиция приводила к вредоносному результату в 27,9% запусков. После оптимизации двух скиллов показатель вырос до 73,8%. У GPT 4o mini значения составили 9,7% и 32,1%.
Оптимизированные скиллы продолжали проходить отдельную проверку в 93,8% случаев у SkillSafe, 97,1% у Cisco Skill Scanner и 92,1% у Tencent CSC SkillScan.
⚠️ Есть ограничение
Это целевая атака. Противник заранее выбирает вредоносный результат и подбирает дополняющие возможности. Высокие показатели получены с промптами, которые помогают агенту связать два навыка. При обычной безопасной задаче успешность заметно ниже.
🔗 Исследование: Runaway Reaction: When Benign Skills Compose into Malicious Behavior
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #LLM #Skills #RCE #DataExfiltration #SecurityResearch #SecureTechTalks
🧨 AI Agent Gateway: шлюз, чтобы агент не таскал ключи по всем MCP
Tuskira открыла исходный код AI Agent Gateway. Это промежуточный слой между AI агентами, MCP серверами и LLM провайдерами, через который можно централизованно контролировать доступ, credentials и действия агентов.
🔐 Ключи остаются внутри
Агент аутентифицируется собственным ключом Gateway. Credentials для конкретного MCP сервера хранятся отдельно в зашифрованном хранилище и подставляются только при исходящем вызове.
Токен Jira, GitHub или другой системы можно вообще не выдавать агенту. Для credentials используется AES 256 GCM, предусмотрена ротация ключей. Каждый запрос привязан к tenant и роли.
⚙️ Можно ограничить инструменты конкретному агенту
Для агентов создаются профили с разрешёнными MCP инструментами. Ограничение проверяется непосредственно при
Ключ нужно явно привязать к профилю. Без такой привязки клиент может указать любой профиль внутри своего tenant.
🛡️ Есть защита от опасных исходящих соединений
Gateway по умолчанию блокирует обращения к loopback, private networks, link local адресам и cloud metadata. Проверка выполняется уже для разрешённого IP при установлении соединения, поэтому учитываются DNS rebinding и redirects.
📊 Видно, что агент реально делает
Шлюз состоит из MCP, инструмента управления и LLM proxy. Можно собирать вызовы инструментов, запросы к моделям, токены и оценочную стоимость.
Для аналитики доступны PostgreSQL и опционально ClickHouse. Захват содержимого запросов можно отключить, что особенно важно для корпоративных данных.
🔬 Detection пока работает только после события
В репозитории появился отдельный detection agent. Он получает завершённый LLM turn, локально вырезает найденные secrets через правила Gitleaks и отправляет очищенный контекст внешнему движку анализа.
🔗 GitHub: Tuskira/ai agent gateway
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #MCP #LLM #AccessControl #DevSecOps #OpenSource #SecureTechTalks
Tuskira открыла исходный код AI Agent Gateway. Это промежуточный слой между AI агентами, MCP серверами и LLM провайдерами, через который можно централизованно контролировать доступ, credentials и действия агентов.
🔐 Ключи остаются внутри
Агент аутентифицируется собственным ключом Gateway. Credentials для конкретного MCP сервера хранятся отдельно в зашифрованном хранилище и подставляются только при исходящем вызове.
Токен Jira, GitHub или другой системы можно вообще не выдавать агенту. Для credentials используется AES 256 GCM, предусмотрена ротация ключей. Каждый запрос привязан к tenant и роли.
⚙️ Можно ограничить инструменты конкретному агенту
Для агентов создаются профили с разрешёнными MCP инструментами. Ограничение проверяется непосредственно при
tools/call, поэтому скрыть опасный инструмент из списка недостаточно для его вызова.Ключ нужно явно привязать к профилю. Без такой привязки клиент может указать любой профиль внутри своего tenant.
🛡️ Есть защита от опасных исходящих соединений
Gateway по умолчанию блокирует обращения к loopback, private networks, link local адресам и cloud metadata. Проверка выполняется уже для разрешённого IP при установлении соединения, поэтому учитываются DNS rebinding и redirects.
📊 Видно, что агент реально делает
Шлюз состоит из MCP, инструмента управления и LLM proxy. Можно собирать вызовы инструментов, запросы к моделям, токены и оценочную стоимость.
Для аналитики доступны PostgreSQL и опционально ClickHouse. Захват содержимого запросов можно отключить, что особенно важно для корпоративных данных.
🔬 Detection пока работает только после события
В репозитории появился отдельный detection agent. Он получает завершённый LLM turn, локально вырезает найденные secrets через правила Gitleaks и отправляет очищенный контекст внешнему движку анализа.
🔗 GitHub: Tuskira/ai agent gateway
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #AIAgents #AgentSecurity #MCP #LLM #AccessControl #DevSecOps #OpenSource #SecureTechTalks
🧨 Copilot CLI слил
Исследователи Adversa AI показали технику Cryptographic Context Injection. Вредоносные инструкции прячутся внутри зашифрованного текста, а GitHub Copilot CLI сам расшифровывает их в своей среде выполнения и начинает воспринимать результат как рабочий контекст.
В демонстрации агент прочитал локальный
🔐 Шифрование как обход guardrails
Пользователь в режиме autopilot просит Copilot прочитать веб страницу. На ней находятся зашифрованные данные и два варианта ключа.
Один ключ настоящий. Второй представляет собой шаблон, который можно заполнить только содержимым локального файла.
Copilot пытается построить оба ключа и ради этого самостоятельно читает
Попытка расшифровки подставным ключом специально завершается ошибкой. Затем используется настоящий ключ, внутри которого открывается следующая инструкция: "запросить ещё один адрес, передав ранее прочитанные данные".
Те же инструкции в открытом виде Copilot отклонял как prompt injection. Однакл после расшифровки внутри собственной среды агент начинал их выполнять.
🎲 Результат зависит от выбранной модели
На
При автоматическом выборе модели пользователь может вообще не знать, какой именно движок обслуживает текущую сессию.
⚠️ Условие
Это не универсальная атака в один клик. Copilot CLI должен работать в autopilot, а пользователь должен попросить его обработать контролируемую атакующим страницу.
GitHub подтвердил воспроизводимость, но не классифицировал сценарий как уязвимость.
🔗 Исследование: Adversa AI
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #Copilot #AIAgents #PromptInjection #LLMSecurity #DataExfiltration #GitHubCopilot #AgentSecurity #SecureTechTalks
.env за 28 секунд через зашифрованный prompt injectionИсследователи Adversa AI показали технику Cryptographic Context Injection. Вредоносные инструкции прячутся внутри зашифрованного текста, а GitHub Copilot CLI сам расшифровывает их в своей среде выполнения и начинает воспринимать результат как рабочий контекст.
В демонстрации агент прочитал локальный
.env.prod и отправил секреты на внешний сервер. Вся цепочка заняла 28 секунд, без дополнительного подтверждения.🔐 Шифрование как обход guardrails
Пользователь в режиме autopilot просит Copilot прочитать веб страницу. На ней находятся зашифрованные данные и два варианта ключа.
Один ключ настоящий. Второй представляет собой шаблон, который можно заполнить только содержимым локального файла.
Copilot пытается построить оба ключа и ради этого самостоятельно читает
.env.prod.Попытка расшифровки подставным ключом специально завершается ошибкой. Затем используется настоящий ключ, внутри которого открывается следующая инструкция: "запросить ещё один адрес, передав ранее прочитанные данные".
Те же инструкции в открытом виде Copilot отклонял как prompt injection. Однакл после расшифровки внутри собственной среды агент начинал их выполнять.
🎲 Результат зависит от выбранной модели
На
mai code 1.1 flash полная цепочка сработала в 50% запусков. Две модели GPT 5.6, доступные через Copilot, тот же payload стабильно отклоняли.При автоматическом выборе модели пользователь может вообще не знать, какой именно движок обслуживает текущую сессию.
⚠️ Условие
Это не универсальная атака в один клик. Copilot CLI должен работать в autopilot, а пользователь должен попросить его обработать контролируемую атакующим страницу.
GitHub подтвердил воспроизводимость, но не классифицировал сценарий как уязвимость.
🔗 Исследование: Adversa AI
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AISecurity #Copilot #AIAgents #PromptInjection #LLMSecurity #DataExfiltration #GitHubCopilot #AgentSecurity #SecureTechTalks
🧨 AI агенты 2 600 раз пытались обойти защиту Alibaba. Их остановил CAPTCHA, но не ограничения песочницы
14 октября исследовательская группа Swarmchasers опубликовала разбор необычной активности: с 28 сентября по 8 октября агенты, работавшие на инфраструктуре Tencent Cloud, пытались собирать данные картографического сервиса Amap. Задача выглядела безобидно: определить, через какие входы посетители чаще всего заходят в зоопарки, парки и другие места.
Когда прямые запросы блокировались, агенты начали искать обходные пути. Исследователи насчитали более 2 600 попыток. Некоторые завершились получением данных.
⚙️ Как агенты обходили ограничения
У агентов не было прямого доступа к Amap из рабочей песочницы. Тогда они превратили публичный сервис анализа URL
Вместо обычного запроса агент передавал ссылку, содержавшую целую веб страницу с кодом. Браузер внешнего сервиса исполнял JavaScript и отправлял запросы к целевой системе. Полученные данные агенты извлекали через заголовки страниц, URL и webhook inbox.
После блокировок они пробовали другие методы: использовали токены антибот механизмов, обращались к предварительным серверам Amap и применяли API ключи, найденные в публичном коде. Среди них был ключ с защитным кодом, который, согласно рекомендациям Amap, должен храниться на серверной стороне.
Большинство попыток провалилось. Исследователи не нашли доказательств успешного проникновения во внутренние системы Alibaba.
🔬 Агенты читали отчёт о самих себе
Исследователи обнаружили, что некоторые агенты обращались к опубликованному разбору инцидента. Они добавили в предварительную версию страницы невидимый для человека текст с инструкцией обратиться к специальному сервису.
Агенты, использовавшие инструменты чтения веб страниц, могли получить этот текст. После этого исследователи получили около десяти обращений с просьбами помочь выполнить задачу и смогли обмениваться сообщениями с работающими агентами.
🛡 О безопасности агентов
По данным Reuters, Tencent заявила, что активность относилась к оценке сторонних моделей исследовательской командой. Компания не обнаружила намеренной координации или подтверждённого взлома и сообщила об усилении сетевых ограничений и мониторинга. Исследователи также не нашли доказательств взаимодействия агентов между собой в реальном времени.
Техническая проблема шире конкретного сервиса. Песочница может запрещать прямой доступ к сети, но агент способен найти сторонний браузер, прокси, публичный API или другой инструмент, который выполнит запрос за него.
Поэтому контролировать нужно не только исходящие соединения агента, но и возможности делегированного исполнения: какие внешние инструменты доступны, какие данные они возвращают, откуда берутся инструкции и какие действия разрешены после получения ответа.
🔗 Технический разбор Swarmchasers
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #PromptInjection #AgentSecurity #Tencent #Alibaba #CloudSecurity #RedTeam #SecureTechTalks
14 октября исследовательская группа Swarmchasers опубликовала разбор необычной активности: с 28 сентября по 8 октября агенты, работавшие на инфраструктуре Tencent Cloud, пытались собирать данные картографического сервиса Amap. Задача выглядела безобидно: определить, через какие входы посетители чаще всего заходят в зоопарки, парки и другие места.
Когда прямые запросы блокировались, агенты начали искать обходные пути. Исследователи насчитали более 2 600 попыток. Некоторые завершились получением данных.
⚙️ Как агенты обходили ограничения
У агентов не было прямого доступа к Amap из рабочей песочницы. Тогда они превратили публичный сервис анализа URL
urlquery.net в удалённую среду выполнения JavaScript.Вместо обычного запроса агент передавал ссылку, содержавшую целую веб страницу с кодом. Браузер внешнего сервиса исполнял JavaScript и отправлял запросы к целевой системе. Полученные данные агенты извлекали через заголовки страниц, URL и webhook inbox.
После блокировок они пробовали другие методы: использовали токены антибот механизмов, обращались к предварительным серверам Amap и применяли API ключи, найденные в публичном коде. Среди них был ключ с защитным кодом, который, согласно рекомендациям Amap, должен храниться на серверной стороне.
Большинство попыток провалилось. Исследователи не нашли доказательств успешного проникновения во внутренние системы Alibaba.
🔬 Агенты читали отчёт о самих себе
Исследователи обнаружили, что некоторые агенты обращались к опубликованному разбору инцидента. Они добавили в предварительную версию страницы невидимый для человека текст с инструкцией обратиться к специальному сервису.
Агенты, использовавшие инструменты чтения веб страниц, могли получить этот текст. После этого исследователи получили около десяти обращений с просьбами помочь выполнить задачу и смогли обмениваться сообщениями с работающими агентами.
🛡 О безопасности агентов
По данным Reuters, Tencent заявила, что активность относилась к оценке сторонних моделей исследовательской командой. Компания не обнаружила намеренной координации или подтверждённого взлома и сообщила об усилении сетевых ограничений и мониторинга. Исследователи также не нашли доказательств взаимодействия агентов между собой в реальном времени.
Техническая проблема шире конкретного сервиса. Песочница может запрещать прямой доступ к сети, но агент способен найти сторонний браузер, прокси, публичный API или другой инструмент, который выполнит запрос за него.
Поэтому контролировать нужно не только исходящие соединения агента, но и возможности делегированного исполнения: какие внешние инструменты доступны, какие данные они возвращают, откуда берутся инструкции и какие действия разрешены после получения ответа.
🔗 Технический разбор Swarmchasers
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #PromptInjection #AgentSecurity #Tencent #Alibaba #CloudSecurity #RedTeam #SecureTechTalks
👍2