The Credential Problem Behind Agentic AI

On July 16, Hugging Face experienced a security breach, which was the result of an autonomous AI agent system. This malicious agent executed thousands of actions across multiple sandboxes over the span of a weekend. The attack began when the agent harvested cloud and cluster credentials, subsequently moving laterally through internal clusters.

During this incident, Hugging Face's own defensive language model (LLM) was blocked by provider safety guardrails, which were unable to differentiate between a defensive LLM and an attacker. The attacker's agent, on the other hand, was not subject to any usage policies.

The crux of the issue lies in the process of credential harvesting, which is a common point of failure in AI agent systems. Generally, a language model treats an API key as simply a series of tokens, without any inherent privilege or special consideration. As such, keys can be easily exposed through various means such as log lines, commit messages, tool calls, memory files, or even disallowed prompts.

In fact, GitGuardian's State of Secrets Sprawl 2026 report revealed that there was a 34% year-over-year increase in hardcoded secrets in public GitHub commits during 2025, with commits assisted by Claude Code showing an alarming 3.2% secret-leak rate compared to the 1.5% baseline for all public commits.

The problem is exacerbated by the fact that the tools writing our code are today more than twice as likely to hardcode credentials into them. This expands the attack surface through supply chains, with agent skill marketplaces boasting over 40,000 listings within months. Recent research has shown that packed malicious skills can bypass marketplace scanners over 90% of the time.

Snyk's ToxicSkills audit discovered that 10.9% of the skills analyzed on a popular hub contained hardcoded secrets, while OWASP's state-of-agentic-security report maps prompt injection to six out of the ten categories in its agentic Top 10.

When considering the individual operator's setup, there are four key components involved. First, files only hold references to credentials, never the actual values. Every configuration requiring a credential gets a pointer, using 1Password reference URIs to reference vaults and items. The real configuration file is gitignored, with only the template containing pointers.

This approach ensures that leaked repositories leak addresses, not keys. Second, references resolve at process start, with the agent CLI launching under the secret manager. At spawn, references are materialized into environment variables that live in process memory for the duration of the session and are never written to disk. The model sees that a tool works, but it does not see why.

Third, unattended jobs get a scoped identity, authenticating with a service account that can only read one vault, read-only. Personal vaults are structurally unreachable and unread by this identity, and granting an automation a new secret requires human intervention, acting as an approval gate. Lastly, tool servers wrap their own resolution, requiring a three-line wrapper that resolves the reference before executing the real binary. The agent process remains unaware of the credential in any form.

The industry is moving towards a similar architecture, with solutions like 1Password's Credential Broker and Infisical agent-vault acting as trusted intermediaries, ensuring secrets never touch the model's context. Two operating rules emerge from this architecture: any secret that has ever entered the model's context must be rotated, regardless of whether it was pasted "just to test something" three weeks ago, and tokens should always be read-only and least-privilege by default.

However, this does not entirely eliminate the risk of attack. An agent holding a resolved capability can still misuse its capabilities without displaying the secret, and prompt injection can still exploit the agent's legitimate reach.