Picture this: you run platform engineering at a company where developers have started writing agent skills. Some live in repos, some in a wiki, some on laptops. Someone in security asks a simple question: which skills are running right now, and who approved them? You don't have an answer. So you start reading about registries.
One of the more useful things you find is a competitor explainer from Port, the internal developer portal company. It's titled "What does the JFrog Agent Skills Registry do?" and it describes JFrog's new product fairly. In Port's words, the registry "stores, scans, signs, and versions the agent skills your developers write, so every skill an agent picks up is vetted before it runs." JFrog calls it the first enterprise-grade private skills registry. It holds skills, MCP servers and models in one system of record, with NVIDIA NemoClaw as the first runtime integration.
Then comes Port's actual argument, which is about scope. A registry, it says, "governs the skill at rest. How that skill is certified for use, scoped to an owner, and cleared to production is governed by an Agentic SDLC Platform, and a maturing organization runs both." You'll notice who is saying this. It's a vendor comparison written by one of the vendors, and the post says so. Port credits JFrog where it is stronger: malware and CVE scanning, signing and immutable versioning, and breadth across agent frameworks. It claims for itself what a registry leaves out: mapping a skill to owners, dependencies and permissions, catching duplicates against the existing catalog, and deciding whether a skill "fits your models and budget."
There are no figures in the post. That's a relief, because you have nothing to check them against. What you get instead is three metrics you could track yourself. The first is skill inventory coverage, "the share of running skills that are registered and owned." The second is the share of skills "scanned and signed before an agent can use them." The third is the time "to trace the offending skill version, its source, and its approver." Your security colleague's question maps onto the first and third almost word for word.
Now the turn, and it points at Port itself. The APIs.io catalog holds Port's own surface, so you can look at what the company would have to offer if it wanted to practice what the post preaches. The provider page lists API pages including the Port Blueprints API and Port Entities API, where the ownership and dependency map lives. There is a Port Scorecards API for certification gates, and a Port Actions API and Port Action Runs API that an agent would trigger and follow. On the agent readiness score, spec presence, agentic access, auth clarity and the rate limit signal are lit.
The overall numbers are modest. The Kin Score is 26.0, in the emerging band, with discoverability at 73.2 against contract quality and contract governance both at 0.0. Agent Readiness is 17.9, agent-aware. The unlit dimensions include agent skills and the MCP server, on a company arguing it should govern both.
Here is where the catalog is careful about itself, and you should be too. The record does not match the surface the post describes, and that may be on the catalog's side. A portal with ten API pages and contract quality at zero suggests the contracts were not read, not that they are missing. Those low numbers are a measurement, not a verdict. The post's own conclusion is that the record should be re-read before it is held against the company that drew the line.
So what do you take away? First, that a registry and a governance layer are different jobs, and the split Port draws, between the artifact and its place in the engineering estate, is worth keeping whichever vendor you buy from. Second, that you can borrow the three metrics today: coverage of registered and owned skills, the share scanned and signed before use, and the time to trace a bad skill to its version, source and approver. Third, that a vendor's account of a rival is still a vendor's account, and a catalog score about a vendor is only as good as the reading behind it. Hold both with that in mind when you bring your answer back to security.
Read the original: https://apis.io/2026/10/21/port-says-a-skills-registry-governs-the-skill-at-rest-not-the-skill-in-use/