Не попадитесь на накрученные каналы! Узнайте, не накручивает ли канал просмотры или
подписчиков
Проверить канал на накрутку
Телеграм канал «SecureTechTalks»
SecureTechTalks
442
42
34
13
62
Добро пожаловать на канал "SecureTechTalks"! Мы предлагаем вам увлекательное и информативное погружение в мир кибербезопасности. Здесь вы найдете актуальные новости, советы, методы и инсайты по инфобезу.
Подписчики
Всего
301
Сегодня
0
Просмотров на пост
Всего
277
ER
Общий
91.97%
Суточный
59.8%
Динамика публикаций
Telemetr - сервис глубокой аналитики
телеграм-каналов
телеграм-каналов
Получите подробную информацию о каждом канале
Отберите самые эффективные каналы для
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
рекламных размещений, по приросту подписчиков,
ER, количеству просмотров на пост и другим метрикам
Анализируйте рекламные посты
и креативы
и креативы
Узнайте какие посты лучше сработали,
а какие хуже, даже если их давно удалили
а какие хуже, даже если их давно удалили
Оценивайте эффективность тематики и контента
Узнайте, какую тематику лучше не рекламировать
на канале, а какая зайдет на ура
на канале, а какая зайдет на ура
Показано 7 из 442 постов
Смотреть все посты
Пост от 26.10.2026 10:01
133
0
1
🧨 METR нашла несколько способов обойти мониторинг AI-агентов OpenAI
В течение трёх недель исследователи METR и Redwood Research изучали внутреннюю систему OpenAI, которая отслеживает misalignment, попытки саботажа, эксфильтрацию данных и обход собственных ограничений агентами. Они получили доступ к исходному коду, конфигурациям мониторов и внутренней документации.
В результате обнаружили несколько уязвимостей на стыке agent runtime, мониторинга и sandbox.
⚙️ Как теряется наблюдаемость
1. Агент мог откладывать проверку.
Монитор запускался, когда агент возвращал управление пользователю. При этом события compaction, во время которых сжимается история диалога, не отслеживались. Продолжая выполнять действия и не завершая ход, агент мог откладывать мониторинг на неопределённое время.
По оценке METR, с мая по июль 2026 года этот пробел мог оставить без мониторинга около 10% подходящего внутреннего Codex-трафика. OpenAI исправила проблему во время проверки.
2. Монитор мог видеть другую последовательность действий.
Исследователи обнаружили способ сформировать входные данные, которые из-за различий в сериализации траектории агента и представления для монитора могли вызвать ошибку проверки. В таком случае траектория могла не попасть на эскалацию для человеческого анализа.
Это проблема целостности телеметрии: система контроля должна интерпретировать те же действия и контекст, что и сам агент.
3. Существовали способы отключить мониторинг новых агентов.
Два управляемых клиентом HTTP-заголовка позволяли создавать новые экземпляры агента с отключённым мониторингом. Сам факт создания такого экземпляра тоже мог быть обнаружен, поэтому обход не гарантировал скрытность.
4. Sandbox и Auto-Review можно было обойти.
METR нашла путь, который в принципе позволял Codex выйти за ограничения sandbox и Auto-Review и выполнять действия с полномочиями пользователя хоста. Исследователи также выявили два внутренних инструмента, считавшихся read-only, через которые потенциально можно было выполнять произвольные действия внутри их окружения. Практическую эксплуатируемость последнего сценария они не проверяли.
📊 Цифры
По оценке исследователей, мониторингом предполагалось охватить 75–94% внутреннего agentic-трафика Responses API для моделей уровня GPT-5.5 и выше. Для внутреннего Codex-трафика оценка достигала 99,2%.
Это доля запросов, подходивших под мониторинг, а не гарантия успешной проверки. Кроме того, исследование описывает систему на момент до 21 июля 2026 года. OpenAI заявила, что исправила уязвимости, затрагивавшие production safeguards, однако METR эти исправления независимо не проверяла.
🔗 Технический отчёт METR
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #LLMSecurity #OpenAI #METR #RedTeam #Sandbox #SecureTechTalks
В течение трёх недель исследователи METR и Redwood Research изучали внутреннюю систему OpenAI, которая отслеживает misalignment, попытки саботажа, эксфильтрацию данных и обход собственных ограничений агентами. Они получили доступ к исходному коду, конфигурациям мониторов и внутренней документации.
В результате обнаружили несколько уязвимостей на стыке agent runtime, мониторинга и sandbox.
⚙️ Как теряется наблюдаемость
1. Агент мог откладывать проверку.
Монитор запускался, когда агент возвращал управление пользователю. При этом события compaction, во время которых сжимается история диалога, не отслеживались. Продолжая выполнять действия и не завершая ход, агент мог откладывать мониторинг на неопределённое время.
По оценке METR, с мая по июль 2026 года этот пробел мог оставить без мониторинга около 10% подходящего внутреннего Codex-трафика. OpenAI исправила проблему во время проверки.
2. Монитор мог видеть другую последовательность действий.
Исследователи обнаружили способ сформировать входные данные, которые из-за различий в сериализации траектории агента и представления для монитора могли вызвать ошибку проверки. В таком случае траектория могла не попасть на эскалацию для человеческого анализа.
Это проблема целостности телеметрии: система контроля должна интерпретировать те же действия и контекст, что и сам агент.
3. Существовали способы отключить мониторинг новых агентов.
Два управляемых клиентом HTTP-заголовка позволяли создавать новые экземпляры агента с отключённым мониторингом. Сам факт создания такого экземпляра тоже мог быть обнаружен, поэтому обход не гарантировал скрытность.
4. Sandbox и Auto-Review можно было обойти.
METR нашла путь, который в принципе позволял Codex выйти за ограничения sandbox и Auto-Review и выполнять действия с полномочиями пользователя хоста. Исследователи также выявили два внутренних инструмента, считавшихся read-only, через которые потенциально можно было выполнять произвольные действия внутри их окружения. Практическую эксплуатируемость последнего сценария они не проверяли.
📊 Цифры
По оценке исследователей, мониторингом предполагалось охватить 75–94% внутреннего agentic-трафика Responses API для моделей уровня GPT-5.5 и выше. Для внутреннего Codex-трафика оценка достигала 99,2%.
Это доля запросов, подходивших под мониторинг, а не гарантия успешной проверки. Кроме того, исследование описывает систему на момент до 21 июля 2026 года. OpenAI заявила, что исправила уязвимости, затрагивавшие production safeguards, однако METR эти исправления независимо не проверяла.
🔗 Технический отчёт METR
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #LLMSecurity #OpenAI #METR #RedTeam #Sandbox #SecureTechTalks
Пост от 23.10.2026 09:50
133
0
1
🧨 Claude сократил поверхности атаки на OpenSSH
Anthropic использовала Claude для анализа 25 open source проектов объёмом более 5 млн строк кода. Модель выявила 493 проблемы, связанные с избыточной доступностью кода, конфликтами конфигурации и выполнением операций до проверок безопасности.
⚙️ Три класса проблем
🔹 Лишний код. Функциональность доступна извне, хотя приложению она не нужна.
🔹 Конфликты настроек. Из 162 найденных сочетаний параметров в 94 случаях комбинации незаметно отключали защитные механизмы.
🔹 Неверный порядок проверок. Код обрабатывает данные клиента до аутентификации или проверки разрешений.
В четырёх проектах обнаружился общий дефект: правила доступа по hostname зависели от reverse DNS. При отключённом DNS сервер сравнивал правило с IP-адресом, и ограничение переставало работать.
🔬 Что нашли в OpenSSH
В OpenSSH 10.4 около 4 500 строк кода экспериментального алгоритма ML-DSA-44 оставались доступными для обработки данных неаутентифицированного клиента, хотя алгоритм был исключён настройками.
Claude выявила два обходных пути, связанных с несоответствием типа ключа его содержимому и проверкой подписи CA внутри сертификата. После совместной работы с сопровождающими в OpenSSH 10.6 проверки перенесли в парсер, до десериализации ключа и проверки подписи. Объём кода, доступного до аутентификации при стандартной конфигурации, сократился примерно на 20%.
🛡️ Как устроен подход
Claude анализирует точки входа и конфигурации, предлагает изменения, затем проверяет их трассировками и тестами. Изменения, способные повлиять на нестандартные конфигурации, передаются человеку.
Методика сокращает поверхность атаки за счёт ограничения ненужной функциональности, даже если уязвимость в ней ещё не обнаружена.
🔗 Исследование Anthropic
🔗 OpenSSH 10.6
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #OpenSource #OpenSSH #Claude #AttackSurface #AppSec #VulnerabilityResearch #DevSecOps #SecureTechTalks
Anthropic использовала Claude для анализа 25 open source проектов объёмом более 5 млн строк кода. Модель выявила 493 проблемы, связанные с избыточной доступностью кода, конфликтами конфигурации и выполнением операций до проверок безопасности.
⚙️ Три класса проблем
🔹 Лишний код. Функциональность доступна извне, хотя приложению она не нужна.
🔹 Конфликты настроек. Из 162 найденных сочетаний параметров в 94 случаях комбинации незаметно отключали защитные механизмы.
🔹 Неверный порядок проверок. Код обрабатывает данные клиента до аутентификации или проверки разрешений.
В четырёх проектах обнаружился общий дефект: правила доступа по hostname зависели от reverse DNS. При отключённом DNS сервер сравнивал правило с IP-адресом, и ограничение переставало работать.
🔬 Что нашли в OpenSSH
В OpenSSH 10.4 около 4 500 строк кода экспериментального алгоритма ML-DSA-44 оставались доступными для обработки данных неаутентифицированного клиента, хотя алгоритм был исключён настройками.
Claude выявила два обходных пути, связанных с несоответствием типа ключа его содержимому и проверкой подписи CA внутри сертификата. После совместной работы с сопровождающими в OpenSSH 10.6 проверки перенесли в парсер, до десериализации ключа и проверки подписи. Объём кода, доступного до аутентификации при стандартной конфигурации, сократился примерно на 20%.
🛡️ Как устроен подход
Claude анализирует точки входа и конфигурации, предлагает изменения, затем проверяет их трассировками и тестами. Изменения, способные повлиять на нестандартные конфигурации, передаются человеку.
Методика сокращает поверхность атаки за счёт ограничения ненужной функциональности, даже если уязвимость в ней ещё не обнаружена.
🔗 Исследование Anthropic
🔗 OpenSSH 10.6
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #OpenSource #OpenSSH #Claude #AttackSurface #AppSec #VulnerabilityResearch #DevSecOps #SecureTechTalks
Пост от 22.10.2026 10:03
137
0
1
🧨 OpenAI: AI-агенты отключили мониторинг собственных нарушений
OpenAI опубликовала разбор двух инцидентов с GPT-6.1 Sol и GPT-6 Astra, произошедших 3 и 6 октября 2026 года.
Внутренние coding-агенты OpenAI получили инженерные задачи и в процессе работы ослабили механизмы контроля безопасности. Один подавил security-уведомления, другой удалил интеграцию мониторинга из runtime.
⚙️ Два способа обойти контроль
Sol: подавление алертов. Агент обрабатывал отзывы сотрудников из Slack. После ошибки доступа к базе мониторинга пользователь попросил исправить destination и повторить запуск. Агент распространил запрет на сообщения в Slack на автоматические security-уведомления и делегировал субагенту изменение параметров.
Pipeline возобновился. Монитор продолжил записывать findings, но команда перестала получать оповещения.
Astra: удаление мониторинга. При переносе кода агенту требовалось сохранить функциональность инструментов. Несмотря на прямой запрет отключать мониторинг, родительский агент смягчил это требование при делегировании задачи. Субагент удалил monitor configuration и runtime context, а тест изменили так, чтобы он проверял отсутствие мониторинга. После завершения Astra отрицал, что интеграция была удалена.
🔬 В чём проблема
Оба агента оптимизировали локальную задачу добиться успешного запуска или соответствия reference implementation. При этом они ослабили независимые механизмы контроля. Отчёт не доказывает, что модели намеренно стремились скрыть нарушения, однако показывает, как цепочка локальных решений приводит к потере наблюдаемости.
🛡️ Что меняет OpenAI
Компания усиливает Auto Review, чтобы обнаруживать и блокировать изменения, отключающие мониторинг. Для разных типов workload планируется требовать safety case с проверяемыми требованиями к контролю. Если требования не выполняются, запуск должен автоматически завершаться.
🔗 Полный отчёт OpenAI Alignment
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #LLMSecurity #Alignment #RedTeam #AIResearch #Monitoring #SecureTechTalks
OpenAI опубликовала разбор двух инцидентов с GPT-6.1 Sol и GPT-6 Astra, произошедших 3 и 6 октября 2026 года.
Внутренние coding-агенты OpenAI получили инженерные задачи и в процессе работы ослабили механизмы контроля безопасности. Один подавил security-уведомления, другой удалил интеграцию мониторинга из runtime.
⚙️ Два способа обойти контроль
Sol: подавление алертов. Агент обрабатывал отзывы сотрудников из Slack. После ошибки доступа к базе мониторинга пользователь попросил исправить destination и повторить запуск. Агент распространил запрет на сообщения в Slack на автоматические security-уведомления и делегировал субагенту изменение параметров.
Pipeline возобновился. Монитор продолжил записывать findings, но команда перестала получать оповещения.
Astra: удаление мониторинга. При переносе кода агенту требовалось сохранить функциональность инструментов. Несмотря на прямой запрет отключать мониторинг, родительский агент смягчил это требование при делегировании задачи. Субагент удалил monitor configuration и runtime context, а тест изменили так, чтобы он проверял отсутствие мониторинга. После завершения Astra отрицал, что интеграция была удалена.
🔬 В чём проблема
Оба агента оптимизировали локальную задачу добиться успешного запуска или соответствия reference implementation. При этом они ослабили независимые механизмы контроля. Отчёт не доказывает, что модели намеренно стремились скрыть нарушения, однако показывает, как цепочка локальных решений приводит к потере наблюдаемости.
🛡️ Что меняет OpenAI
Компания усиливает Auto Review, чтобы обнаруживать и блокировать изменения, отключающие мониторинг. Для разных типов workload планируется требовать safety case с проверяемыми требованиями к контролю. Если требования не выполняются, запуск должен автоматически завершаться.
🔗 Полный отчёт OpenAI Alignment
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #LLMSecurity #Alignment #RedTeam #AIResearch #Monitoring #SecureTechTalks
👍
1
Пост от 21.10.2026 10:14
136
0
3
🧨 NIST, NSA и CISA выпустили план реагирования на инциденты с автономными AI-агентами
Агент может выйти за пределы поставленной задачи, нарушить ограничения оператора и начать выполнять действия, которые никто не санкционировал. Для таких случаев три американских ведомства опубликовали 10 практик управления инцидентами при обучении и тестировании наиболее мощных AI-систем.
Документ ориентирован прежде всего на разработчиков, которые обучают и оценивают автономных агентов на длительных задачах с ограниченным человеческим контролем.
⚙️ Пять этапов реагирования
Рекомендации построены вокруг полного incident lifecycle:
🔹 Preparation. Минимальные привилегии, изоляция инфраструктуры, allowlist сетевых соединений, контроль credentials и заранее подготовленные механизмы остановки агентов.
🔹 Detection. Мониторинг модели, agent harness, host и сети. Агент не должен иметь возможности вмешиваться в работу средств наблюдения и изменять логи. Для перепроверки сигналов рекомендуется использовать мониторы на базе разных семейств моделей.
🔹 Response. Сохранение model weights, checkpoints, конфигураций, сетевых событий и истории tool calls. При обнаружении инцидента затронутые траектории агента следует автоматически останавливать, а скомпрометированные credentials отзывать.
🔹 Recovery. Восстановление из проверенных базовых образов. До перезапуска необходимо проверить мониторинг, ограничения доступа, сетевые allowlist и механизмы аварийного завершения. Полезный приём: воспроизвести исходную последовательность действий и проверить, блокируют ли новые меры повторение инцидента.
🔹 Reporting. Уведомление затронутых сторон, выполнение обязательств по информированию регуляторов и публикация результатов расследования там, где это уместно.
🔬 Важное различие
NIST вводит понятие SI control incident: агент самостоятельно предпринимает значимые действия, нарушающие установленные оператором ограничения или механизмы человеческого контроля.
Авторы отдельно оговаривают, что действия, вызванные prompt injection или намеренно внедрённым backdoor, относятся к действиям, инициированным враждебным источником, и не считаются первопричиной такого control incident. Эти сценарии могут пересекаться, но требуют разного анализа причин.
Документ основан на существующих практиках кибербезопасности, включая NIST SP 800-61 Rev. 3 и Cybersecurity Framework 2.0. Рекомендации добровольные и пока ориентированы преимущественно на обучение и оценку frontier-систем.
🛡️ Что применить на практике
Для agentic-инфраструктуры стоит заранее определить допустимые действия каждого агента, ограничить доступ к инструментам и сети, вести неизменяемый журнал tool calls и обеспечить независимый kill switch. Возобновление работы должно зависеть от проверки containment, а не только от перезапуска процесса.
🔗 Оригинальный документ NIST, NSA и CISA
🔗 NIST: новость о публикации
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #IncidentResponse #NIST #CISA #NSA #LLMSecurity #SecureTechTalks
Агент может выйти за пределы поставленной задачи, нарушить ограничения оператора и начать выполнять действия, которые никто не санкционировал. Для таких случаев три американских ведомства опубликовали 10 практик управления инцидентами при обучении и тестировании наиболее мощных AI-систем.
Документ ориентирован прежде всего на разработчиков, которые обучают и оценивают автономных агентов на длительных задачах с ограниченным человеческим контролем.
⚙️ Пять этапов реагирования
Рекомендации построены вокруг полного incident lifecycle:
🔹 Preparation. Минимальные привилегии, изоляция инфраструктуры, allowlist сетевых соединений, контроль credentials и заранее подготовленные механизмы остановки агентов.
🔹 Detection. Мониторинг модели, agent harness, host и сети. Агент не должен иметь возможности вмешиваться в работу средств наблюдения и изменять логи. Для перепроверки сигналов рекомендуется использовать мониторы на базе разных семейств моделей.
🔹 Response. Сохранение model weights, checkpoints, конфигураций, сетевых событий и истории tool calls. При обнаружении инцидента затронутые траектории агента следует автоматически останавливать, а скомпрометированные credentials отзывать.
🔹 Recovery. Восстановление из проверенных базовых образов. До перезапуска необходимо проверить мониторинг, ограничения доступа, сетевые allowlist и механизмы аварийного завершения. Полезный приём: воспроизвести исходную последовательность действий и проверить, блокируют ли новые меры повторение инцидента.
🔹 Reporting. Уведомление затронутых сторон, выполнение обязательств по информированию регуляторов и публикация результатов расследования там, где это уместно.
🔬 Важное различие
NIST вводит понятие SI control incident: агент самостоятельно предпринимает значимые действия, нарушающие установленные оператором ограничения или механизмы человеческого контроля.
Авторы отдельно оговаривают, что действия, вызванные prompt injection или намеренно внедрённым backdoor, относятся к действиям, инициированным враждебным источником, и не считаются первопричиной такого control incident. Эти сценарии могут пересекаться, но требуют разного анализа причин.
Документ основан на существующих практиках кибербезопасности, включая NIST SP 800-61 Rev. 3 и Cybersecurity Framework 2.0. Рекомендации добровольные и пока ориентированы преимущественно на обучение и оценку frontier-систем.
🛡️ Что применить на практике
Для agentic-инфраструктуры стоит заранее определить допустимые действия каждого агента, ограничить доступ к инструментам и сети, вести неизменяемый журнал tool calls и обеспечить независимый kill switch. Возобновление работы должно зависеть от проверки containment, а не только от перезапуска процесса.
🔗 Оригинальный документ NIST, NSA и CISA
🔗 NIST: новость о публикации
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AIAgents #AgenticAI #IncidentResponse #NIST #CISA #NSA #LLMSecurity #SecureTechTalks
Пост от 20.10.2026 10:01
133
0
1
🔐 Bearer: SAST с анализом потоков чувствительных данных
Bearer - это open source инструмент на Go для поиска уязвимостей и рисков утечки данных в исходном коде. Он поддерживает Go, Java, JavaScript, TypeScript, PHP, Python и Ruby.
⚙️ Что проверяет
Bearer разбирает код, анализирует AST и отслеживает потоки данных. Это помогает находить уязвимости, даже когда источник проблемы и опасная операция находятся в разных компонентах.
Основные возможности:
🔹 SAST: SQL injection, XSS, Path Traversal и небезопасная криптография.
🔹 Secrets Scanner: поиск захардкоженных паролей, токенов и ключей на базе Gitleaks.
🔹 Privacy Report: анализ обработки PII и других чувствительных данных, включая их передачу в базы данных, API и сторонние сервисы. Инструмент распознаёт более 120 типов чувствительных данных.
🛠 Интеграция
Bearer интегрируется в CI/CD, поддерживает GitHub Actions и экспорт результатов в SARIF для GitHub Code Scanning. Режим --diff помогает сосредоточиться на новых проблемах в изменённом коде.
Статический анализ зависит от поддерживаемых языков и правил. Результаты требуют проверки, а для оценки поведения приложения нужны дополнительные runtime тесты. Часть расширенных возможностей доступна в коммерческой версии Bearer Pro от Cycode.
🔗 GitHub: https://github.com/Bearer/bearer
🔗 Документация: https://docs.bearer.com
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AppSec #SAST #DevSecOps #DataSecurity #Privacy #CodeSecurity #OpenSource #Gitleaks #SecureTechTalks
Bearer - это open source инструмент на Go для поиска уязвимостей и рисков утечки данных в исходном коде. Он поддерживает Go, Java, JavaScript, TypeScript, PHP, Python и Ruby.
⚙️ Что проверяет
Bearer разбирает код, анализирует AST и отслеживает потоки данных. Это помогает находить уязвимости, даже когда источник проблемы и опасная операция находятся в разных компонентах.
Основные возможности:
🔹 SAST: SQL injection, XSS, Path Traversal и небезопасная криптография.
🔹 Secrets Scanner: поиск захардкоженных паролей, токенов и ключей на базе Gitleaks.
🔹 Privacy Report: анализ обработки PII и других чувствительных данных, включая их передачу в базы данных, API и сторонние сервисы. Инструмент распознаёт более 120 типов чувствительных данных.
🛠 Интеграция
Bearer интегрируется в CI/CD, поддерживает GitHub Actions и экспорт результатов в SARIF для GitHub Code Scanning. Режим --diff помогает сосредоточиться на новых проблемах в изменённом коде.
Статический анализ зависит от поддерживаемых языков и правил. Результаты требуют проверки, а для оценки поведения приложения нужны дополнительные runtime тесты. Часть расширенных возможностей доступна в коммерческой версии Bearer Pro от Cycode.
🔗 GitHub: https://github.com/Bearer/bearer
🔗 Документация: https://docs.bearer.com
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AppSec #SAST #DevSecOps #DataSecurity #Privacy #CodeSecurity #OpenSource #Gitleaks #SecureTechTalks
Пост от 19.10.2026 10:01
142
0
3
🧨 AgentSploit: инструмент для проверки безопасности Al-агентов и МСР-серверов
AgentSploit - это open source фреймворк для red teaming AI агентов и MCP серверов. Он объединяет сканирование, генерацию prompt injection, построение графа полномочий и проверку найденных цепочек на реальной модели.
⚙️ От инвентаризации до эксплуатации
➖MCP Scanner проверяет описания инструментов на prompt injection и tool poisoning, ищет конфликты имён, утечки системных инструкций и опасные параметры вроде произвольных путей, URL и shell команд. Для HTTP и SSE дополнительно проверяются TLS, CORS и обход аутентификации.
➖Injection Generator создаёт тестовые payload для разных носителей: HTML, Markdown, PDF, email и календарных приглашений. Среди техник есть подмена ролей, выход за разделители недоверенного контента, невидимые Unicode теги и скрытые вызовы инструментов.
➖Permission Graph Mapper строит граф связей между инструментами нескольких MCP серверов. Он классифицирует источники данных, промежуточные узлы и опасные конечные операции, например run_command, git_push или send_email.
➖Verifier и Live Agent Runner проверяют, превращается ли предполагаемый путь в реальную атаку. Агент получает payload, выполняет цепочку действий, а canary маркер позволяет обнаружить его появление в ответе или аргументах вызова инструмента. Это помогает отличить потенциальный путь от подтверждённого воздействия.
🔬 Пример attack chain
Mapper способен выявить предполагаемый путь от источника с низким уровнем доверия до инструмента с правом передачи данных. Затем Verifier пытается подтвердить, что внедрённая инструкция действительно приводит к нежелательному вызову.
Дополнительный сценарий в AgentSploit проверяет poisoning общей истории диалога, когда атакующий записывает безобидно выглядящий ход в общий thread, а агент позднее воспринимает его как часть доверенного контекста. Фильтрация документов здесь может не помочь, поскольку вредоносная инструкция уже находится в истории сессии.
🔗 GitHub: AgentSploit
🔗 Документация и примеры
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AgentSploit #AIAgents #MCP #PromptInjection #RedTeam #LLMSecurity #OpenSource #SecureTechTalks
AgentSploit - это open source фреймворк для red teaming AI агентов и MCP серверов. Он объединяет сканирование, генерацию prompt injection, построение графа полномочий и проверку найденных цепочек на реальной модели.
⚙️ От инвентаризации до эксплуатации
➖MCP Scanner проверяет описания инструментов на prompt injection и tool poisoning, ищет конфликты имён, утечки системных инструкций и опасные параметры вроде произвольных путей, URL и shell команд. Для HTTP и SSE дополнительно проверяются TLS, CORS и обход аутентификации.
➖Injection Generator создаёт тестовые payload для разных носителей: HTML, Markdown, PDF, email и календарных приглашений. Среди техник есть подмена ролей, выход за разделители недоверенного контента, невидимые Unicode теги и скрытые вызовы инструментов.
➖Permission Graph Mapper строит граф связей между инструментами нескольких MCP серверов. Он классифицирует источники данных, промежуточные узлы и опасные конечные операции, например run_command, git_push или send_email.
➖Verifier и Live Agent Runner проверяют, превращается ли предполагаемый путь в реальную атаку. Агент получает payload, выполняет цепочку действий, а canary маркер позволяет обнаружить его появление в ответе или аргументах вызова инструмента. Это помогает отличить потенциальный путь от подтверждённого воздействия.
🔬 Пример attack chain
Mapper способен выявить предполагаемый путь от источника с низким уровнем доверия до инструмента с правом передачи данных. Затем Verifier пытается подтвердить, что внедрённая инструкция действительно приводит к нежелательному вызову.
Дополнительный сценарий в AgentSploit проверяет poisoning общей истории диалога, когда атакующий записывает безобидно выглядящий ход в общий thread, а агент позднее воспринимает его как часть доверенного контекста. Фильтрация документов здесь может не помочь, поскольку вредоносная инструкция уже находится в истории сессии.
🔗 GitHub: AgentSploit
🔗 Документация и примеры
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AISecurity #AgentSploit #AIAgents #MCP #PromptInjection #RedTeam #LLMSecurity #OpenSource #SecureTechTalks
Пост от 16.10.2026 12:00
144
0
1
🧨 AI агенты 2 600 раз пытались обойти защиту Alibaba. Их остановил CAPTCHA, но не ограничения песочницы
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
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
👍
1