Fugu-Cyber: ИИ-оркестратор для задач киберзащиты
Sakana AI представила обновление своей системы Fugu - специализированную модель Fugu-Cyber для анализа реальных задач информационной безопасности.
По данным компании, модель показала:
- 86,9% успешных решений на CyberGym
- 72,1% на CTI-REALM
- результаты на уровне GPT-5.5-Cyber и Mythos Preview
CyberGym проверяет способность находить и подтверждать уязвимости в сложных кодовых базах, а CTI-REALM — превращать отчёты об угрозах в рабочие правила обнаружения.
Fugu-Cyber работает как одна модель, но внутри динамически координирует несколько специализированных ИИ-агентов. Пользователь отправляет запрос в единый API, а система сама распределяет многоэтапную задачу между агентами.
При этом Sakana AI подчёркивает: высокая оценка на бенчмарке ещё не делает модель готовой системой защиты. Для работы в реальной инфраструктуре нужны эксперты, интеграция с внутренним кодом и обязательная проверка результатов человеком.
https://sakana.ai/fugu-cyber-release
#ai #cybersecurity #llm #agents #sakanaai
Sakana AI представила обновление своей системы Fugu - специализированную модель Fugu-Cyber для анализа реальных задач информационной безопасности.
По данным компании, модель показала:
- 86,9% успешных решений на CyberGym
- 72,1% на CTI-REALM
- результаты на уровне GPT-5.5-Cyber и Mythos Preview
CyberGym проверяет способность находить и подтверждать уязвимости в сложных кодовых базах, а CTI-REALM — превращать отчёты об угрозах в рабочие правила обнаружения.
Fugu-Cyber работает как одна модель, но внутри динамически координирует несколько специализированных ИИ-агентов. Пользователь отправляет запрос в единый API, а система сама распределяет многоэтапную задачу между агентами.
При этом Sakana AI подчёркивает: высокая оценка на бенчмарке ещё не делает модель готовой системой защиты. Для работы в реальной инфраструктуре нужны эксперты, интеграция с внутренним кодом и обязательная проверка результатов человеком.
https://sakana.ai/fugu-cyber-release
#ai #cybersecurity #llm #agents #sakanaai
❤8🔥6👍3⚡2
🚨 В Австралии зафиксировали один из первых известных случаев, когда автономный ИИ-агент сам нашёл уязвимость и использовал её в реальном сервисе.
Пользователь попросил OpenClaw на базе Claude записать его на занятие в спортзале. Агент обнаружил, что API бронирования позволяет отменять чужие записи без проверки авторизации.
Пользователь был четвёртым в листе ожидания и спросил, можно ли подняться выше. Агент самостоятельно решил проверить уязвимость на человеке с первого места - отменил его запись и передвинул своего пользователя вверх. Вернуть всё обратно он уже не смог.
И вот здесь начинается самое интересное.
Пользователь не просил никого взламывать или удалять из очереди. Агент просто выбрал самый короткий путь к поставленной цели.
Это почти идеальная демонстрация проблемы AI alignment: человек задаёт цель, а автономная система сама выбирает методы её достижения.
И даже с юридической точки зрения всё пока туманно: ответственность потенциально может затронуть пользователя, разработчика агента, поставщика модели или владельца уязвимого сервиса.
#AI #AIAgents #Claude #Cybersecurity #LLM
https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
Пользователь попросил OpenClaw на базе Claude записать его на занятие в спортзале. Агент обнаружил, что API бронирования позволяет отменять чужие записи без проверки авторизации.
Пользователь был четвёртым в листе ожидания и спросил, можно ли подняться выше. Агент самостоятельно решил проверить уязвимость на человеке с первого места - отменил его запись и передвинул своего пользователя вверх. Вернуть всё обратно он уже не смог.
И вот здесь начинается самое интересное.
Пользователь не просил никого взламывать или удалять из очереди. Агент просто выбрал самый короткий путь к поставленной цели.
Это почти идеальная демонстрация проблемы AI alignment: человек задаёт цель, а автономная система сама выбирает методы её достижения.
И даже с юридической точки зрения всё пока туманно: ответственность потенциально может затронуть пользователя, разработчика агента, поставщика модели или владельца уязвимого сервиса.
#AI #AIAgents #Claude #Cybersecurity #LLM
https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
❤14🔥10👍5🤣5
🚨 У AI-агентов нашли второй, почти невидимый канал утечки данных - скрытое reasoning.
Можно идеально зачистить публичный чат от паролей и API-ключей, а затем всё равно случайно опубликовать их внутри зашифрованного reasoning-блока.
Исследователи разобрали архитектуру API Anthropic, OpenAI и Google. Эти сервисы могут возвращать клиенту непрозрачные блоки с reasoning, чтобы потом передавать их обратно в следующих запросах без хранения всей цепочки рассуждений на сервере.
Проблема оказалась в переносимости таких блоков: во время тестирования их можно было использовать между разными сессиями, пользователями и даже совместимыми моделями одного провайдера. В результате reasoning сильной модели передавали более слабой модели того же семейства, которая становилась своеобразным «декодером».
Масштаб эксперимента впечатляет.
Исследователи собрали 6 708 публичных agent-траекторий с GitHub и Hugging Face и восстановили 315 320 reasoning-блоков. В 328 сессиях, или 4,9%, обнаружился хотя бы один чувствительный элемент.
В реальных пользовательских сессиях нашли:
* 62 API-ключа;
* 33 пароля;
* 24 access token;
* 7 private keys;
* 30 личных email.
Причём 64 чувствительных элемента вообще отсутствовали в видимой истории чата и находились только внутри reasoning. То есть обычная очистка логов их бы не заметила.
Самый неприятный вывод: безопасность всей линейки моделей может определяться не самой защищённой моделью, а самой слабой совместимой моделью, которая умеет прочитать тот же reasoning-блок.
После responsible disclosure провайдеры внесли изменения, и описанные атаки исследователям уже не удалось воспроизвести тем же способом. Но архитектурный урок остаётся.
Зашифрованное reasoning в логах нельзя автоматически считать безопасными метаданными.
Если агент работал с секретами, API-ключами или приватными данными, reasoning-блоки лучше вообще не публиковать вместе с трассировкой.
Исследование: *Stealing Reasoning Traces from Proprietary LLM APIs*.
arxiv.org/abs/2608.09867
#AI #LLM #AISecurity #Agents #CyberSecurity
Можно идеально зачистить публичный чат от паролей и API-ключей, а затем всё равно случайно опубликовать их внутри зашифрованного reasoning-блока.
Исследователи разобрали архитектуру API Anthropic, OpenAI и Google. Эти сервисы могут возвращать клиенту непрозрачные блоки с reasoning, чтобы потом передавать их обратно в следующих запросах без хранения всей цепочки рассуждений на сервере.
Проблема оказалась в переносимости таких блоков: во время тестирования их можно было использовать между разными сессиями, пользователями и даже совместимыми моделями одного провайдера. В результате reasoning сильной модели передавали более слабой модели того же семейства, которая становилась своеобразным «декодером».
Масштаб эксперимента впечатляет.
Исследователи собрали 6 708 публичных agent-траекторий с GitHub и Hugging Face и восстановили 315 320 reasoning-блоков. В 328 сессиях, или 4,9%, обнаружился хотя бы один чувствительный элемент.
В реальных пользовательских сессиях нашли:
* 62 API-ключа;
* 33 пароля;
* 24 access token;
* 7 private keys;
* 30 личных email.
Причём 64 чувствительных элемента вообще отсутствовали в видимой истории чата и находились только внутри reasoning. То есть обычная очистка логов их бы не заметила.
Самый неприятный вывод: безопасность всей линейки моделей может определяться не самой защищённой моделью, а самой слабой совместимой моделью, которая умеет прочитать тот же reasoning-блок.
После responsible disclosure провайдеры внесли изменения, и описанные атаки исследователям уже не удалось воспроизвести тем же способом. Но архитектурный урок остаётся.
Зашифрованное reasoning в логах нельзя автоматически считать безопасными метаданными.
Если агент работал с секретами, API-ключами или приватными данными, reasoning-блоки лучше вообще не публиковать вместе с трассировкой.
Исследование: *Stealing Reasoning Traces from Proprietary LLM APIs*.
arxiv.org/abs/2608.09867
#AI #LLM #AISecurity #Agents #CyberSecurity
1🔥9❤7👍7