A paper accepted to ASE 2026 — "How Your Credentials Are Leaked by LLM Agent Skills: An Empirical Study" (Chen et al.) — did something most agent-security discussion doesn't: it measured. The authors sampled 17,022 third-party agent "skills" and looked for credentials leaking out of them. The result is worth sitting with.
The numbers
- 520 skills leaked credentials, across 1,708 distinct issues.
- 89.6% of the leaked credentials were immediately exploitable — and 92.5% of those during routine execution, no privilege escalation needed.
- Secrets removed from 107 upstream repositories persisted across 50+ forks, so "we patched it" didn't actually fix it downstream.
But the single most useful finding is the mechanism.
The dominant cause is boring, and that's the point
73.5% of the leaks came from debug logging.
Not a clever exploit. Not a novel attack. Debug logging. Here's why that's not as dumb as it sounds: in most agent frameworks, a tool's stdout is piped straight into the model's context window — and from there into your traces and logs. So the moment a skill prints something for debugging, and that something happens to include an API key or a token, the secret has been handed to the model and written to your logs. Nobody decided to leak it. The plumbing did.
This reframes how you should think about data hygiene in an agent. We spend most of our attention on what comes in — prompt injection, untrusted documents, poisoned tool descriptions. But a tool's output is a leakage channel too, running in the opposite direction, and it's the one this study found doing the most damage in the wild.
What to actually do about it
Three things, in order of leverage:
- Redact secrets on the tool-output path — before it reaches the context window or the logs. Same discipline you apply to untrusted input, pointed the other way. A secret-shaped string in stdout should be scrubbed before the framework forwards it anywhere.
- Keep credentials capability-scoped and short-lived. The study found 89.6% of leaked secrets immediately exploitable largely because they were broad and long-lived. A read-only, 15-minute token that leaks is a much smaller problem than a standing god-credential that leaks.
- Vet skills — and re-vet them. The fork-persistence finding is a reminder that a skill you approved can change underneath you. Pin it, fingerprint it (a hash of its code/description), and re-check on load.
None of this requires new infrastructure. It requires treating tool output with the same suspicion you already give tool input.
This study is one of the sources behind *BRACE*, an open, vendor-neutral framework for securing autonomous AI agents. Its run-time guide covers exactly this — data hygiene runs both ways, and tool output is a leakage channel. BRACE is built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?
Top comments (0)