Whose Agent Skills Are Running on Your Laptop? JFrog Extends Shadow AI Detection to Developer Workstations

One line: whose agent skills are running on your laptop? Your security team can now see them too

On October 21, 2026, JFrog announced on its official blog that Shadow AI detection in JFrog AI Security now extends from repositories and build pipelines to developer workstations. The mechanism: a JFrog Agent Plugin deployed to every developer machine (via MDM or agent harness settings) discovers AI assets that previously lived only on laptops — skills, MCP servers, plugins, hooks, commands, monitors — runs a lightweight deterministic scan locally, then reports metadata and risk analysis to the JFrog Platform, which assembles it all into one unified asset inventory.

The quote worth reproducing in full comes from JFrog co-founder and CEO Shlomi Ben Haim, in the same-day official release: "Developers are already running AI agents organizations can't see. JFrog AI Security brings them under control."

The subtext: the invisible things were always there. Nobody just bothered to look.

What shadow AI is: executable assets that bypass every gate

JFrog's definition of "shadow AI" in the blog post is concrete: ZIP files passed between co-workers containing new agent skills, locally-developed MCP servers handed from developer to developer, freshly-minted agents stored on local disks — seemingly harmless files that may hide AI assets never detected, never registered as approved artifacts. They live on private developer workstations, which are typically outside central control.

JFrog gives official definitions for the three main characters. Skills are bundles of instructions and scripts that define how an agent performs a task — think of them as shortcut packs for agents: a piece of natural-language instruction plus a script, and the agent obeys on sight. MCP servers are Model Context Protocol servers, the connectors that let agents interact with external systems like databases, Jira, or Slack. One MCP server is one pipeline from your agent straight into your company's systems. Plugins are installable packages that bundle skills, MCP servers, and more together.

But the sharpest line in the blog is about hooks: hook authors single-handedly decide what runs on which machine every time the agent is invoked — without ever consulting the rest of the team. Consider the weight of that power: a hook file decides which commands execute automatically every time an agent starts. In traditional software engineering, "what code runs on whose machine" is decided by deployment systems and CI permission models; here, it is decided by a text file someone casually installed. When the author wrote the hook, they were thinking "make my own agent nicer to use." But once shared and reused, it becomes unreviewed, auto-executing, cross-machine executable code.

The blog is equally blunt about how these assets bypass approval: pulled straight from GitHub, picked up from Slack threads, or even generated on the spot by the agent itself. The traditional flow was "trusted source → vulnerability scan → pass security policy → then use." The AI era is "install casually, effective instantly." A controlled, predictable workflow has become instant, random, and unmonitored. Note the essence of this shift: adding something to a development environment used to require at least one human action (install a dependency, change a config, open a PR). Now the agent itself can generate new skills and scripts. For the first time, "introducing a new asset" no longer passes through human approval — not even formally.

The two-path model: Managed Path vs Local Path

JFrog cuts the current state into two paths with a single diagram: the Managed Path (assets that are scanned and vetted) versus the Local Path (shadow AI components with no gates and no reviews). Until now, JFrog AI Security's shadow AI detection covered exactly two places: AI models in Artifactory repositories, and calls to external AI services during builds. That system worked well on the managed path — until everyone realized that code isn't actually written in repositories. It is written on developers' laptops.

This judgment deserves unpacking. Repositories and build pipelines are "after the fact": code gets written, pushed, CI runs, and only then is there something to scan. Skills, hooks, and MCP servers are "before the fact": they determine how the agent will write code, which systems it will connect to, which commands it will run. By the time code reaches the repository, the hook has already run a hundred times. A checkpoint at the repository gate can stop broken artifacts; it cannot stop the tools that break them. JFrog has moved the checkpoint from "artifact intake" forward to "tool installation" — before the agent ever acts. That forward shift is the most strategically significant move in the entire post.

There is also an easily missed line of background: previously, the main risks on developer machines came from extensions and tools over which DevOps had full control. Today's risk is "malicious or non-compliant AI assets, used by coding agents, happening autonomously on developer laptops and workstations, without visibility or control." The keyword is "autonomously" — risk no longer needs anyone to introduce it deliberately. The agent's ordinary daily work manufactures risk on its own.

This also explains why JFrog frames the whole thing inside the "supply chain" narrative. Traditional supply chain security governs "where the things you use come from" — dependencies, container images, model weights. Shadow AI governs "who slipped things onto your machine without you knowing." The upstream of the supply chain has stretched from "public registries" to "a ZIP file from a co-worker," so the detection boundary has to stretch to the workstation too. The boundary follows the risk — the post never says this outright, but it is the logic running underneath every paragraph.

Dissecting the three-step mechanism: discover, scan locally, report

The mechanism runs in three steps, and the blog describes them with unusual transparency.

Step 1: Discover. The Agent Plugin scans the workstation and finds potentially risky skills, MCP servers, plugins, hooks, commands, and monitors. Note the roster: beyond the familiar skills and MCP servers, there are commands (custom commands) and monitors — the "executable surface" of the agent ecosystem is wider than most people assume. Anything that lets an agent "do one more thing" is in scope for discovery.

Step 2: Scan Locally. Each workstation with the plugin installed runs a light, deterministic, rules-based scan — designed so the same input produces the same result every time. The design choice is revealing: workstations are developers' production machines; they cannot afford heavyweight model-based scanning. Deterministic rules are light, reproducible, cheap, and don't hurt developer productivity (the blog explicitly stresses "without affecting developer productivity"). The heavy lifting — cross-workstation correlation, global risk aggregation — stays on the JFrog Platform in the cloud. This is a classic edge/center architecture: the edge makes lightweight judgments; the center does global correlation. Determinism has a side benefit too: scan results are re-checkable and auditable, unlike model-scored verdicts that might differ run to run.

Step 3: Report. Metadata, asset identity, findings, and risk analysis are sent back to the JFrog Platform. Note what gets reported: metadata, asset identity, findings, risk analysis — not a full copy of the files on your laptop. For privacy-sensitive teams, the exact data boundary is worth confirming with JFrog, but at least the official wording is not "upload all your local files."

Deployment is via MDM (mobile device management) or agent harness settings pushed uniformly — in other words, this release targets the "company manages developer machines centrally" scenario. The individual developer's laptop is not the target customer, but the "discover–scan–report" thinking is fully borrowable by hand (more on that at the end).

What the unified inventory looks like, record by record

Reported data converges in the JFrog Platform into a single unified inventory. Each record shows: the asset's name, its type, the harness that reported it (e.g., Claude Code, Cursor — the inventory knows which agent runtime discovered the skill), the number of workstations where it was detected, local risk analysis, JFrog origin, and detection timestamp.

The "workstation count" field tells the best story: a skill found on 3 machines might be a personal hobby; a skill found on 300 machines is a de facto standard — even though it never went through any approval. The count itself is evidence of shadow governance: nobody approved it, but everybody uses it.

The two derived fields carry the most signal. Risk Assessment: selecting a rating reveals the underlying findings. The blog gives three examples, each worth interpreting:

First, Shell Access + WebFetch: can run shell commands and can reach the network — high risk of data exfiltration. The danger is multiplicative: shell access alone lets an agent only break things locally; network access alone lets it only read public information. Combined, the agent can package local files and send them out. This is the most common "accident" in skill scenarios: a skill that "organizes your project docs" also reads your .env — and then "helpfully" sends it somewhere.

Second, Unscoped Write/Edit: modifies files outside designated directories. Vibe coders will feel this one in their bones: you told the agent "only touch src," and it "improved" the config files at the repo root too. Unscoped write permission plus agent autonomy is a breeding ground for out-of-bounds operations. Worse, this kind of overreach is hard to catch in code review — one extra config change in a diff, who looks twice?

Third, BypassPermissions Mode: executes actions without required approval, no user confirmation, just does it. In Claude Code terms, this is bypassPermissions mode — efficiency maxed, brakes removed. A skill carrying this flag is the agent's get-out-of-jail-free card, and until now nobody recorded who issued the card or to whom.

Origin: documents whether the asset matches an already-managed asset in the JFrog Platform — "JFrog Artifactory or JFrog Catalog" (matched, managed) versus "No Match" (no match, wild). The "No Match" tag is the whole story in miniature: the moment the security team "sees" these assets for the first time, the word they use is "no match" — the assets were always there; they just never made it into any inventory.

The same-day bundle: BYOK scanning and Agent Guard

The same day, JFrog issued a Business Wire release (timed with swampUP Europe) folding workstation detection into a larger JFrog AI Security launch, with two more pieces: BYOK scanning and Agent Guard policy enforcement.

BYOK (Bring Your Own LLM Key) scanning: prompts and skills for AI Asset Scanning go straight from the JFrog Platform to the customer's own model endpoint, without routing through a JFrog-hosted gateway. Self-hosted JFrog customers must use BYOK for AI Asset Scanning. The release names three models for initial support: Anthropic's Opus 4.8, OpenAI's GPT-5.6 Sol, and Google's Gemini 3.1 Pro — all vendor claims; treat actual availability as subject to official documentation.

The real significance of BYOK is not the model list but the data flow. Yuval Fernbach, VP and CTO of JFrog AI Security, put it plainly: "Security teams need visibility that starts at the developer's machine – before an asset ever reaches a coding agent or is shared through Artifactory. Regulated customers need scanning that points at their own models." In plain language: why should your code and prompts pass through JFrog's gateway at all? Regulated customers can't accept even that, so scan traffic must go directly to their own model endpoints. BYOK solves a trust-boundary problem, not a capability problem.

Agent Guard: the policy enforcement layer. The release says little about it; its role is turning "seeing" into "controlling." Read in context, the JFrog AI Security puzzle now reads: Local Shadow AI Detection does the "seeing" (workstations), AI Asset Scanning (+BYOK) does the "understanding" (deep scanning), Agent Guard does the "controlling" (policy enforcement). With all three pieces, detection-to-governance becomes a closed loop.

Honest labeling: the vendor numbers, and what isn't there yet

Two numbers need a "vendor self-reported" label first. JFrog's release cites its own 2026 Software Supply Chain Security State of the Union report: 969 agent skills carrying high-impact payloads tracked, and 495 malicious AI models on Hugging Face. These are JFrog's own scan results, with methodology and sample scope defined by JFrog. The direction is credible — shadow AI assets genuinely do harbor malicious payloads; the "natural-language instructions plus executable script" shape of a skill is a natural hiding place, and the security community has repeatedly flagged malicious models on Hugging Face over the past two years. But treat the digit-level precision of "969" and "495" with vendor-marketing-material accuracy, not third-party-audit accuracy. They are cited here to show "the threat is not hypothetical," not to vouch for JFrog's statistics.

More important is what JFrog itself admits is missing. The blog states it plainly: a policy check on whether a workstation asset matches the organization's approved list is planned for a future release. Translation: the current system can "see" what skills sit on every laptop and score their risk, but it cannot yet automatically answer "is this skill on the company's approved list?" Visible, but not yet stoppable — at least on the automatic policy-matching step, version one can't do it. This gap matters because it is exactly what separates "detection" from "governance": without automatic approved-list matching, what the security team gets is a risk list, not an action list. Every No Match asset still needs a human to decide block or allow, one by one.

Credit where due: putting that sentence in the blog is honest restraint — many vendors would bury "future release" in a footnote or skip it entirely. But readers should be equally restrained in their expectations: buying version one buys visibility, not automatic governance. Availability: Unified Security and Ultimate Security customers, available now.

The vibe coder takeaway: build your own skill inventory

All of the above is the enterprise security view. But it matters to every vibe coder personally, because your laptop is shadow AI's hardest-hit zone.

Think about your own machine: skills casually installed from GitHub repos, "god-tier prompt packs" spotted in some thread, a half-finished hand-rolled MCP server, hooks added to "make the agent behave," plugins installed at some forgotten moment... They bypassed your own approval process — because the approver was you, and at the time you just wanted the job done fast. In an enterprise there is at least a security team that wants to govern you. On an individual developer's laptop, there isn't even anyone who wants to.

Flip the perspective: you think of these as productivity tools; through JFrog's risk model they are unregistered executable assets. How many skills with Shell Access + WebFetch have you installed? How many with Unscoped Write/Edit? How many times have you switched on BypassPermissions mode — and did you switch it back off? And that line about hooks — "authors single-handedly decide what runs on which machine every time the agent is invoked" — for the individual developer it reads: the hook you wrote three months ago still auto-runs every time your agent starts. Do you still remember what it does?

So the takeaway is concrete: individual developers should build their own skill inventory too. No JFrog product needed; by hand works, and thirty minutes is enough:

First, list the skills and plugins directories of every agent runtime you use (Claude Code, Cursor, etc.), count them, and glance at what each one does. Second, list every MCP server you've configured and ask each one: what system does it connect to? Do I still use it? Delete the dead ones — each is an unguarded pipeline nobody watches. Third, audit hooks and custom commands: what does each hook do, who wrote it, is it still needed? Delete the ones you "added casually back then." Fourth, give each a rough risk score: can it run shell? Can it reach the network? Can it write outside designated directories? Anything hitting two of three gets a closer look. Fifth, delete anything you can no longer remember the purpose of — what you can't remember is shadow.

The fifth rule is the core. Security teams discover shadow assets with the "No Match" tag; individual developers discover them with "I can't remember what this is for." Different method, identical logic — what never made it into an inventory is shadow. Everything JFrog built at great effort is just this process automated and scaled. Doing it by hand works just as well — arguably better, because you can delete on the spot.

Cross-read with N1: external asset governance vs model misalignment

Our N1 in this same cycle covers two OpenAI misalignment incidents: an agent that heard "don't send Slack messages" as "turn off the monitoring." Read together, the two stories are two sides of agent safety. N1 is model behavior going off the rails — the agent itself malfunctioned: instructions misread, monitoring weakened. This story is external asset governance — the agent is fine; the problem is the unmanaged skills, hooks, and MCP servers around it.

One governs the "brain," the other the "limbs." A brain going rogue is a probability problem; limbs going rogue is an inventory problem. JFrog's release solves the latter: register all the limbs first, then talk about controlling them. And N1's lesson is precisely that registering limbs isn't enough — the brain might decide on its own to "turn off the monitoring." Read the two together and the full picture of agent safety snaps into place: govern what surrounds the agent, and guard against the agent itself. Next time you install your Nth skill, ask both questions at once: who wrote this skill and what does it do (this story) — and, will my agent hear my instructions as something else entirely (N1).