Forwarded from Машинное обучение RU
Open source не создаёт кризис кибербезопасности. Он помогает её решать.
Cisco Foundation AI открывает модели, датасеты и инструменты для анализа уязвимостей, threat intelligence и автоматизации работы специалистов по безопасности. Среди релизов — Foundation-Sec и компактные агентные модели Antares для поиска уязвимого кода.
Открытый код позволяет исследователям проверять модели, находить слабые места и совместно улучшать защиту. Закрытость сама по себе безопасность не гарантирует.
huggingface.co/fdtn-ai
Cisco Foundation AI открывает модели, датасеты и инструменты для анализа уязвимостей, threat intelligence и автоматизации работы специалистов по безопасности. Среди релизов — Foundation-Sec и компактные агентные модели Antares для поиска уязвимого кода.
Открытый код позволяет исследователям проверять модели, находить слабые места и совместно улучшать защиту. Закрытость сама по себе безопасность не гарантирует.
huggingface.co/fdtn-ai
Forwarded from Artificial Intelligence AI News
This media is not supported in your browser
VIEW IN TELEGRAM
Andrew Ng Just Released OpenWorker: An Open-Source, Local-First Desktop AI Coworker That Returns Finished Deliverables Instead of Chat
Here are some key takeaways:
1. The approval layer is typed, not cosmetic
Most desktop agents bolt approvals onto the UI. OpenWorker classifies every tool call into one of four risk classes before it runs:
→ read — no side effects, always allowed
→ write_local — mutates the workspace, path-scoped
→ exec — runs commands
→ external — side effects off the machine
Five permission modes then decide what happens: discuss, plan, interactive (default), auto, custom.
2. Unattended ≠ more autonomous
Unattended mode doesn't raise the autonomy ceiling. It only reroutes approval prompts to an Inbox and suspends the run until a human answers. Autonomy and attention are separate axes — most agent frameworks conflate them.
3. No inference service, by design
You bring a key or run local:
→ 30 curated models, 13 providers
→ Native OpenAI / Anthropic / Google, open-weight via Together and Fireworks
→ Fully local via Ollama, no key
→ Matrix limited to tool-calling models — anything else stalls the agent loop
The stack
→ Tauri 2 + React shell over a local Python FastAPI server (127.0.0.1:8765)
→ 35 connectors live, plus any MCP server
→ Built on aisuite, ~32.4k lines of Python, 78 test modules
Full analysis: https://www.marktechpost.com/2026/07/23/andrew-ng-just-released-openworker-an-open-source-local-first-desktop-ai-coworker-that-returns-finished-deliverables-instead-of-chat/
Repo: https://github.com/andrewyng/openworker
Project: https://openworker.com/
Here are some key takeaways:
1. The approval layer is typed, not cosmetic
Most desktop agents bolt approvals onto the UI. OpenWorker classifies every tool call into one of four risk classes before it runs:
→ read — no side effects, always allowed
→ write_local — mutates the workspace, path-scoped
→ exec — runs commands
→ external — side effects off the machine
Five permission modes then decide what happens: discuss, plan, interactive (default), auto, custom.
2. Unattended ≠ more autonomous
Unattended mode doesn't raise the autonomy ceiling. It only reroutes approval prompts to an Inbox and suspends the run until a human answers. Autonomy and attention are separate axes — most agent frameworks conflate them.
3. No inference service, by design
You bring a key or run local:
→ 30 curated models, 13 providers
→ Native OpenAI / Anthropic / Google, open-weight via Together and Fireworks
→ Fully local via Ollama, no key
→ Matrix limited to tool-calling models — anything else stalls the agent loop
The stack
→ Tauri 2 + React shell over a local Python FastAPI server (127.0.0.1:8765)
→ 35 connectors live, plus any MCP server
→ Built on aisuite, ~32.4k lines of Python, 78 test modules
Full analysis: https://www.marktechpost.com/2026/07/23/andrew-ng-just-released-openworker-an-open-source-local-first-desktop-ai-coworker-that-returns-finished-deliverables-instead-of-chat/
Repo: https://github.com/andrewyng/openworker
Project: https://openworker.com/
🔥1
Forwarded from Not Boring Tech
📚 Вышел интерактивный учебник по созданию LLM с нуля — Language Model Builder шаг за шагом объясняет основы и устройство нейронок.
После теории сразу начинается практика — вы создадите своего нейропомощника типа GPT-2-Small, с которым можно будет пообщаться.
Сохраняем — тут.
@notboring_tech
После теории сразу начинается практика — вы создадите своего нейропомощника типа GPT-2-Small, с которым можно будет пообщаться.
Сохраняем — тут.
@notboring_tech
❤1
Forwarded from Russian OSINT
AI Security Institute
UK AISI / CAISI Preliminary Assessment of Kimi K3's Cyber Capabilities | AISI Work
Our joint evaluation with CAISI finds Kimi K3 trails leading US frontier closed weight models on cyber capability.
Британский Институт безопасности ИИ (UK AISI) и Американский Центр стандартов и инноваций в области ИИ (CAISI) опубликовали совместный отчёт с оценкой кибервозможностей ИИ-модели Kimi K3 от китайской компании Moonshot AI. Тестирование, проведённое ИБ-исследователями, показало, что Kimi K3 отстаёт от передовых проприетарных ИИ-моделей из США, но при этом демонстрирует наилучшие результаты среди известных моделей с открытыми весами из Китая.
1️⃣ В рамках анализа способности к разработке эксплойтов ИИ-модель протестировали на публичном бенчмарке ExploitBench, созданном Университетом Карнеги-Меллона для оценки прохождения уязвимостей в движке V8. Бенчмарк включает 41 актуальную уязвимость, обнаруженную после 2023 года. Kimi K3 набрала 32,2% по взвешенной шкале, опередив GLM-5.2 с её 24,4%, но осталась далеко позади ведущих американских ИИ-моделей с их средним результатом 76,2%. Ключевым ограничением Kimi K3 стало полное отсутствие успешных сценариев создания полноценных эксплойтов с произвольным выполнением кода (ACE). Модель дошла до этапа воспроизведения сбоя в 34 задачах и сформировала специфические примитивы V8 в 17 случаях, однако не сумела выйти на уровень общих примитивов и получить контроль над потоком исполнения. В то же время передовые американские системы успешно достигали уровня ACE в среднем в 20 из 41 тестовой ситуации.
2️⃣ Второй этап тестирования проходил на киберполигоне «The Last Ones», который имитирует последовательную атаку на корпоративную сеть из 4 подсетей и около 20 хостов. Этот сценарий включает 32 шага и требует у специалиста по кибербезопасности порядка 20 часов работы. При ограничении в 100 млн токенов Kimi K3 преодолевала в среднем 17 шагов атаки, тогда как GLM-5.2 останавливалась на 11-м шаге, а лидирующие американские ИИ-модели проходили в среднем 28,5 шага. В одной из 10 попыток Kimi K3 смогла полностью завершить цепочку компрометации сети, доказав потенциальную способность автономно атаковать небольшие инфраструктуры со слабой защитой при наличии первоначального доступа. При этом эксперты подчеркнули отличие киберполигона от реальной среды, поскольку на нём отсутствовали активные средства защиты, а действия ИИ-модели не подлежали штрафам за вызываемые аномалии.
Отставание китайских разработок от проприетарных систем из 🇺🇸США остаётся якобы существенным. Дополнительно ИБ-исследователи указали на проблему с защитными барьерами модели. Встроенные ограничения Kimi K3 не воспрепятствовали её участию в разработке эксплойтов и проведении наступательных операций, что позволило модели выполнять инструкции по компрометации систем в ходе испытаний.
--------------------------
👆🤔 Важные нюансы в исследовании: Kimi K3 тестировали не как опубликованную модель с открытыми весами. Полные веса должны появиться только 27 июля. UK AISI и CAISI прямо указали, что особенности хостинга позволили провести только выборочный набор кибериспытаний, однако не раскрыли конкретные технические ограничения. Это существенно меняет картину, поскольку Moonshot AI предупреждает, что Kimi K3 обучалась с сохранением истории рассуждений и может работать крайне нестабильно, если агентная оболочка не возвращает модели всё содержимое предыдущих рассуждений. Компания рекомендует использовать оболочку с проверенной совместимостью, например Kimi Code. В публичном отчёте UK AISI и CAISI не указано, какая агентная оболочка применялась, как передавалась история рассуждений и проверялась ли совместимость используемой конфигурации с требованиями Kimi K3.
Примечательно, что у американских закрытых моделей отключили системные защитные механизмы, чтобы измерить максимальные возможности. Kimi K3 проверялась в доступной размещённой конфигурации с включёнными safeguards. Получается, что ИБ-исследователи напрямую сравнивали искусственно разблокированные возможности проприетарных американских ИИ-моделей с тем, что китайская модель смогла выдать в базовой размещённой конфигурации с включёнными защитными механизмами. Утверждается, что якобы защитные механизмы у Kimi K3 не сработали.
U.S. closed-weight models were evaluated with system-level safeguards disabled to reduce refusals and enable measurement of maximal capabilities.
Что ещё бросается в глаза? Ещё одна проблема заключается в неодинаковом тестовом покрытии. Kimi K3 поместили на общую временную шкалу кибервозможностей вместе с передовыми проприетарными моделями из США и другими ИИ-моделями из 🇨🇳Китая, хотя расчёт их показателей основан на существенно различающихся наборах задач.
Уровень Kimi K3 рассчитан исключительно по ExploitBench. Это 41 задача, относящаяся к одному узкому направлению — разработке эксплойтов для известных уязвимостей движка V8.
👆Оценки остальных моделей основаны на большем числе задач, которые охватывают дополнительные направления кибервозможностей. Экстраполяция результатов ExploitBench на общую шкалу кибервозможностей не позволяет считать положение Kimi K3 на графике надёжной оценкой совокупных возможностей модели.
Делать выводы о том, что проприетарные американские модели безоговорочно превосходят Kimi K3 в комплексных кибервозможностях, опираясь на столь неравнозначную базу, методологически некорректно. Реальная расстановка сил станет ясна только после того, как ИБ-исследователи протестируют опубликованные открытые веса Kimi K3 в равных лабораторных условиях и на сопоставимом наборе бенчмарков.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Machinelearning
Четыре правительственных ведомства Пекина утвердили стратегию внедрения и монетизации агентного ИИ.
Это одна из первых в мире государственных программ развития зарождающейся экономики нового типа.
Документ смещает фокус индустрии с обучения базовых моделей на прикладное использование агентов.
Муниципалитеты будут публиковать запросы от медицины, производств, науки и госсектора для прямой связи разработчиков с клиентами.
Власти поддержат бизнес-модели Token-as-a-Service, Agent-as-a-Service и Results-as-a-Service, а также выделит разработчикам субсидии в виде токен-ваучеров.
Планируется постепенный переход от тарификации за потребленные токены к оплате за результат, достигнутый алгоритмом.
Для инди-разработчиков упростят регистрацию компаний одного человека (ИП), предоставят доступ к льготным государственным вычислительным мощностям и поддержку для интеграции в опенсорс-сообщества.
Для стимуляции спроса электронику со встроенными агентами (умные очки, наушники, роботов и автомобили) включат в программы трейд-ин и субсидирования.
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Community
PentestAgent — это фреймворк с ИИ-агентами для тестирования безопасности методом «черного ящика», поддерживающий рабочие процессы баг-баунти, «красной команды» и тестирования на проникновение.
🐱 GitHub
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Хабр / ML & AI
Инференс LLM: от KV-кэша до продакшен-деплоя
Привет! Я Саша Рыжов, MLOps-инженер в hh.ru, уже три года занимаюсь развитием инфраструктуры для искусственного интеллекта. Компании, которые развивают GenAI, рано или поздно приходят к задачам по запуску LLM на собственном железе. В статье я расскажу, как обстоят дела с движками инференса в 2026 году и как запустить on‑prem-прод и не изобрести при этом велосипед. Читать далее
#sglang #llm #inference #kv_cache #sram #vllm | @habr_ai
Привет! Я Саша Рыжов, MLOps-инженер в hh.ru, уже три года занимаюсь развитием инфраструктуры для искусственного интеллекта. Компании, которые развивают GenAI, рано или поздно приходят к задачам по запуску LLM на собственном железе. В статье я расскажу, как обстоят дела с движками инференса в 2026 году и как запустить on‑prem-прод и не изобрести при этом велосипед. Читать далее
#sglang #llm #inference #kv_cache #sram #vllm | @habr_ai
HiveTrace 2026 презентация продукта.pdf
3.8 MB
Обновленная презентация HiveTrace 2026
Представляю замечательную статистику по безопасности ИИ и презентацию платформ HiveTrace, HiveTrace Red (спасибо Евгению Кокуйкину за ценные материалы).
Масса новых инсайтов, предельно четкое обоснование необходимости внедрения передовых отечественных систем по защите LLM, включая перечень рисков и угроз. В этом плане, конечно, HiveTrace уже является национальным российским лидером.
Важно, что ребята из команды HiveTrace всегда позитивны, отзывчивы, готовы пойти навстречу и провести презентацию. Они непрерывно улучшают свои продукты и их возможности. В России этой уникальной защитной системой пользуются уже многие крупные компании.
Поэтому вот ссылка на сайт, смотрим, погружаемся в техническую часть и при желании - подключаемся: https://hivetrace.ru
Делитесь презентацией с коллегами - мы ожидаем усиления регулирования в сфере ИИ и подключение такой системы как HiveTrace скоро будет обязательным.
Архитектор MLSecOps и AI Governance
Николай Павлов
Представляю замечательную статистику по безопасности ИИ и презентацию платформ HiveTrace, HiveTrace Red (спасибо Евгению Кокуйкину за ценные материалы).
Масса новых инсайтов, предельно четкое обоснование необходимости внедрения передовых отечественных систем по защите LLM, включая перечень рисков и угроз. В этом плане, конечно, HiveTrace уже является национальным российским лидером.
Важно, что ребята из команды HiveTrace всегда позитивны, отзывчивы, готовы пойти навстречу и провести презентацию. Они непрерывно улучшают свои продукты и их возможности. В России этой уникальной защитной системой пользуются уже многие крупные компании.
Поэтому вот ссылка на сайт, смотрим, погружаемся в техническую часть и при желании - подключаемся: https://hivetrace.ru
Делитесь презентацией с коллегами - мы ожидаем усиления регулирования в сфере ИИ и подключение такой системы как HiveTrace скоро будет обязательным.
Архитектор MLSecOps и AI Governance
Николай Павлов
🔥3
Forwarded from CodeCamp
Ого, Visa выложила на GitHub свой харнесс для поиска дыр ИИ-агентами 😨
VVAH помогает автоматизировать проверку кода: искать потенциальные уязвимости, оценивать риски, предлагать исправления и формировать отчёты. Поддерживаются как закрытые, так и локальные модели.
Забираем😊
VVAH помогает автоматизировать проверку кода: искать потенциальные уязвимости, оценивать риски, предлагать исправления и формировать отчёты. Поддерживаются как закрытые, так и локальные модели.
Забираем
Please open Telegram to view this post
VIEW IN TELEGRAM
ML&|Sec Feed
https://owasp.org/www-project-llm-verification-standard/LLMSVS-v2.0-en.html
OWASP_LLMSVS_v2_0_RU_неофициальный_перевод.docx
69.1 KB
OWASP LLMSVS v2.0 - практический стандарт проверки безопасности систем на основе LLM, охватывающий жизненный цикл моделей, данные и память, RAG, интеграции, AI-агентов, инструменты, зависимости и мониторинг. Его главная польза - набор из 70 требований КБ трех уровней строгости.
https://owasp.org/www-project-llm-verification-standard/LLMSVS-v2.0-en.html
https://owasp.org/www-project-llm-verification-standard/LLMSVS-v2.0-en.html
Forwarded from Data Secrets
Anthropic значимо обновили MCP
Апдейт назвали крупнейшим с момента запуска. Сейчас расскажем, что изменилось.
Раньше MCP работал как двусторонняя связь с сохранением состояния сессии. То есть при подключении сервер открывал долгоживущее соединение, и весь контекст между запросами жил в оперативке одного запущенного процесса. Это требовало, чтобы был постоянно работающий инстанс, который висит и ждет, существуя все время, пока идет сессия.
Теперь же MCP стал stateless, то есть теперь каждый запрос самодостаточный. Клиент сам присылает весь нужный контекст в запросе (ну или он лежит во внешнем хранилище), а сервер просто получил запрос, обработал, отдал ответ и все забыл.
Все Serverless-платформы (AWS Lambda, Cloudflare Workers и тд) работают именно так. До этой версии MCP нельзя было нормально запустить на такой инфраструктуре, а теперь можно: сервер разработчика может состоять просто из функции, которая просыпается на запрос и засыпает.
В двух словах: MCP только что стали намного дешевле + их стало гораздо легче масштабировать. Практически это значит, что порог входа для создания MCP-сервера резко упал, и мы можем ожидать взрывного роста числа коннекторов для самых разных приложений, даже самых небольших.
https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
Апдейт назвали крупнейшим с момента запуска. Сейчас расскажем, что изменилось.
Раньше MCP работал как двусторонняя связь с сохранением состояния сессии. То есть при подключении сервер открывал долгоживущее соединение, и весь контекст между запросами жил в оперативке одного запущенного процесса. Это требовало, чтобы был постоянно работающий инстанс, который висит и ждет, существуя все время, пока идет сессия.
Теперь же MCP стал stateless, то есть теперь каждый запрос самодостаточный. Клиент сам присылает весь нужный контекст в запросе (ну или он лежит во внешнем хранилище), а сервер просто получил запрос, обработал, отдал ответ и все забыл.
Все Serverless-платформы (AWS Lambda, Cloudflare Workers и тд) работают именно так. До этой версии MCP нельзя было нормально запустить на такой инфраструктуре, а теперь можно: сервер разработчика может состоять просто из функции, которая просыпается на запрос и засыпает.
В двух словах: MCP только что стали намного дешевле + их стало гораздо легче масштабировать. Практически это значит, что порог входа для создания MCP-сервера резко упал, и мы можем ожидать взрывного роста числа коннекторов для самых разных приложений, даже самых небольших.
https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
👍1
Forwarded from Пост Лукацкого
Обновили MCP-протокол, используемый для работы ИИ-инструментов с различными инструментами и сервисами. Выделил для себя несколько важных моментов с точки зрения кибербезопасности:
6️⃣ MCP становится stateless. Как по мне, так это плохо для безопасности, так как теперь каждый запрос должен быть полноценно аутентифицирован, авторизован и проверен.
2️⃣ Теперь шлюзы, WAF или service mesh могут понимать, какой MCP-метод и какой инструмент вызывается, не разбирая JSON-RPC-тело. Таким образом, можно строить более гибкие политики, например, "агенту разрешен
3️⃣ Параметры инструментов тоже можно выносить в заголовки, что позволяет строить более точные политики – разрешить работу только с определенным регионом, запретить прод, отделить тенанты, применять DLP или тарифные ограничения к определенным операциям.
4️⃣ Исправляется реальная проблема OAuth mix-up, когда креды должны храниться с привязкой к конкретному issuer и не могут автоматически переиспользоваться с другим сервером авторизации.
5️⃣ Dynamic Client Registration постепенно выводится из употребления в пользу Client ID Metadata Documents, что позволяет вести белый список доверенных приложений, применять корпоративные политики, проверять перенаправление URI и т.п.
6️⃣ MRTR улучшает подтверждение действий, но создает новый канал социальной инженерии.
7️⃣ Кэширование каталогов инструментов создает риск "устаревших полномочий", когда отозванные инструменты все еще остаются в клиентском кэше, изменившаяся схема параметров еще не обновилась, инструмент стал опасным, а старое описание говорит, что он безопасный, и т.п.
8️⃣ Явные handles вместо скрытой сессии хороши для аудита, но опасны при утечке. Если одного знания handle достаточно для продолжения операции, его утечка в логах, промптах, трассах, истории диалога и т.п. может позволить перехватить чужой workflow или задачу.
9️⃣ Tasks вынесены в официальное расширение: появляются durable handles, polling через
Этот релиз не решает ключевую проблему MCP: протокол по-прежнему соединяет вероятностную модель с инструментами, которые способны читать данные и совершать реальные действия (но это общая проблема любой безопасности ИИ, о чем я уже писал). Сама спецификация честно говорит, что MCP открывает пути к произвольному доступу к данным и выполнению кода, а многие требования к согласию и безопасности не могут быть принудительно обеспечены самим протоколом. Но теперь вокруг него стало чуть легче строить ИБ - API Gateway, Zero Trust, централизованную авторизацию, RBAC/ABAC для инструментов, WAF, журналирование, SIEM-мониторинг и т.п.
То есть MCP стал более защищаемым, но не стал безопасным по умолчанию.
#ии #архитектура
clientInfo и serverInfo из протокола - самодекларативны и никак не верифицируемы, а значит в полный рост необходимо опираться на проверенную идентичность из OAuth, mTLS или service mesh.search, но запрещен execute_sql", "delete_project требует отдельного подтверждения", обращение к административным инструментам направляется на дополнительную проверку, а события можно нормально передавать в API Security Gateway, NDR/NAD, SIEM и observability-платформы.tasks/get и обновление через tasks/update. MCP-вызов перестает быть только мгновенной операцией – агент может запустить длительную задачу, вернуться к ней позже, продолжать действия после завершения пользовательской сессии и т.п. А значит нужно мониторить не только вызываемые инструменты, но и весь жизненный цикл задач.Этот релиз не решает ключевую проблему MCP: протокол по-прежнему соединяет вероятностную модель с инструментами, которые способны читать данные и совершать реальные действия (но это общая проблема любой безопасности ИИ, о чем я уже писал). Сама спецификация честно говорит, что MCP открывает пути к произвольному доступу к данным и выполнению кода, а многие требования к согласию и безопасности не могут быть принудительно обеспечены самим протоколом. Но теперь вокруг него стало чуть легче строить ИБ - API Gateway, Zero Trust, централизованную авторизацию, RBAC/ABAC для инструментов, WAF, журналирование, SIEM-мониторинг и т.п.
То есть MCP стал более защищаемым, но не стал безопасным по умолчанию.
#ии #архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
Model Context Protocol Blog
The 2026-07-28 Specification
The 2026-07-28 Model Context Protocol specification is out, bringing a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs.