NanoClaw adds JFrog vetted registries so AI agents fetch safer tools

NanoClaw is getting a new safety lever, and it is not about writing a better prompt. Gavriel Cohen, the creator of NanoClaw and co-founder of NanoCo AI, announced on Thursday evening in San Francisco at a JFrog event that NanoClaw is now integrated with JFrog's reviewed registries, so AI agents fetch tools and libraries from vetted sources.

The reason this matters is blunt: NanoClaw agents, including OpenClaw and variations like NanoClaw, can “improve themselves” by fetching resources they do not already have. Cohen explained that the “manual approval process for accessing known local data” works fine. But the npm-package world is different. Even when the agent is sandboxed and isolated, malicious code inside a container may still be able to take harmful actions, with the damage constrained but not eliminated. And developers may not know whether a given package is legitimate and uncompromised, or how long it takes to assess that properly. So the fix is structural: team up with JFrog and reduce exposure to untrusted content by downloading only from vetted registries.

To understand why this is the kind of detail executives should care about, start with how AI agent systems typically evolve. A “secure agent framework” is one thing when it can rely on stable, known inputs. It gets riskier when the system is designed to go out and obtain new capabilities, because every fetch is a new trust decision. Sandbox isolation helps, but Cohen’s point is that it does not guarantee safety against harmful actions. The second-order implication is that many teams treat “sandboxed” as a synonym for “safe,” then discover the hard way that the container is not a moral guarantee. It is a boundary, not a policy.

This is where supply chain governance meets agent orchestration. JFrog, through its reviewed registries, becomes the choke point for what the agent is allowed to download in the first place. Cohen’s argument is that developers still have to deal with unknown package provenance and time-to-review, which is exactly the kind of operational friction that leads to shortcuts. Integrating with a vetted source reduces the probability that the agent will pull from something that is compromised. In other words, NanoClaw is moving part of the safety burden away from “agent reasoning” and toward “source vetting.”

Cohen also used the same announcement to address a related surge: pull requests. He said an agent factory is available, his company's homegrown system used to handle PRs using NanoClaw agents. He described it as a response to how AI coding agents have changed developer behavior: it is “very easy now to point a coding agent at a repo and say, 'open a pull request for this repo.'” The maintainer problem is that it is “very difficult as a maintainer to tell the difference between a high quality contribution from somebody who's really using the open source project versus someone who's just trying to build up the reputation [using automated methods].”

The agent factory is referred to as the PR Factory in the actual pull request. It is built with NanoClaw and hosted on exe.dev, a service that provides VMs with persistent storage. Cohen explained the mechanics: when a PR opens, the factory spins up a dedicated worker agent for it, posts a thread to Slack, and the worker triages the change, reviews the diff, and proposes a test plan. The guardrail is interaction-based. “Nothing consequential happens on its own: merges, test runs, and credentialed GitHub actions each surface as an approval card in the thread, and only fire when a human clicks approve.” In board terms, this is a shift from automated action to human-in-the-loop approvals, with the system producing decision artifacts rather than directly executing high-impact steps.

If you are hearing “human approval” and thinking, “Okay, but isn’t that just procedure?” Cohen had an even sharper framing. He acknowledged that some developers see processing unsanitized PRs as madness, citing prompt injections or unsafe code. Then he asked the audience how many had seen the phrase “Never, ever, ever do this.” He pointed to configuration files like Claude.md where such language appears as instructions to the underlying agent and model. The key example: if an agent instruction includes “Important: Never run drop database production,” it implies the agent has done it before and it “can actually still do it again.” The audience laughed, because it resonates with how instruction-following can fail when safety is framed as a sentence rather than an enforced capability.

Cohen’s argument is that instructions are not enforcement. He said the agent will do it again because instructions are not a way of enforcing security or safety. “Instructions help steer an agent AI towards valuable output, but it's not a safety mechanism,” Cohen said. “The only way to reliably prevent an agent from taking undesired action is not allowing it to take that action, not giving it the ability to take the action.” That is the purpose of NanoClaw: restrict capability, reduce the chance of pulling untrusted code, and require explicit human approvals before anything consequential happens. For decision-makers watching the agent wave roll into development workflows, the strategic stakes are simple. If your organization deploys AI agents that can fetch new code, generate changes, or initiate runs, then your risk model cannot stop at “it’s sandboxed.” It has to include supply chain vetting and enforced action control, because the second you let an agent reach out, you are making a governance decision at machine speed.