JFrog’s new open source agent-belt CLI targets a narrow but real gap in AI software delivery: teams can ship the same skill, MCP server, or agent-facing workflow, while the agent runtime around it changes underneath them.
The JFrog post describes agent-belt as an Apache 2.0 evaluation framework for coding agents. Its core idea is simple: run the actual agent CLI against a real workspace, then check whether the outcome still matches what the product team expects. That makes it more operational than a prompt benchmark and more relevant to software supply chain risk than a generic model score.
What changed#
JFrog has open-sourced agent-belt, a CLI-based eval framework for AI coding agents. The project is positioned as a “seat belt” for coding agents: it does not prevent an agent from making a bad decision, but it gives teams a way to catch bad trajectories before customers do.
According to the source, agent-belt ships with support for seven bundled agents: claude-code, codex, copilot, cursor, gemini, goose, and opencode. It also includes layered rules, LLM-based scoring, exporters, sandbox providers such as host and Docker, and a plugin contract across extension points.
The important design choice is what gets tested. agent-belt evaluates the CLI itself — the thing a user installs, authenticates, and allows to open pull requests or touch a workspace. It runs that CLI as a subprocess against a workspace where MCP servers, skills, and auth can already be wired in.
That is different from testing only a model prompt, wrapping a function in an observability SDK, or using a benchmark that freezes a dataset. JFrog’s claim is that those approaches measure adjacent systems. agent-belt tries to measure the operational unit that matters when an AI-facing product reaches users: the agent, its CLI, its connected tools, and its behavior over a realistic task.
The setup described in the post is intentionally CLI-first:
pip install agent-belt
belt quickstart claude-code
That assumes the target coding-agent CLI is already installed and authenticated. The result is not a theoretical model ranking. It is a verdict on how a given agent behaves in a specific environment, on a given day, with a given scenario.
Why it matters for the software supply chain#
The software supply chain problem here is not a compromised package registry or a malicious maintainer update. It is more subtle: teams are increasingly shipping interfaces that other people’s AI agents will call. Those interfaces may include MCP servers, coding skills, repository automation, customer triage flows, or internal tools exposed through an agent runtime.
That runtime is not stable. The source gives the example of coding-agent releases landing close together while the team’s own skill has not changed. A workflow that behaved correctly last week may silently choose the wrong tool this week. The product code is the same. The surrounding agent changed.
That matters because AI agents collapse several trust boundaries. A package or plugin may be open source. The agent CLI may be updated separately. The model may change on a different cadence. The MCP server may have access to production-shaped data or internal tickets. The user may believe they are running a familiar workflow, while the tool selection and execution path have shifted.
In classic open source security, teams worry about maintainer access, build provenance, registry integrity, and dependency drift. Those still matter. But agent-driven workflows add another layer: behavior drift. The code can remain unchanged while the execution path becomes unsafe, incomplete, or misleading.
That is the useful part of agent-belt: it treats agent behavior as something that belongs in security operations, not as a demo artifact. If a coding agent can inspect data, modify files, draft customer replies, or trigger tools, then teams need regression checks around those behaviors.
What agent-belt actually checks#
The source describes scenarios as JSON files that can live alongside product code, in an eval repository, or with fixture repositories that mimic customer environments. A scenario does not tell the agent step by step how to work. It gives the kind of task a user might give, then asserts what must be true afterwards.
JFrog’s example is a customer billing anomaly investigation. The scenario asks the agent to investigate a customer whose bill spiked, use multiple MCP sources, identify the relevant change, and then draft a reply without promising a refund. The checks cover several layers:
- whether the agent touched the right categories of tools, even if tool names vary;
- whether it found key facts such as the customer identifier and rate-limit cause;
- whether it preserved context across turns;
- whether it modified only the expected file;
- whether the resulting diff contained required substance;
- whether it avoided forbidden actions or language.
That mix is important. Deterministic checks can catch concrete failures: wrong file, missing string, too many turns, unexpected tool sequence. LLM scoring can inspect more qualitative behavior: whether the agent’s trajectory was sound, whether the response quality is acceptable, or whether the agent took an unsafe shortcut.
The source says agent-belt combines deterministic checks with a separate judge model. The judge is not fixed by the framework. Teams choose the provider and model. That separation is a useful design choice because it avoids pretending that one evaluation model is universally trusted. It also makes the trust model explicit: you are not only testing an agent; you are choosing who judges the test.
What to check before acting on it#
Teams looking at agent-belt should start with high-risk workflows, not broad benchmark theater. The first candidates are flows where an agent can write to a repository, call internal tools, draft external communication, mutate state, or combine data from several systems.
A practical review should include:
- which agent CLIs are actually used by developers or customers;
- which MCP servers or skills are reachable from those agents;
- what credentials and permissions those tools inherit;
- which workflows would create customer, privacy, financial, or production risk if the agent chose the wrong tool;
- which outcomes can be checked deterministically;
- which outcomes need LLM judging, and which model will act as judge;
- whether scenarios run in a sandbox, a fixture repo, or a real workspace clone;
- whether evals run on agent updates, tool changes, product releases, or all three.
The privacy risk deserves separate attention. Running real agent CLIs against realistic workspaces can expose source code, internal prompts, customer-like data, and tool outputs to the agent provider or judge provider, depending on configuration. The source emphasizes that the judge is chosen by the user, but that does not remove the need to map data flow.
For teams already tightening open source security, this belongs next to provenance and package checks rather than replacing them. See also GigaTap’s earlier notes on making security artifacts operational and why package test coverage matters:
- 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
What not to overclaim#
agent-belt does not make an AI agent safe. It does not prove that an agent will behave correctly outside the scenarios a team writes. It does not remove the need for permission boundaries, sandboxing, audit logs, code review, least privilege, or careful maintainer access.
It also depends on scenario quality. Weak scenarios will produce weak confidence. If a test only checks that a file exists, it may miss a dangerous tool call. If a judge rubric is vague, the result can look authoritative while hiding uncertainty. The value comes from encoding real failure modes: the tool the agent must not call, the source it must consult, the file it must not touch, the phrase it must not promise.
The strongest claim supported by the source is narrower and more useful: agent-belt gives teams a repeatable way to evaluate real coding-agent CLIs against their own workflows. That is a meaningful control for AI-facing software supply chain operations, especially where agent updates can change behavior without any change to the team’s own code.
The test is not whether a benchmark score improves. The test is whether the agent still does the job your users think it is doing.