1 in 6 OpenClaw skills can read your environment variables — and why we won't call that 'credential access'

The number we could put in this headline is "8% of OpenClaw skills are dangerous." We're not going to — because that's a judgment, not a measurement, and we'd rather lead with something you can check against our code. Here is the number we can actually defend: 17.1% of skills — 1 in 6 — can read your environment variables. And here is the more interesting part: that is not the same as saying 1 in 6 skills can read your credentials. Most tools would have called it that. It's an overclaim, and the gap between the two is the whole point of this post.

A measurement is not a judgment

There are two kinds of number a scanner can report, and they are not the same kind of thing.

A capability count is a measurement. A skill either reads process.env or it doesn't; either contains an outbound network call or it doesn't. You can point at the line. Two people running the same extractor over the same corpus get the same count. There is no opinion in it.

A tier — "Trusted," "Caution," "Dangerous" — is a judgment. It's a threshold layered on top of heuristics: weights, combinations, score cutoffs that we chose. "8% Dangerous" is a defensible judgment, but it is a judgment, and a judgment is probe-vulnerable in a way a measurement isn't. So when we have the choice, we lead with what we measured, not with what we concluded.

Here is what we measured, across the full corpus of 19,461 skills:

Three of those four numbers are easy. The fourth is the one that keeps us honest.

Why we won't call it "credential access"

It would be tempting — and it would land harder — to call that 17.1% "credential access." 1 in 6 skills can read your credentials. It's a better headline. It's also wrong.

Our environment-variable capability keys on process.env reads. That construct matches any environment variable. NODE_ENV is an environment variable. So is PATH. So is TERM. Reading the environment is not the same as reading a secret, and an extractor that pattern-matches process.env cannot tell the difference. So we report what the extractor actually knows: the skill reads environment variables. Full stop. What's in your environment — whether that's an API key or the string development — is context we don't get to assume.

The capability that genuinely means "can read a real secret store" is a different, narrower one. It keys on the specific places secrets actually live: .ssh, .aws/credentials, the system keychain. We call it credential_store, and its prevalence is 0.6% — about 1 in 180 skills.

That's the number a careless headline would have inflated by roughly 28×. The honest version is less dramatic and more useful: a sixth of skills touch the environment, and a much smaller sliver — well under one percent — reach for the files where real secrets are kept. If you only have room for one figure when you're deciding what to worry about, 0.6% is the calibrated one.

A note on how we phrase even this, because the overclaim likes to sneak back in as a rider. "Reads environment variables — where your API keys live" reads as neutral context but smuggles the same false implication: this skill reads your secrets. So we state the capability flat and keep the stakes separate. The skill reads environment variables. Whether that matters depends on what's in your environment — which is a fact about you, not about the skill.

The combination, without the overclaim

The number that should get your attention is the 9.8% — the 1 in 10 skills that both read the environment and make outbound network calls. A capability that reads and a capability that sends, present in the same skill, is the shape of data exfiltration.

But read that sentence carefully, because the precision is the integrity. Co-occurrence is the shape of exfiltration, not proof of it. Our compound layer fires when both capabilities are present in the same skill — it does not verify that the data read in one place reaches the network call in another. Two unrelated code blocks — a config reader here, an API client there — trip it exactly the way a real read-then-send pipeline would. It's a strong prioritization signal and a weak proof, and we won't pretend it's the second thing. (We wrote a whole separate post on why we stopped calling this "detecting exfiltration.")

What we can and can't tell you

Which lands on the line this whole tool is built around:

We can't tell you whether a skill will steal your keys. But we can tell you which ones can.

That's not a hedge. It's the actual boundary of what static analysis knows, stated plainly instead of dressed up. Capability exposure is the measurable thing: which skills hold the keys to a door, not which ones walk through it. A sixth of the registry can open the environment. A tenth can open it and reach the network. A small fraction reach for the real secret stores. None of that is a verdict on any single author's intent — it's the map of what's possible, which is exactly the thing you want before you install something, and exactly the thing nobody else is measuring at corpus scale.

Check one

Pick a skill you've installed, or one you're about to. Run it through the live engine and read the capabilities for yourself — the verdict page shows what the extractor found, with the confidence chip that tells you how far each finding actually reaches.

Or browse the registry and open any skill's verdict page directly. The capability is a measurement; the tier is our judgment; and we show you both, labeled as what they are.

Numbers in this post are from ClawAudit's full-registry scan of 19,461 OpenClaw skills. All capability extraction is static and deterministic — no model in the loop. "Environment variables" = process.env reads (any variable); "real secret store" = credential_store (.ssh, .aws/credentials, keychain).