Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.

Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AST,оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.

Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.

В Grafana Alerting появилась полезная штука для тех, у кого одним инстансом пользуются несколько команд.

Исторически маршрутизация уведомлений жила в одном общем дереве. Можно было выделить каждой команде свою ветку, но конфигурация всё равно оставалась общей. Хочешь поменять доставку алертов своего сервиса — правишь дерево, в котором живут и все соседи. С ростом числа команд удовольствие сомнительное.

В Grafana 13.2 в GA появились несколько независимых деревьев notification policies. Теперь можно завести отдельное дерево для команды или сервиса и явно направить в него алерты нужных правил. У каждого дерева — своё управление через UI, API или Terraform.

Самое полезное здесь — возможность раздельно менять и выкатывать настройки маршрутизации. Команда платежей правит свои маршруты, не затрагивая конфигурацию и состояние уведомлений платформенной команды.

Переносить всё разом тоже не требуется: существующие правила продолжат использовать политику по умолчанию, пока им не назначат другую.

Среда выполнения для агентов ИИ, созданная для реальной работы с кодом. Реализация на Bash исключает зависимости от среды выполнения, в то время как C, Go и Rust используют одну и ту же семантику сессии, инструмента, очереди отображения, events.jsonl и stream-json.

Возможности:
— никаких зависимостей - только bash, awk, curl, rg.
— четыре совместимые среды выполнения - bash/c/go/rust - используют один и тот же цикл работы агента, инструменты и семантику сессий.
— Async SubAgent - встроенный инструмент SubAgent, который делегирует подзадачи независимым сессиям, работающим параллельно, а результаты автоматически передаются обратно. Поддерживает режим fork для наследования контекста, изоляции сессий и распространения ошибок.
— компакция с учетом кэша - алгоритм DP economics решает, следует ли и в каком объеме производить компакция.
— сохранение сессии - в рамках проекта, с возможностью возобновления, с возможностью создания форка, с возможностью сжатия.
— удобен для машинного обучения - stream-json выводит структурированные события для обработки клиентом.
— система навыков - загрузка навыков по запросу без искажения будущих подсказок.

Объявите агентную задачу со спецификациями рабочих пространств и шлюза. AX изолирует ее, подключает рабочее пространство, защищает сеть и помогает выполнять масштабируемую работу.

AX - это высокопроизводительный декларативный инструмент управления для запуска миллиардов автономных рабочих нагрузок агентов в кластере. Он работает поверх Agent Substrate для изолированного выполнения и рассчитан на выполнение миллиардов задач в кластере. Если вы использовали Kubernetes, ax будет работать аналогично.