Skip to main content
In 2025, 18.1 million API keys were stolen. 29 million new secrets were committed to GitHub — a 34% year-over-year increase. The average time from initial access to lateral movement dropped to 29 minutes. The fastest recorded breach went from zero to full exfiltration in 4 minutes. These are not hypothetical risks. These are the numbers from production. And now agents — autonomous software that reads files, calls APIs, sends emails, and spends money — are using those same leaked keys with no identity, no scoping, and no revocation mechanism. Here are four incidents from the past 12 months that make the case for why agent authorization is no longer optional.

​
1. Shai-Hulud — 500+ npm Packages, 2.6 Billion Weekly Downloads

In mid-2025, security researchers identified a supply chain worm — codenamed Shai-Hulud — that had silently compromised over 500 npm packages with a combined 2.6 billion weekly downloads. The payload was subtle: it harvested every cloud credential accessible from CI/CD runners and exfiltrated them to attacker-controlled endpoints. CISA issued a formal alert. The blast radius was enormous because CI pipelines routinely inject long-lived secrets as environment variables — AWS keys, GCP service account tokens, database credentials. Every compromised package had access to all of them. Why this matters for agents: AI agents running in CI/CD (code review bots, deployment agents, test orchestrators) inherit the same environment. If the agent’s framework pulls in a compromised dependency, every secret the agent can see is compromised. With Grantex, the agent would hold a scoped, time-limited JWT — not raw cloud credentials. Compromising the token gives the attacker access to calendar:read for 1 hour, not root on your AWS account forever.

​
2. SANDWORM_MODE — 19 Malicious npm Packages Targeting AI IDEs

In February 2026, researchers discovered 19 npm packages designed to install rogue MCP (Model Context Protocol) servers inside Claude Code, Cursor, and Windsurf. The packages masqueraded as popular utilities and, once installed, silently registered themselves as MCP tool providers. The rogue servers targeted API keys from 9 LLM providers — OpenAI, Anthropic, Cohere, Mistral, and others. Because MCP servers have broad access to the IDE’s tool-calling context, the malicious servers could intercept and exfiltrate keys as they were used in API calls. Why this matters for agents: MCP is the emerging standard for giving agents access to tools. But MCP has no native authentication layer. Any server can register itself, and agents trust whatever tools are available. Grantex’s MCP Auth Server adds OAuth 2.1 + PKCE to any MCP server — meaning even if a rogue server registers, it cannot obtain a valid grant token without the human explicitly approving the scope in the consent flow.

​
3. OpenClaw — 21,639 Exposed Instances Leaking OAuth Tokens

A February 2026 Censys scan revealed 21,639 publicly accessible instances of a popular open-source automation tool leaking OAuth tokens and plaintext credentials to anyone who could reach the endpoint. No authentication was required — the instances were deployed with default configurations that exposed their internal token stores. The leaked tokens included OAuth refresh tokens for Google Workspace, Microsoft 365, Slack, and GitHub — many with broad scopes and no expiry. Why this matters for agents: Agents that automate workflows across SaaS tools accumulate tokens — often stored in plaintext or weakly encrypted databases. A single misconfigured deployment leaks every integration. Grantex’s Credential Vault solves this by letting agents exchange their grant token for upstream credentials at runtime. The master keys never leave the vault. If the agent’s deployment is compromised, the attacker gets a scoped, time-limited Grantex JWT — not the raw SaaS tokens.

​
4. CVE-2026-21852 — Opening a Repo Exfiltrates Your API Key

This one is the most chilling because it required zero user interaction beyond opening a repository. CVE-2026-21852 demonstrated that simply opening a crafted Git repository in Claude Code was enough to exfiltrate the developer’s active Anthropic API key. The attack exploited the fact that the IDE’s agent runtime had ambient access to the API key — it was loaded into the environment for legitimate use and was accessible to any code the agent executed, including code from the opened repository. Why this matters for agents: The root cause is ambient credentials. The API key exists as an environment variable or config file, and everything running in that context can read it. Grantex eliminates ambient credentials entirely. The agent authenticates via a grant flow and receives a JWT scoped to exactly the permissions it needs. No environment variable to steal. No master key to exfiltrate. And if the token is somehow compromised, one POST /v1/tokens/revoke call invalidates it — and every delegated sub-token — instantly.

​
The Common Thread

All four incidents share a root cause: shared, long-lived, unscoped secrets used as identity.
IncidentRoot CauseGrantex Mitigation
Shai-HuludCI injects raw cloud creds as env varsAgent holds scoped JWT, not raw keys
SANDWORM_MODEMCP servers have no auth layerMCP Auth Server adds OAuth 2.1 + PKCE
OpenClawOAuth tokens stored in plaintextCredential Vault — master keys never leave
CVE-2026-21852Ambient API key in agent runtimeNo ambient creds — grant flow only
The fix is not better secret scanning. The fix is not rotating keys faster. The fix is not using shared secrets as agent identity in the first place. Agents need their own authorization protocol — one where every agent has a cryptographic identity, every action is scoped and consented to by a human, and every token can be revoked in real time. That is what Grantex is.

​
Get Started