Agent skills are being treated like extensions. They behave more like dependencies with access to secrets.
That difference is now measurable. A new empirical study of LLM agent skills found credential leakage across public skill packages at enough scale to make the market look less like a convenience layer and more like a secrets-management problem.
The paper analyzed 17,022 skills sampled from the SkillsMP marketplace and found 520 vulnerable skills with 1,708 leakage issues. The important part is not just the count. It is the failure mode. The researchers found that leakage is often cross-modal: 76.3% of cases required joint analysis of code and natural-language descriptions, while only 3.1% came purely from prompt injection. Debug logging was the primary vector, with print and console.log causing 73.5% of leaks by exposing stdout back to LLMs. The leaked credentials were also practical, not theoretical: 89.6% were exploitable without privileges, and forks could keep secrets after upstream fixes, according to the April 2026 study.
That is the agent-economy version of a supply-chain warning light.
Skills Are Not Just Prompts
The security mistake is treating agent skills as harmless instruction bundles.
Some are just text. Many are not. Skills package reusable capabilities through instructions, scripts, tool calls, environment assumptions and procedural logic. They tell an agent when to activate, what to do, which APIs to call and how to format outputs. That makes them operational.
Once a skill handles credentials, it becomes part of the trusted path.
The problem is that the trusted path is unusually fuzzy. In normal software, secret leakage is often visible in code: a hardcoded key, a config file, a log line, a committed token. In agent skills, leakage can sit between code and language. A natural-language instruction can cause the model to expose something a code scanner misses. A debug print can send a key to stdout, which the LLM then sees as context. A benign-looking skill description can create a risky behavior pattern when paired with executable code.
This is why the study’s cross-modal finding matters. If 76.3% of leakage cases require joint code-and-language analysis, then conventional secret scanners are structurally incomplete. They can catch strings. They do not understand the agent’s execution story.
The attack surface is the package plus the model’s interpretation.
Debug Logs Are An Agent Leak Path
Debug logging is not new. Developers have been printing things they should not print since the first person said “temporary.”
Agent skills make that habit worse because stdout can become model-visible context. If a skill prints an API response, environment variable, token or credential during execution, the LLM may see it and reason over it. A secret that would once have been a bad log entry becomes part of an interactive agent session.
That is why the 73.5% debug-logging figure is useful. It points to a boring fix path.
Do not let skills print secrets. Do not expose raw stdout to the model without filtering. Do not assume developers will remember to remove diagnostics before packaging. Do not allow marketplace submissions that can read broad environment variables and write them into agent-visible channels. Boring rules, useful rules.
The lesson is that agent runtimes need output hygiene. A skill’s output is not just user-facing text. It is input to the next reasoning step. Treating it as a clean channel is lazy.
Forks Make Cleanup Harder
The persistence finding is where this stops being a one-time scanning problem.
If vulnerable skills are forked, a secret can survive after the original maintainer fixes the upstream package. That is normal software supply-chain behavior. Agent ecosystems inherit it. The difference is that many teams still treat skills as lightweight productivity assets instead of governed dependencies.
Once a skill leaks a credential, remediation needs to include rotation, fork discovery, marketplace takedown where possible, dependency replacement and runtime control changes. Removing the original secret from the original skill is not enough. The copies are the problem.
This is ugly for organizations adopting public skill marketplaces.
Developers may install a skill because it solves a narrow workflow. The skill may depend on a fork. The fork may contain stale credentials. The agent may execute it inside a workspace with access to fresh internal secrets. A small convenience package becomes a bridge between someone else’s hygiene and your environment.
That is not an extension market. That is dependency risk with friendlier packaging.
Prompt Injection Is Not The Whole Story
Security teams should care about prompt injection. They are wrong if they stop there.
The study found only 3.1% of leakage cases arose purely from prompt injection. That does not make prompt injection irrelevant. It makes the broader point sharper: most of the leakage was not just a clever instruction in text. It came from the interaction between code, natural language, logging, runtime behavior and credential handling.
This is why agent-skill governance needs to look more like software supply-chain management than chatbot policy.
Approve skills. Pin versions. Scan code and natural-language instructions together. Strip stdout. Scope secrets. Use short-lived credentials. Prevent skills from reading broad environment variables by default. Run untrusted skills in sandboxes. Track forks. Rotate credentials after exposure. Log skill execution paths. Treat marketplace reputation as weak signal, not proof.
None of this is exotic. It is standard dependency discipline adjusted for agents.
The difference is the model in the middle. The model can read instructions, observe outputs and decide the next action. That makes leakage more dynamic than a static key in a repository.
The Marketplace Problem
Skill marketplaces create a scaling problem.
A single organization can review a handful of internal skills. A public marketplace with thousands of reusable skills creates a different risk shape. The value proposition is reuse. The risk is also reuse.
If a vulnerable skill is popular, leakage propagates. If a fork keeps a stale secret, the problem persists. If the marketplace relies on weak scanning, users inherit assumptions they cannot verify.
This is where the control burden should shift.
Marketplace operators need submission checks that understand code and natural-language behavior. Runtime platforms need secret filtering and permission scoping. Enterprises need allowlists and internal mirrors for approved skills.
The Implication
Agent skills are moving AI assistants closer to real work. That means they are moving closer to real secrets.
The lesson from the April study is not that skill marketplaces are doomed. It is that they need the same discipline software ecosystems learned painfully: dependency review, secret scanning, version pinning, least privilege, provenance and sandboxing.
The agent-specific addition is cross-modal review. A skill is not secure because the code scans clean. The natural-language instructions matter. The stdout behavior matters. The runtime context matters. The model’s view of all three matters.
For enterprises, the policy should be blunt: no public agent skill gets access to production credentials without review, scoping and runtime controls. Treat the agent like an untrusted operator. Give it what it needs. Do not hand it the keyring.
Skills make agents useful. They also make secrets movable. That is not a reason to stop using them. It is a reason to govern them like they can leak what they can touch.
Discussion
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.