Skip to content
Ironheights
GuideIronheights

Where your agent leaks credentials without you noticing

Credential theft is the goal behind most malicious OpenClaw skills in public reports. Infostealers collected keychains, browser passwords, SSH keys and wallets. A fake weather skill posted a bot's .env file to a public request catcher. But a skill does not always have to steal a key. Often the agent has already put it somewhere easy to reach. This post walks through the six places we see keys end up, what each looks like in a skill file, and how to check it.

Why agents are credential magnets

An agent is useful because it can act for you: read your email, push code, call APIs, move money. Every one of those actions needs a credential, and the agent needs to reach it. That makes the agent's workspace the most valuable directory on the machine, and every skill you install runs with the agent's reach.

The reports show what attackers look for. OpenSourceMalware described skills that stole exchange API keys, wallet keys, SSH credentials and browser passwords. Trend Micro described an AMOS stealer variant delivered through skills that collected keychains, browser data, documents and wallet data. Bitdefender described a "sync" skill that searched the workspace for private-key files and sent them to an attacker endpoint.

1. Secrets pasted into chat

The easiest leak is the one you create yourself. A skill asks for an API key "to get started", you paste it into the chat, and now it lives in the conversation transcript. Depending on your setup, it may also be summarized into memory, logged, or sent to a model provider with every later turn.

A skill should tell you to set an environment variable or use a secret store, never to paste a secret into chat. Ironheights flags skills that ask the user for a secret and store it in chat or memory as IH-CRED-003. The fix on your side is a habit: never paste a live key into an agent conversation, and if you already have, rotate it.

2. Agent memory and instruction files

OpenClaw keeps long-lived context in plain files such as MEMORY.md and the memory/ directory, alongside AGENTS.md, SOUL.md and the rest. Anything that ends up there is readable by every skill, every session, from then on. A line like "the deployment token is …" in memory is a key stored in clear text.

The second risk is tampering. A malicious skill can add a standing instruction to memory, such as always sending a copy of something to an outside address. That is persistence without a cron job. Ironheights watches these files by default: ironheights baseline create records them, and ironheights verify reports any change as IH-INT-004, watched agent file changed. Open each reported file and make sure you recognize the change.

3. .env files and the credentials directory

Most agents load keys from a .env file or a credentials directory. That is better than chat, but the file is still on disk in a place the agent can read, and a skill can tell the agent to read it. In the rankaj case from our tracker, a skill posing as a weather tool read the bot's .env file and posted the contents to a public request-catcher service.

Ironheights flags references to sensitive locations as IH-CRED-001: SSH and cloud key paths, .env files, browser stores, keychains, wallet files, shell history, and OpenClaw's own config and auth files. When the same file also makes an outbound request, IH-NET-002, possible exfiltration, fires as well. The credentials/ directory and .env under the OpenClaw state directory are also in the default watch list for verify, so you can see when they change.

4. Keys hard-coded in skill files

Some leaks go the other way: a skill author ships their own key inside the skill. Anyone who installs or reads the skill can copy it, and if the key belongs to you or your team, so can everyone else who sees the repository.

Ironheights flags private-key headers and high-entropy values assigned to key-like names as IH-CRED-002. It masks the evidence, keeping only the first four characters, so the report itself does not spread the secret. If it fires on your own skill, remove the key, rotate it, and load it from the environment.

5. Over-broad access requests

A skill can also ask for far more access than its job needs. JFrog documented a skill called omnicogg that posed as a unified API for Reddit, Steam, Spotify, GitHub, Discord and YouTube and asked for tokens to all of them, while hiding an encoded download-and-run command in a padded README. One skill, six sets of tokens.

No rule can judge whether a request is proportionate; that takes a person. Before you hand over a token, ask whether the skill's stated job needs that service at all, and prefer tokens with the narrowest scope the service offers.

6. Outbound requests you did not expect

The last step of any credential leak is sending it somewhere. In skills that often means a webhook, a request-catcher service, a messaging bot API, or a raw IP address. A skill should name every host it talks to, and each host should fit its purpose.

Ironheights flags hosts outside its allowlist as IH-NET-001. The built-in allowlist includes the reserved example domains, localhost, GitHub, npm, PyPI and openclaw.ai, and you can add your own with allowDomains. A webhook to an unexplained host is the clearest exfiltration signal there is.

A ten-minute credential audit

You can check your own setup today:

  1. Search your agent's transcripts and memory files for key-like strings and remove any you find. Rotate those keys.
  2. List what is in .env and credentials/. Remove anything the agent does not need right now.
  3. Scan every installed skill with npx ironheights scan --all, which walks the configured skill directories or the default OpenClaw locations, and read every credential and network finding.
  4. Create a baseline with npx ironheights baseline create, then run npx ironheights verify after each new skill or update.
  5. Split agents by risk. An agent that tries new skills should not hold production keys or a funded wallet.

The browser scanner runs the same content rules on a pasted SKILL.md if you want to check one skill without installing anything, and the skill safety checklist includes the credential questions.

What Ironheights does not do here

Ironheights finds references to credential locations and secrets in files, and changes to watched files. It does not watch processes or network traffic, so a key read and sent by a downloaded script at runtime is outside what it sees. It cannot tell a legitimate .env read from a malicious one; it flags the pattern and leaves the judgment to you, which means some findings will be false positives. A credential broker that keeps keys out of the agent's reach is on our roadmap, not in version 0.1.5. The limitations page has the full list, and the benchmark shows how our credential rules behaved on our synthetic test corpus and why that is not a real-world rate.

FAQ

How do malicious OpenClaw skills steal API keys?

The reported methods are reading key files such as .env, SSH keys or wallets and sending them to an outside host, asking the user to paste keys into chat, and installing an infostealer through a fake setup step that then collects browser passwords and keychains.

Is it safe to give an OpenClaw agent my API keys?

Every key you give an agent can be reached by the skills it runs. Give it only the keys a task needs, with the narrowest scope available, keep them out of chat and memory, and rotate any key that a suspicious skill could have read.

Sources

Scan the next skill before your agent reads it

Ironheights is a free, open-source, local-first scanner and integrity monitor for OpenClaw skills. The CLI has no telemetry, and a scan makes no network calls. It reports what its rules match; it cannot prove a skill is safe.

Get Ironheights