- JFrog says AI skills, MCP servers and plugins often sit on developer laptops outside central review. JFrog sells AI security products, so this is a vendor's view.
- JFrog's new plugin scans workstations and reports to a central inventory. JFrog says a policy check, which asks whether an asset is allowed, is planned for a later release.
- Ask who approves agent add-ons, whether laptops are covered by inventory, and what each agent is permitted to run.
Software review was built for code, not for a shared ZIP file
Many companies have a routine for new software. It comes from an approved source, gets scanned, and must pass policy before anyone uses it. JFrog, a software supply chain vendor, says that routine does not cover the add-ons that AI coding agents now use.
JFrog published the argument on October 21 alongside a product update. The company sells AI security tools, so treat the framing as a vendor's. Even so, the mechanism it describes is worth understanding.
What the files are and how they spread
JFrog's post names three kinds of add-on. A skill is a package of written instructions and scripts that tells an agent how to do a job. An MCP server, from Model Context Protocol, is a bridge that lets an agent reach tools such as databases, Jira or Slack. A plugin is one installable bundle that can hold skills, MCP servers and other items.
JFrog says these arrive in ordinary ways. Co-workers share ZIP files containing new skills. Developers pass locally built MCP servers to each other. Assets come from GitHub, from Slack threads, or are generated by the agent itself.
In JFrog's words, such assets bypass standard security checks. It describes two paths: a managed one where assets are scanned and vetted, and a local one where they go undetected. The company calls the second kind "Shadow AI".
Why hooks make the point sharply
JFrog singles out hooks, which run each time an agent is called. In JFrog's telling, one author can decide what executes on which machine, with no input from teammates.
That is the human side of the story. A developer who installs a helpful skill from a colleague is not trying to evade policy. The process simply has no step where anyone looks.
How the new detection works
JFrog's earlier AI Security work looked at two places. One was AI models held in its Artifactory repositories. The other was builds that call outside AI services. That covered the managed path. The new feature reaches the laptops.
JFrog describes a plugin, installed on each workstation, that works in three stages. First, it discovers add-ons that could be risky: skills, MCP servers, plugins, hooks, commands and monitors. Next, it runs a light, rules-based check on the machine itself, built to give identical results for identical input. Finally, it passes the asset's identity, its findings and a risk assessment up to the JFrog Platform.
The platform then builds one inventory. JFrog says each record shows the asset's name and type, the agent harness that reported it (such as Claude Code or Cursor), how many workstations hold it, a local risk analysis, its JFrog origin and a detection timestamp.
JFrog gives three examples of risk findings. Shell access combined with web fetching is flagged as a high risk of data exfiltration. Unscoped write or edit access can modify files outside designated directories. Bypass-permissions mode lets actions run without required approval.
The origin field reports only whether an asset matches one JFrog already manages in Artifactory or Catalog, or has no match. It does not say whether the asset is acceptable.
What the announcement does not show
The post offers no numbers on how common unvetted AI assets are, and no incident. It states the risk as a design gap, not a measured loss. Treat it as a description of a control, not evidence of scale.
The post also states a limit. Judging whether an asset is allowed by organizational policy is a capability JFrog says it plans to add in a future release. Today the product reports what exists and how risky it looks. The approving still falls to your people.
JFrog's illustration of that planned check is useful. A GitHub connector on a laptop could be fine if it is the one your company approved. It would be a problem if it was built from an unknown repository. That judgement is the future capability, not something the origin field does today.
Questions for your security and engineering leads
Start with inventory. Can your team say which skills, MCP servers and hooks run on developer machines today? If the answer is a survey, you do not have an answer.
Ask who approves a new agent add-on and where that approval is recorded. Ask whether review covers the instructions inside a skill as well as its scripts.
Ask what each coding agent is permitted to run. Shell access paired with web access is the combination JFrog flags. A team can likely check that in its own agent settings.
The lesson here is that the unit of software supply chain has widened. It now includes text that steers an agent. Governance that stops at the repository leaves the local path, which JFrog says often goes unreviewed, outside its reach.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: JFrog.
