In one line. A token, an API key, an OAuth grant, a signing identity — every one of them is a bearer credential: whoever holds it can use it, from any machine, anywhere. In 2026 attackers largely stopped breaking in. They hold a valid secret and log in — increasingly with AI writing the malware and an AI running the intrusion. My company EDAMAME does not try to stop the theft. We make the stolen credential insufficient: access is granted to a machine we can vouch for at that instant, not to whoever happens to be holding the secret.

Something broke this year, and most access models have not caught up to it. I want to describe the failure precisely, show you the 2026 incidents that prove it is already here, and then the specific thing my company EDAMAME does about it.

The problem is simple to state. Almost every modern credential — an OAuth access token, a refresh token, a personal access token, an API key, a session cookie, a cloud access key, a CI/CD OIDC token, even a code-signing identity — is a bearer credential. It is proof that an authentication already happened. Whoever presents it gets in. The system on the other end does not ask which machine is holding the secret, whether that machine is the one the credential was issued to, or whether that machine started behaving like a credential stealer thirty seconds ago. As one survey of SaaS attack technique put it plainly, most tokens are bearer tokens, “something like a key. Whoever has this key can use it, regardless of how they obtained it.” That single property is what the entire credential-theft economy runs on — and this year that economy stopped being run by humans.

In 2026, the signature was valid — and it was still malware

For a decade the industry's answer to software trust was cryptography: sign the artifact, attest the build, verify the provenance, show a green “trusted publishing” badge. In the spring of 2026 that answer failed in public, at scale, and it should frighten you more than any leak statistic.

The Shai-Hulud worm waves that tore through npm and PyPI this year forged nothing. They published malware carrying legitimate GitHub Actions signatures, valid Sigstore attestations, and cryptographically valid SLSA Build Level 3 provenance — produced by scraping a live OIDC token out of a CI runner's memory and signing under the project's own trusted identity. As Palo Alto's Unit 42 documented, the certificate was accurate and the packages really were built by that pipeline — it just happened to have malware injected at the time. The attestation was real. The “trusted publishing” badge was green. And the package was a credential stealer.

Sit with that for a moment. Every primitive we built to verify software — the signature, the attestation, the provenance — verifies the key, not the machine that held the key at the moment it signed. A stolen signing identity produces perfect signatures. This is the bearer-credential weakness in its purest and most alarming form: the strongest cryptographic trust we deploy was fully satisfied, and it certified a credential stealer riding more than 170 packages and 200 million downloads a week straight into developer machines and CI pipelines.

AI is the force multiplier — and it widens the blast radius of every stolen secret

The reason the curve bent this hard, this fast, is AI, working every part of the problem at once.

More secrets, in more places. In GitGuardian's latest data, leaked AI-service secrets surged 81% in a single year, eight of the ten fastest-growing leaked secret types are AI services, and the surrounding LLM infrastructure is leaking five times faster than the model providers themselves. Commits co-authored by Claude Code leak secrets at roughly twice the human baseline (3.2% versus 1.5%). Researchers found 24,008 secrets sitting in Model Context Protocol config files alone. And every coding agent — Cursor, Claude Code, Codex, OpenClaw — must hold live credentials to do its job. The population of machines holding usable secrets is now the entire developer fleet, plus every CI runner, plus every agent host.
The malware is now vibe-coded. Generative models write fresh, unique malware per victim, so signature scanners — which look for known files — are blind by construction. Worse: the most damaging supply-chain worm of the year, Mini Shai-Hulud, had its full weaponised toolchain — the CI cache-poisoning scripts, the OIDC token extractor, the self-propagating credential stealer — open-sourced on public GitHub. The barrier to running an autonomous, self-spreading credential-stealing worm is now a prompt and a weekend.
A larger blast radius per token. A human with a stolen token moves at human speed. An agent with shell, repository, cloud and CI access turns one stolen token into lateral movement at machine speed. In the Megalodon wave, a single actor pushed 5,718 malicious commits across 5,561 repositories in under six hours. That is not a human tempo. AI is, in the most literal sense, a blast-radius multiplier on every leaked secret.
AI now runs the intrusion, not just the code. Anthropic has documented the first cyber-espionage campaign executed largely by an AI: Claude Code was manipulated into carrying out 80–90% of tactical operations — reconnaissance, exploitation, lateral movement, credential harvesting, exfiltration — at what its investigators called “physically impossible request rates”, against around thirty targets. The human operator approved strategy. The machine did the breaking in.

AI did not invent the bearer-credential weakness. It took a linear risk, made it compound, and then handed the compounding to a machine that does not sleep.

2026's breaches share one last step

Strip away the tradecraft and the year's headline incidents end identically: a valid credential, used from a machine that should never have had it.

The Shai-Hulud waves (spring 2026). Once a poisoned package lands, a preinstall hook harvests everything on the host — GitHub and npm tokens, AWS, GCP and Azure credentials, Kubernetes service-account tokens, Vault secrets, SSH keys, .env files, even Claude Code configs — exfiltrates it through redundant channels, then reuses the stolen publishing access to infect more packages. It is a credential-theft worm wearing a supply-chain costume.
Red Hat / Miasma (June 2026). At least 32 @redhat-cloud-services npm releases — roughly 80,000 weekly downloads — were poisoned through a single compromised employee GitHub account. The payload, which stamps “Miasma: The Spreading Blight” on the repositories it creates, is the same open-sourced stealer, now in anyone's hands.
Vercel (April 2026). A Lumma infostealer on an administrator at a third-party AI tool lifted OAuth tokens and session cookies. An attacker replayed one OAuth token into Vercel's Google Workspace and reached internal systems and environment variables. A genuine token, replayed from attacker infrastructure.
The device-side view. We have written the same shape up from the endpoint: a compromised workstation still holding valid GitHub credentials reaching about 3,800 internal repositories — an endpoint-trust problem — and the axios, litellm, pgserve and TanStack / Shai-Hulud payloads we caught harvesting credentials at runtime.

Different entry points, different malware, different ecosystems. One identical final move: a valid secret, used from the wrong machine.

Hardening the credential does not change what it is

The standard answer is to make the secret smaller and shorter-lived: fine-grained tokens, short time-to-live, automatic rotation, scoped OIDC, MFA on the human login. All of it is necessary. None of it changes the bearer property. A one-hour token is still a key for one hour, usable from anywhere. MFA protects the login, but the session token minted after MFA is precisely the thing being stolen. And as 2026 proved, even signing and provenance — the strongest cryptography we deploy — only verify the key, never the machine that held it. A leaked secret is not a short-lived mistake either: 64% of credentials confirmed valid in 2022 were still exploitable in January 2026. Rotating faster shortens the window; it does not close the door.

To actually neutralise a stolen credential, you have to attach a condition the thief cannot carry along with the secret: the live trust of the machine making the request.

How EDAMAME makes a stolen token useless

EDAMAME does not replace the identity provider, the repository, or the SaaS application. It supplies the one input none of them has on its own — continuous, live truth about the device — and feeds it into the access controls those systems already expose. The model has two halves.

1. The token is insufficient off an attested device

EDAMAME Security on the workstation and EDAMAME Posture on CI runners and coding-agent hosts continuously measure device posture — reporting-only, user-up, no MDM enrollment, across employees, contractors and BYOD alike. EDAMAME Hub turns that posture into the signal the enforcement point already understands:

Identity-provider Conditional Access (Microsoft Entra, Okta): a non-attested or non-compliant device cannot complete the SSO / OAuth flow, so a token is never usable from it.
GitHub Enterprise IP allow-lists and the IdP Conditional Access IP path: repository access over web, API, Git, personal access token and SSH is bound to trusted egress that Hub keeps current. See Zero Trust for GitHub.
VPN / ZTNA / repository integration: the resource is simply unreachable from a device outside the trusted set.

Replay a stolen OAuth token, API key, personal access token or session cookie from attacker infrastructure — the machine in the Vercel case — and the request arrives from a device EDAMAME never attested. The platform's own access control refuses it. The secret is genuine; the machine is not trusted; access is denied.

2. When a trusted device turns, it loses trust immediately

The harder case is the device that was trusted and then goes bad — the infostealer, the poisoned extension, the supply-chain payload that signed itself with a valid certificate. Here the runtime side does the work. EDAMAME watches host truth: process lineage, files opened, sensitive-path categories, network destinations, posture drift. The moment one process starts reading credential material it has no business touching, or opens exfiltration egress, EDAMAME raises credential_harvest and token_exfiltration findings, the device drops out of the trusted set, and the same enforcement point starts rejecting it — before exfiltration runs its course. This is the engine we have shown catching axios, litellm, pgserve and the TanStack worm on the host, no signature database required.

host behaviour changes → endpoint trust changes → the platform's own access control rejects the next request, even with a perfectly valid, perfectly signed token.

The control has to sit outside the credential

This is the same structural point under every incident above. The credential answers one question: “may this actor access the resource?” It cannot answer the second one: “from this machine, in this state, right now?” That second sentence is where a stolen token dies. The industry has spent years hardening the answer to the first question — smaller tokens, better signing, more provenance — and almost no time on the second, which is exactly why a valid secret in the wrong hands is still the most reliable way into an enterprise.

EDAMAME is built to be the authority for the second sentence:

The identity provider remains the identity authority.
The repository, the SaaS app and the cloud remain the resource authority.
EDAMAME becomes the endpoint-trust authority — the live device signal those controls were always missing.

Where this is going

Follow the trend lines and the destination is clear. Software now writes, reviews and ships itself. Machine identities — service accounts, agent tokens, signing identities — already outnumber humans across most estates, and the gap widens every quarter. The agent running on a developer's laptop holds more live credentials than the developer does. In that world, a bearer credential — a secret that grants access to anyone holding it, with no notion of which machine is holding it or how that machine is behaving at this instant — is simply the wrong primitive. It was designed for slow humans at known desks, and that world is gone.

The next trust model does not ask “do you hold a valid secret?” It asks “is the machine making this request one I can vouch for, in this state, right now?” — and it asks again continuously, because in the AI era a trusted machine can turn hostile between one request and the next. Trust has to move off the credential and onto the live machine and its runtime behaviour. That is the layer my company EDAMAME is building: an endpoint-trust authority for the agentic era, feeding live device truth into the access controls every enterprise already runs. The credential proves that an authentication once happened. EDAMAME proves the machine deserves to use it — right now, and only for as long as it earns it.

A precise claim

I will be exact about what this does and does not do, because over-claiming is its own kind of dishonesty. EDAMAME does not stop a token from being stolen. Infostealers, poisoned extensions, vibe-coded malware and OAuth-integration compromises will keep harvesting secrets, and stolen signing identities will keep producing valid signatures. What EDAMAME changes is what a stolen secret is worth:

Where the enforcement point can see device or network context — IdP Conditional Access, GitHub Enterprise allow-lists, ZTNA — a credential replayed from an unattested device, or from a device EDAMAME has just dropped from the trusted set, is rejected at that point. The theft still succeeds; the use does not.

That is the whole idea. Stop trusting the key. Trust the machine holding it — continuously, and only for as long as it earns it.

Sources

Credential and AI-secret scale: GitGuardian State of Secrets Sprawl 2026 (AI-service leak surge, Claude Code leak rate, MCP config secrets, four-year validity gap).
2026 supply-chain waves: JFrog Shai-Hulud analysis, Unit 42 npm threat landscape (valid SLSA provenance, open-sourced toolchain), CSA Shai-Hulud / Megalodon note, and The Register on the Red Hat / Miasma compromise.
AI-run intrusion and token replay: Anthropic on the first AI-orchestrated espionage campaign, Vercel / Context.ai incident, and the bearer-token framing in this survey of SaaS attack techniques.
EDAMAME prior coverage: GitHub VS Code extension breach, TanStack / Shai-Hulud, pgserve, axios, litellm.

Get started

Download EDAMAME Security — free desktop app for macOS, Windows, Linux, iOS and Android. Four users per tenant on the free plan.
EDAMAME Posture CLI — free CLI for CI/CD pipelines, coding agents and headless servers.
edamame_posture_action — drop-in GitHub Action with self-hosted-runner protection and posture gating.
See the conditional-access side on Zero Trust for GitHub and the coding-agent runtime side on the EDAMAME agents page. For continuous evidence into your compliance platform, see EDAMAME's compliance page.