does an openclaw skill need permission to steal ssh keys

No. A default OpenClaw install has no permission left to ask for. Sandboxing is off by default, an unconfigured host runs exec on a full / off baseline — “run host exec without ordinary policy prompts” — and a skill never has to touch ~/.ssh itself. It tells the agent to run curl, and the agent complies.

“skills do not grant permissions” is true and useless

The line people quote is real. OpenClaw’s skills doc says an eligible skill “does not grant tool access,” and that owning a skill library grants no “new tools, credentials, host installation rights, or isolation from the Gateway operator.”

Read it again. It says a skill cannot expand what the agent may already do. It does not say the agent may do little. Your keys live in the gap between those two claims.

The same page, laying out what the skills allowlist actually controls, says it outright: “This is not a host shell authorization boundary. If the same agent can use exec, constrain that shell separately with sandboxing, OS-user isolation, exec deny/allowlists, and per-resource credentials.” Skills were never built as a security boundary, and the docs don’t pretend otherwise.

what are the permissions on a fresh install?

Full access, unless you went and changed it. That’s not my inference — it’s in the docs twice.

Sandboxing, from the sandboxing page: “Sandboxing is off by default.”

Host exec, from exec approvals: “An unconfigured node uses the same full / off baseline as the Gateway.” The permission modes table defines that pair as “run host exec without ordinary policy prompts” — no allowlist match required, no prompt when a command misses the list. The older exec.security field puts it flatter: “Default is full for gateway/node hosts. A sandbox host defaults to deny instead.”

Now the part that earns a jab. The docs carry a section headed “Recommended default,” and the recommended default is auto — allowlist matches run, misses go to a reviewer. You get it by running openclaw config set tools.exec.mode auto. A recommended default you have to type in yourself isn’t a default. It’s a suggestion with good branding.

so how does a skill actually take the keys?

It asks.

Koi Security caught the coordinated campaign on February 1, 2026 and named it ClawHavoc. Antiy CERT later counted at least 1,184 malicious skills across the registry’s whole history, over 12 author IDs, 677 from the account hightower6eu alone. Not one exploited a vulnerability. Antiy sorts the samples by job: talk the agent into fetching and running code, open a reverse shell, or steal files outright.

The theft end is duller than the headlines suggest. One sample dressed as a weather assistant just reads ~/.clawdbot/.env — the file holding your paid Claude and OpenAI keys — and posts it to a webhook. The macOS droppers pull down Atomic Stealer, which Antiy lists as able to take browser passwords, cookies, keychain data, Telegram sessions, shell history, crypto wallets and SSH keys.

Every step there is something you had already told the agent it could do. The markdown is the installer.

One genuinely funny detail sits in the defaults. The file-writing tool, apply_patch, “stays workspace-contained by default even when tools.exec.mode is full.” OpenClaw will stop your agent from editing a file outside the project folder, while the shell beside it reads every private key on the box. The containment is real. It’s aimed at the wrong tool.

is a skill permission manifest coming?

Not yet. The proposal for a skill.yaml manifest — skills declaring up front which paths, commands, endpoints and credentials they need, reviewable before install — has been open since February 9, 2026. A maintainer’s last word on it was “Keep open.” An automated review spelled out the blocker: the project has to settle “its permission authority, consent semantics, enforcement boundary, and compatibility policy” first.

What ships today is a pair of generic hooks, before_install and before_tool_call, plus ClawHub’s scanners — worth about what the numbers suggest. Across the same 67,453 skills, VirusTotal, static heuristic analysis and NVIDIA SkillSpector all flag the same skill just 0.69% of the time, and 81.9% of everything flagged is caught by exactly one of them. Trail of Bits published four working bypasses on June 3, 2026, one of which beat ClawHub by padding 100,000 newlines in front of the payload. Their conclusion: “No amount of scanning or LLM analysis can reliably detect malicious content in agent skills.”

how do i actually lock this down?

In order of what each one buys you:

1. Turn on a sandbox (agents.defaults.sandbox). Exec defaults to deny on a sandbox host, so this is the only control that shrinks the blast radius instead of improving your odds. Mind that tools.elevated is an explicit escape hatch that runs exec outside it.
2. Set tools.exec.mode to auto or ask, then confirm with openclaw exec-policy show instead of assuming the write landed where you meant.
3. Run openclaw skills verify @owner/<slug> before enabling anything from ClawHub. It pulls the skill’s clawhub.skill.verify.v1 trust envelope and exits non-zero when ClawHub marks verification failed. Cheap, and it catches the lazy attacks.
4. Read the skill. The docs ask you to directly: “Treat third-party skills as untrusted code. Read them before enabling.”

Then stop keeping the keys where the agent lives. A skill can’t steal an SSH key from a box that doesn’t have one.

The question assumes there’s a lock to pick. There’s a setting, it ships open, and the docs said so in a sentence nobody reads.