Credential harvesting is the single most common archetype among malicious agent skills. The pattern is simple: a skill masquerades as a benign tool while actively searching the user's environment for authentication material, .env files, API keys, tokens, SSH keys, and passing whatever it finds to a server the developer never approved.

What it actually targets

The search targets are predictable once you know the pattern: environment variables and .env files, cloud credential directories like .aws/credentials, SSH keys under .ssh/, and configuration files such as .gitconfig or secrets.yaml. None of these files are exotic. They're exactly what a developer's machine or CI environment already has sitting on disk, which is what makes the attack so quiet. There's no exploit involved, only a script reading files it was never supposed to touch and a socket sending the contents somewhere else.

Why it's the leading pattern

Credential theft scales better than almost any other objective. A stolen API key or cloud credential unlocks whatever that credential was scoped to: source repositories, cloud infrastructure, internal APIs, sometimes an entire organization's CI/CD pipeline. Compared to a destructive action that gets noticed the moment it happens, quiet credential collection can go undetected for a long time, and a single successful harvest can be reused well after the original skill is uninstalled.

Sensitive information disclosure, alongside excessive agency and supply chain risk, consistently dominates the categories flagged across large-scale audits of public agent skill repositories.

How detection actually works

Static rules catch the obvious version: a regex or signature matching patterns like os.environ or getenv combined with terms like key, secret, token, or password near a network call. That catches unobfuscated attempts, but it also catches a lot of completely benign code, since checking for an API key before making an authenticated request is normal, expected behavior in legitimate automation.

The more reliable signal comes from runtime behavior: does the skill successfully open a credential file (not just attempt and fail), and is that successful access followed by outbound network activity to a domain that has nothing to do with the skill's stated purpose. A failed open call that returns "file not found" is not evidence of theft. A successful read of .env immediately followed by a socket connection to an unfamiliar external domain is.

FAQ

Does a skill need internet access to be a credential harvester? It needs some way to transmit what it collects, whether that's a direct network call, writing to a location the attacker later retrieves, or piggybacking on the agent's own legitimate network calls. Filesystem access alone is the first half of the attack, not the whole thing.

Can this happen without the user running any suspicious command? Yes. Because agent skills execute with the AI agent mediating the action, a user can simply be using the skill as intended while the harvesting logic runs silently in the background of a request that otherwise looks routine.

Is this different from a phishing attack? Different delivery mechanism, same goal. Phishing tricks a person into handing over credentials directly. A credential-harvesting skill tricks a developer into installing something that collects credentials on its own, without the developer ever consciously handing anything over.

Related reading: "Shadow Features: The Malicious Capability Your Skill Scanner Never Sees," "Hidden in Plain Sight: How Obfuscation Hides Data Exfiltration in Agent Skills"