JFrog adds checks for unvetted AI tools on developer workstations

JFrog is bringing security checks to AI tools installed on developers’ machines, including assets that never pass through a company’s central software repositories. Announced October 21 at swampUP Europe 2026, the update pairs Local Shadow AI Detection with instruction scanning through customers’ own model accounts. JFrog says the features are available to Unified Security and Ultimate Security customers.

The repository is no longer the only checkpoint

Previously, JFrog’s Shadow AI detection scanned models in Artifactory, its software repository system, and calls to external AI services during software builds. The new workstation coverage addresses a different route: developers receiving files through GitHub, Slack, shared ZIP archives or agents generating assets themselves. Those files can enter a working environment without following the centrally managed path.

The assets include skills—bundles of instructions and scripts defining an agent’s task—and plugins that package capabilities together. Detection also covers Model Context Protocol, or MCP, servers: connectors that let agents interact with systems such as databases or Slack. JFrog’s concern is not simply where these files came from. Its launch announcement says they run with developers’ permissions and credentials.

Local detection requires the JFrog Agent Plugin on each workstation. It discovers skills, MCP servers, plugins, hooks and other agent components, then runs a lightweight, rules-based scan locally. JFrog describes that scan as deterministic: the same input produces the same result. Metadata, asset identity, findings and risk analysis are then sent to the JFrog Platform.

An inventory is not an approval decision

The resulting inventory records each asset’s name, type, reporting agent environment, workstation count, local risk analysis, origin and detection timestamp. Origin matching distinguishes assets already present in JFrog Artifactory or its Catalog from those with no match. That gives security teams a way to separate familiar components from items outside their managed inventory.

JFrog’s product article identifies several signals behind the risk ratings, giving administrators more detail than a single severity label:

• Shell access combined with web fetching, which JFrog flags as a high risk for data theft.
• Unrestricted write or edit access that can modify files outside designated directories.
• A permission-bypass mode that executes actions without required approval.

There is an important distinction between matching an asset and deciding whether it is permitted. The press release describes cross-referencing assets to understand what is approved. But the more detailed product article places the organizational-policy check in a future release. It illustrates the difference with an approved GitHub MCP server versus one built from a random repository.

Instruction scanning uses a separate model account

The other addition, AI Asset Scanning with Bring Your Own LLM Key, or BYOK, uses a customer’s own language-model account to examine skills, coding-agent plugins and packages. Unlike the local rules-based check, JFrog describes this as semantic scanning: assessing the meaning and intent of material that an agent may read and act on.

The routing distinction concerns the model endpoint, not keeping all content on the laptop. Prompts and skills go from the JFrog Platform directly to that endpoint, bypassing a JFrog-hosted gateway. Customers use their existing provider contracts and receive billing through that provider. For self-hosted JFrog customers, BYOK is the only supported route for AI Asset Scanning.

JFrog lists initial BYOK support for Anthropic’s Opus 4.8, OpenAI’s GPT 5.6 Sol and Google’s Gemini 3.1 Pro. The company frames the scanning need around a difference from conventional code review: agent skills and plugins can carry plain-English instructions that software agents follow, rather than only code with identifiable vulnerabilities.