In March we scanned about 19,000 OpenClaw skills and published the numbers. Since then the registry more than tripled. So we did the only honest thing: we re-scanned the whole thing.
63,697 skills — 98% of the live registry. We downloaded each one, extracted its code, and counted what it can actually do: what it reads, what it runs, where it sends data. Not what we think it intends. What its code is capable of touching.
This is a capability census, not a threat list. The most useful thing we can tell you before you install a skill is not a verdict — it's a fact: here is what this code can reach.
1 in 8 skills can read your environment variables
12.8% of skills — about 1 in 8 — contain code that reads
environment variables. That is the single number we would put on a billboard, because
it is a measurement, not an opinion. Either the code touches process.env
(or its language equivalents) or it doesn't. We can show you the line.
Notice the noun we are using: environment variables, not "credentials." This matters.
Environment variables are where API keys and tokens often live — but most env reads are
NODE_ENV, PATH, a port number.
Reporting "1 in 8 skills can steal your credentials" would be a lie dressed as a statistic. The
honest claim is narrower and still worth knowing: 1 in 8 skills can read the place your secrets
tend to sit.
On a corpus three times larger than March's, the figure barely moved — it was 1 in 6 then, 1 in 8 now. The behavior is structural, not a sampling artifact.
1 in 16 can read env vars and reach the network
6.2% of skills — 1 in 16 — can both read environment variables and make outbound network calls. This is the shape of data exfiltration: a thing that can read secrets, and a thing that can send them somewhere.
But read that sentence carefully, because we are. This is co-occurrence, not proof. Both capabilities are present in the same skill. We do not verify that the env-var read ever flows into the network call. They might be in unrelated functions, in different files, on paths that never connect. The capability to exfiltrate is not the act of exfiltrating. We report the shape and we are explicit that it is only the shape.
Most of these 1-in-16 skills are completely legitimate — an integration that reads an API key from the environment and calls the API it's an integration for. That is exactly what it should do. The number is useful precisely because it is large and mundane: it tells you the exfiltration shape is the normal shape of a connected tool, which is what makes the genuinely malicious ones hard to spot.
1 in 267 can touch a real secret store
Here is the number we would stake our name on. 0.4% of skills — 1 in
267 — contain code that reaches a real credential store: ~/.ssh,
~/.aws/credentials, a system keychain, cloud-credential files.
This is the bulletproof "can read your actual secrets" capability, and we keep it deliberately
separate from the broad env-var number. When a skill that has no business touching your SSH keys
contains code that opens ~/.ssh/id_rsa, that is not a heuristic
judgment. That is a fact you want before you install it. It is rare — and that rarity is the point.
The narrow, certain number is more honest than a big scary one.
Why we don't lead with "X% are dangerous"
We could. We have a tiering system, and it would let us write a headline like "5% of skills are Dangerous." We're not going to, because that number is a judgment layered on top of the capability facts — and judgments are exactly the thing a security tool should be most careful about.
We've been honest about this before: we graded our own scanner against real attacks and it failed two of six. The same humility applies here. When we audited our own tier verdicts against the actual content of flagged skills, our heuristics over-flagged — they called things risky that, read in context, weren't. Pattern matching on a document that mixes prose, documentation, and code can't reliably tell "here is a dangerous command" from "here is an example of a dangerous command not to run." That distinction is semantic, and it's the next thing we're building toward.
So we lead with what survives scrutiny: capability exposure. A capability is a measurement. A tier is an interpretation. We'll keep showing both — but we'll never dress the interpretation up as the measurement, and we'll keep telling you which is which.
The thing worth doing
We can't tell you whether a skill will steal your keys. Almost no static tool honestly can. But we can tell you which ones can — which ones contain the code to read the place your secrets live, reach the network, or open your SSH directory — and we can show you the line that does it.
That's the whole product. Before you install the next skill, check the one you're about to trust. The capabilities are already counted; they're sitting on its page.