JFrog выпустила open source agent-belt CLI для узкой, но реальной проблемы в AI software delivery: команда может поставлять тот же skill, MCP server или workflow для agent, а runtime вокруг него меняется под ногами.
В публикации JFrog agent-belt описан как Apache 2.0 evaluation framework для coding agents. Идея простая: запускать настоящий agent CLI в реальном workspace, а затем проверять, совпал ли результат с ожиданиями product team. Поэтому это ближе к эксплуатации, чем prompt benchmark, и полезнее для риска software supply chain, чем общий model score.
Что изменилось#
JFrog открыла agent-belt — CLI-based eval framework для AI coding agents. Проект подается как «ремень безопасности» для coding agents: он не мешает agent принять плохое решение, но дает командам способ поймать опасную траекторию раньше клиентов.
По данным источника, agent-belt поставляется с поддержкой семи встроенных agents: claude-code, codex, copilot, cursor, gemini, goose и opencode. Также в него входят layered rules, LLM-based scoring, exporters, sandbox providers вроде host и Docker, а также plugin contract для разных extension points.
Ключевой выбор — что именно проверяется. agent-belt оценивает сам CLI: то, что пользователь устанавливает, аутентифицирует и разрешает открывать pull requests или менять workspace. CLI запускается как subprocess в workspace, где MCP servers, skills и auth уже могут быть подключены.
Это не то же самое, что проверять только model prompt, оборачивать функцию в observability SDK или использовать benchmark с замороженным dataset. Позиция JFrog: такие подходы измеряют соседние системы. agent-belt пытается измерять операционную единицу, которая важна, когда AI-facing product доходит до пользователей: agent, его CLI, подключенные tools и поведение на реалистичной задаче.
Описанная в посте настройка намеренно строится вокруг CLI:
pip install agent-belt
belt quickstart claude-code
Предполагается, что целевой coding-agent CLI уже установлен и аутентифицирован. На выходе получается не теоретический рейтинг моделей, а вердикт о том, как конкретный agent ведет себя в конкретной среде, в конкретный день и по конкретному сценарию.
Почему это важно для software supply chain#
Проблема software supply chain здесь не в скомпрометированном package registry и не во вредоносном обновлении от maintainer. Она тоньше: команды все чаще поставляют interfaces, к которым будут обращаться чужие AI agents. Это могут быть MCP servers, coding skills, repository automation, customer triage flows или internal tools, открытые через agent runtime.
Этот runtime нестабилен. Источник приводит пример: релизы coding-agent выходят рядом друг с другом, а собственный skill команды при этом не менялся. Workflow, который на прошлой неделе работал правильно, на этой неделе может незаметно выбрать не тот tool. Product code тот же. Изменился окружающий agent.
Это важно, потому что AI agents сжимают сразу несколько trust boundaries. Package или plugin может быть open source. Agent CLI может обновляться отдельно. Model может меняться по другому графику. MCP server может иметь доступ к production-shaped data или internal tickets. Пользователь думает, что запускает знакомый workflow, а tool selection и execution path уже сдвинулись.
В классической open source security команды думают о maintainer access, build provenance, registry integrity и dependency drift. Все это по-прежнему важно. Но agent-driven workflows добавляют еще один слой: behavior drift. Код может не измениться, а execution path стать небезопасным, неполным или вводящим в заблуждение.
В этом и есть полезная часть agent-belt: он рассматривает поведение agent как объект security operations, а не как demo artifact. Если coding agent может читать данные, менять файлы, готовить ответы клиентам или запускать tools, командам нужны regression checks для такого поведения.
Что на самом деле проверяет agent-belt#
Источник описывает scenarios как JSON-файлы, которые могут лежать рядом с product code, в eval repository или вместе с fixture repositories, имитирующими customer environments. Scenario не расписывает agent пошагово, как работать. Он задает тип задачи, которую мог бы дать пользователь, а затем фиксирует, что должно быть верно после выполнения.
Пример JFrog — расследование аномалии в customer billing. Scenario просит agent разобраться, почему у клиента резко вырос счет, использовать несколько MCP sources, найти релевантное изменение и подготовить ответ без обещания refund. Checks покрывают несколько уровней:
- коснулся ли agent нужных категорий tools, даже если названия tools отличаются;
- нашел ли ключевые факты, например customer identifier и причину rate-limit;
- сохранил ли context across turns;
- изменил ли только ожидаемый file;
- содержал ли resulting diff нужную суть;
- избежал ли forbidden actions или language.
Такое сочетание важно. Deterministic checks ловят конкретные сбои: wrong file, missing string, too many turns, unexpected tool sequence. LLM scoring может оценить более качественное поведение: была ли trajectory agent разумной, приемлемо ли качество response, не выбрал ли agent unsafe shortcut.
Источник говорит, что agent-belt совмещает deterministic checks с отдельной judge model. Judge не зафиксирован framework. Команды сами выбирают provider и model. Это удачное разделение: оно не притворяется, будто одна evaluation model универсально надежна. Оно также делает trust model явной: вы не только тестируете agent, но и выбираете, кто судит тест.
Что проверить перед внедрением#
Командам, которые смотрят на agent-belt, стоит начинать не с большого benchmark theater, а с high-risk workflows. Первые кандидаты — flows, где agent может писать в repository, вызывать internal tools, готовить внешнюю коммуникацию, менять state или объединять данные из нескольких систем.
Практический review должен включать:
- какие agent CLIs реально используют developers или customers;
- какие MCP servers или skills доступны этим agents;
- какие credentials и permissions наследуют эти tools;
- какие workflows создадут customer, privacy, financial или production risk, если agent выберет wrong tool;
- какие outcomes можно проверить deterministically;
- какие outcomes требуют LLM judging и какая model будет judge;
- где запускаются scenarios: в sandbox, fixture repo или clone реального workspace;
- когда запускаются evals: при agent updates, tool changes, product releases или во всех трех случаях.
Privacy risk заслуживает отдельного внимания. Запуск реальных agent CLIs против realistic workspaces может раскрыть source code, internal prompts, customer-like data и tool outputs провайдеру agent или judge provider — зависит от configuration. Источник подчеркивает, что judge выбирает user, но это не отменяет необходимости разложить data flow.
Для команд, которые уже усиливают open source security, это должно стоять рядом с provenance и package checks, а не заменять их. См. также ранние заметки GigaTap о том, как делать security artifacts операционными и почему package test coverage имеет значение:
- https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
- https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
- https://gigatap.top/en/articles/open-source-security-needs-more-than-code
Что не стоит обещать#
agent-belt не делает AI agent безопасным. Он не доказывает, что agent будет вести себя правильно за пределами scenarios, которые написала команда. Он не отменяет permission boundaries, sandboxing, audit logs, code review, least privilege и аккуратное управление maintainer access.
Он также зависит от качества scenarios. Слабые scenarios дают слабую уверенность. Если test проверяет только наличие file, он может пропустить опасный tool call. Если judge rubric расплывчата, результат может выглядеть авторитетно, но скрывать неопределенность. Ценность появляется там, где закодированы реальные failure modes: tool, который agent не должен вызывать; source, к которому он обязан обратиться; file, который он не должен трогать; phrase, которую он не должен обещать.
Самое сильное утверждение, которое поддерживает источник, уже и полезнее: agent-belt дает командам повторяемый способ оценивать реальные coding-agent CLIs на собственных workflows. Это осмысленный control для AI-facing software supply chain operations, особенно там, где agent updates могут изменить поведение без каких-либо изменений в коде команды.
Проверка не в том, вырос ли benchmark score. Проверка в том, продолжает ли agent делать именно ту работу, которую, по мнению ваших пользователей, он делает.