How Infostealers Steal Developer and AI Agent Tokens, and How to Stop It

Infostealers steal developer and AI agent tokens by reading the files, keychains and browser stores where those tokens already sit: session cookies, ~/.npmrc, GitHub CLI and cloud CLI caches, and the login and MCP files that coding agents keep. Protect them by making tokens short-lived, bound to a device or a workflow, and quick to revoke.

A stealer does not crack anything. It copies what is already there, sends it out in seconds, and the attacker replays it from somewhere else. Your defence is to make whatever it copies worth as little as possible, for as short a time as possible, and to notice when it is used from the wrong place.

This guide covers what a modern stealer grabs from a developer machine, how a stolen publish token becomes a supply chain attack within hours, which tokens you can make short-lived or device bound, how trusted publishing and OIDC remove long-lived publish tokens, what session theft means for MFA, how to spot token use from an unexpected place, and what to do in the first hour after a laptop is infected.

Key takeaways

• Stealers copy, they do not crack. Anything a developer tool can read on disk or in a user keychain, malware running as that user can usually read too.
• AI agents are a new target. Gen Digital reported in September 2026 that several stealer families now collect coding agent tokens, MCP configuration credentials and prompt histories.
• A stolen publish token is a supply chain incident. The Shai-Hulud npm worms used stolen tokens to publish poisoned versions of other packages the victim maintained.
• MFA does not protect a session that already exists. A stolen cookie or refresh token skips the login step.
• Remove long-lived tokens first. Trusted publishing, GitHub Actions OIDC and cloud single sign-on replace stored keys with credentials that last minutes or one job.
• Bind and limit what you cannot remove, and plan the first hour: rotate from a clean machine and revoke sessions as well as tokens.

Why this question is everywhere in October 2026

In September, Gen Digital's threat research team published a study showing commodity stealers adding collection rules for AI coding agents. In short, stealers have a new target: your AI agent. Singapore's Cyber Security Agency kept updating advisory AD-2026-009 on a new npm worm in the Shai-Hulud family. And on 21 October, a compromised LiteLLM release showed how developer tokens captured in one place can become a poisoned release somewhere else; LiteLLM's incident report is the primary account.

None of this is new in kind. What changed is how many high value tokens one developer laptop now holds, and how fast an attacker can turn one into a release that thousands of machines install automatically.

What does a modern infostealer grab from a developer machine?

An infostealer is malware built to collect credentials and session material and send them to its operator. Most arrive through fake installers, cracked software, malicious browser extensions, lures that trick a user into pasting a command, or a malicious package that runs code at install time. Once running as the logged in user, it works through a list of known locations. On a developer machine that list is long.

Browser cookies and saved passwords

Session cookies for your identity provider, code host, cloud console, package registry and chat tools let an attacker load those sites as you, without a password or second factor. MITRE ATT&CK tracks this as Steal Web Session Cookie (T1539) and lists well known stealer families among the software that does it. Saved passwords, autofill data and extension storage usually go in the same pass.

Package registry and source control tokens

These are the tokens that turn one infected laptop into a supply chain problem:

• ~/.npmrc and ~/.pypirc can hold registry tokens in plain text, as can a project level .npmrc left in a working directory.
• The GitHub CLI stores its token in the system credential store by default, but its manual says it falls back to a plain text file when no credential store is available, and that --insecure-storage forces plain text. gh auth status shows where yours lives.
• ~/.git-credentials if anyone used the store helper, and SSH private keys without a passphrase.
• Container registry logins in ~/.docker/config.json when no credential helper is configured.

Cloud, cluster and infrastructure credentials

Long-term AWS keys in ~/.aws/credentials, cached single sign-on tokens under ~/.aws/sso/cache, other cloud CLI token caches, ~/.kube/config files with embedded tokens, and Terraform credentials. CSA's advisory lists cloud credentials, GitHub tokens, SSH keys, Kubernetes configurations and Terraform credentials among the things to rotate after exposure, which is a fair map of what these tools collect.

Environment files and shell history

.env files across old checkouts, shell history holding a token pasted into a curl command, and environment variables of running processes. A developer laptop often has dozens of forgotten .env files, each with a database URL or API key.

AI coding agent logins, MCP configs and prompt histories

Coding agents need credentials of their own, and often hold credentials for other services too.

• Agent logins. Anthropic's documentation says Claude Code stores credentials in the encrypted macOS Keychain on macOS, and in ~/.claude/.credentials.json with file mode 0600 on Linux; on Windows they sit in %USERPROFILE%\.claude\.credentials.json. On macOS it falls back to that file when the Keychain rejects the write, for example when it is locked in an SSH session. OpenAI's documentation says Codex caches login details in ~/.codex/auth.json or the OS credential store, and tells users to "treat ~/.codex/auth.json like a password."
• MCP configuration. Server definitions often carry API keys, headers or environment variables inline. A DEV Community piece on agents and secrets notes these files frequently hold connection strings and keys in plaintext, next to .env files that stealers already collect.
• Prompt histories. Developers paste logs, config snippets and sometimes secrets into agent sessions. Gen Digital says stealers now take prompt histories, conversation databases and project traces, which can contain proprietary code, internal hostnames and pasted secrets.

Gen Digital names specific families. By its account, Amatera targets data associated with Cline and Continue; Remus targets Claude, Cursor and OpenCode; CallbackBeaver targets Cursor and Claude, with more than 5,000 samples in a recent 30 day period; and a macOS stealer called Djinn targets Claude, Codex, Gemini, Cline, OpenCode and Kilo. The report does not publish file paths and notes that locations vary by product, operating system and settings.

Why "it is in the keychain" is only a partial answer

Moving a token from a plain text file into the OS credential store is worth doing. It stops casual file grabs and keeps tokens out of backups and dotfile repositories. It does not stop malware that runs as the same user and asks the credential store, or that waits for the legitimate tool to use the token. Treat keychain storage as raising the cost, not as a wall. The bigger wins come from short lifetimes and binding tokens to a device or workflow.

How do stolen tokens turn into supply chain attacks within hours?

Registries and CI systems trust tokens, not people. That makes the path from an infected laptop to thousands of compromised installs short.

The worm pattern

CISA's September 2025 alert on the original Shai-Hulud worm describes the loop. The malware scanned for credentials including GitHub personal access tokens and AWS, Google Cloud and Azure keys, sent them to an attacker endpoint, uploaded them to a public GitHub repository named Shai-Hulud, then authenticated to npm as the developer, injected code into other packages that developer maintained and published new versions. CISA counted more than 500 compromised packages in that wave.

The pattern continues. CSA's advisory AD-2026-009, first issued on 6 August 2026 and still being updated on 22 October, covers a variant it calls ChainDrop, with more than 1,300 compromised npm package versions and about 2 billion combined monthly downloads. It tells defenders to watch for GitHub repositories whose description contains "Shai-Hulud: Here We Go Again." Our Shai-Hulud explainer covers the mechanics.

Every step runs on a stolen token:

1. Malware runs on a maintainer's laptop or CI job, often because they installed an already infected package.
2. It reads the npm and GitHub tokens that machine holds.
3. It publishes a new patch version of every package the token can write to, with the payload added.
4. Every project that accepts new patch versions installs the payload on its next fresh install, and the cycle repeats.

Steps 2 to 4 can take minutes. A publish token reaches every downstream user at once, which makes it the most valuable credential on most developer machines.

The pipeline pattern

The LiteLLM incident shows another route to the same outcome. According to LiteLLM's report, developers' GitHub CLI OAuth tokens had ended up in request and response logs on an internal deployment, because coding agent traffic passing through the proxy contained them. That deployment was reachable from the internet. The attacker used three developers' GitHub CLI credentials; one belonged to an organization owner and was used to disable branch protections and force push. The attacker then ran the official release workflow against a lookalike repository, which signed and published the poisoned artifacts. LiteLLM's timeline has litellm==1.107.0 on PyPI from 11:39:51 to 13:23 UTC.

Two lessons carry over. A token can leak without any malware on the laptop, simply by being logged somewhere. And a release pipeline that signs whatever it is asked to build will sign an attacker's build too. Provenance tells you which workflow built an artifact, not whether the person who triggered it should have been able to, a gap we covered in the tensorlake npm compromise.

The account pattern

The quieter route skips publishing. A stolen cloud console or SSO session gives an attacker the developer's view of code, CI secrets and production. A stolen agent token lets them spend your organization's quota and use connectors the account has authorized. OWASP's Non-Human Identities Top 10 lists Secret Leakage (NHI2), Long-Lived Secrets (NHI7) and Human Use of NHI (NHI10) for this reason: tool and machine identities are where long-lived credentials collect.

Which tokens can be short-lived or bound to a device, and which cannot?

The honest answer is a sorting exercise.

Anything that runs in CI can almost always move to workload identity, because the CI platform can prove which workflow is running. Anything a human uses interactively is harder, because the token has to survive on a laptop between uses. There, the levers are shorter lifetimes, device binding where supported, narrow scopes and fast revocation.

Device Bound Session Credentials

The biggest change for browser sessions is Device Bound Session Credentials (DBSC). Chrome's documentation explains that at login Chrome creates a key pair and keeps the private key in secure hardware such as a TPM where available. The site issues short-lived cookies, and before each refresh Chrome must prove it holds the private key. A cookie copied to another machine expires quickly and cannot be refreshed there.

Google announced on 28 May 2026 that DBSC is generally available in Chrome on Windows, enabled by default for Google Workspace users and available for personal Google accounts. Two caveats from the documentation: malware present when the session is registered may be able to extract or misuse the key, and devices without secure hardware fall back to ordinary cookies. DBSC also protects only sites that implement it, so it helps your Google sign-in today but not necessarily your registry or cloud console.

Agent tokens specifically

Coding agent tokens sit in the hard category. The practical controls:

• Keychain storage. For Codex, the cli_auth_credentials_store setting accepts keyring (fail rather than fall back to a file), auto or ephemeral (in memory for the process only), per OpenAI's docs.
• Organization restricted logins. Claude Code's forceLoginMethod and forceLoginOrgUUID managed settings stop personal accounts on work machines and make it obvious which account to revoke.
• Runtime credentials. Claude Code's apiKeyHelper runs a script that returns a key, which Anthropic suggests for rotating credentials such as short-lived tokens from a vault.
• An inventory of long-lived ones. claude setup-token prints a one year OAuth token for CI without saving it. Record where each one goes and rotate it on a schedule.

How do trusted publishing and OIDC remove long-lived publish tokens?

Trusted publishing replaces "a stored token that can publish forever" with "a credential the registry mints for one workflow run, after checking who is asking." The CI platform issues a signed OpenID Connect token stating which repository, workflow and ref is running. The registry checks it against the publisher you configured and, if it matches, issues a short-lived credential for that publish.

npm

npm's trusted publishing documentation requires npm CLI 11.5.1 or later and Node 22.14.0 or later, on GitHub-hosted runners, GitLab.com shared runners or CircleCI cloud. Self-hosted runners are not supported. Provenance is generated automatically for public packages from public repositories on GitHub Actions and GitLab.

name: Publish package
on:
  push:
    tags:
      - 'v*'
permissions:
  id-token: write
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    environment: release
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm publish

Then close the door. npm recommends that once trusted publishing works, you select "Require two-factor authentication and disallow tokens" in the package's publishing access settings, which blocks token based publishing while OIDC keeps working. For the strictest setup, give the trusted publisher stage-only permission so each CI publish waits for a maintainer's 2FA approval. Then revoke the old automation tokens. Note that a new trusted publisher must complete its first publish within two days or it expires, and that installs of private dependencies still need a read-only granular token.

npm has also been removing older token types. Its access token documentation says legacy tokens have been removed and only granular tokens are supported since November 2025. Granular tokens can carry an expiry, a package and scope list, read-only access and an IP allowlist in CIDR notation. From August 2026, tokens that bypass 2FA can no longer perform account identity or governance actions, and direct publishing with them is slated for removal in January 2027.

PyPI

PyPI's trusted publishers documentation describes the same exchange, returning a project scoped API token that expires 15 minutes after creation. A stolen copy is useless almost immediately, and there is no stored upload token in CI for a stealer or malicious dependency to read.

Cloud credentials in CI

GitHub's OIDC documentation explains that instead of storing long-lived cloud credentials as secrets, a workflow requests a short-lived token valid for a single job, and the cloud role's trust policy checks claims such as sub, aud, repository, ref and environment. Repositories created after 15 July 2026 use an immutable default sub format that includes owner and repository IDs, so older trust conditions may need updating.

permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-production
          aws-region: us-east-1
      - run: aws sts get-caller-identity

Pin the trust condition to the most specific claim you can, such as a protected production environment. A policy that trusts any workflow in your organization turns OIDC back into a shared secret.

What trusted publishing does not fix

It removes the stored token. It does not stop an attacker who can push to your release branch or trigger your release workflow, as the LiteLLM case shows. Pair it with branch protection that also binds administrators, required reviews on workflow changes, a protected release environment with required reviewers, and alerts when any of those settings change.

What does session-token theft mean for MFA?

MFA protects the front door and nothing after it. It runs when you sign in. After that, the service hands your browser a session cookie, or your CLI an OAuth access and refresh token, and those prove who you are for every later request. If malware copies them, the attacker presents them directly and never sees an MFA prompt. MITRE's T1539 entry notes that session cookies can be used to bypass some multi-factor authentication protocols.

So the answer is not more MFA but different controls:

• Phishing-resistant MFA still matters, because it stops real-time phishing proxies that capture the cookie as you log in. It does not stop a stealer on the endpoint.
• Device binding, such as DBSC for browser sessions and hardware backed keys for SSH and signing, makes a copied session fail elsewhere.
• Step-up authentication for sensitive actions: creating tokens, changing branch protection, adding deploy keys, changing publishing settings.
• Conditional access that limits sessions to managed devices.
• Revocation that revokes. Changing a password does not always end existing sessions; sign out all sessions explicitly.

Our post on Okta, infostealers and session replay covers the identity provider side. This post stays with developer and agent tokens outside it.

How do you detect token use from an unexpected place?

You cannot see a stealer reading a file. You can see the stolen token being used.

GitHub: trace a specific token

GitHub's audit log documentation says to compute the base64 encoded SHA-256 hash of a token and search with hashed_token:"VALUE". It works for personal access tokens, OAuth tokens, GitHub App tokens, deploy keys and SSH keys; Git events need an audit log export.

# Read the token without echoing it or saving it to shell history
read -rs TOKEN
printf '%s' "$TOKEN" | openssl dgst -sha256 -binary | base64
unset TOKEN

Look for activity from unfamiliar IP addresses, user agents or hours, and for events attackers favor: branch protection changes, new deploy keys, new OAuth authorizations, new repositories, workflow edits and new self-hosted runners.

npm: watch your own packages

npm view your-package time --json
npm token list

The first shows every published version with a timestamp, so you can spot one nobody released. The second lists tokens on the account with creation dates. If you publish only through trusted publishing with tokens disallowed, a token based publish should fail outright.

Cloud: watch the first call attackers make

LiteLLM's guidance suggests checking CloudTrail for GetCallerIdentity calls from the affected role around install time, and for use of the role's credentials from outside your infrastructure. Attackers with a fresh credential usually ask "who am I?" first. Alert on that call from IP ranges you do not own, and on CI role credentials used outside your CI provider's ranges.

AI providers

Watch usage and billing for the AI providers your teams use. Spikes, new regions or activity at odd hours are often the first sign that an agent token or API key is being replayed.

Set up the signal in advance

• Restrict npm granular tokens to your office or VPN CIDR ranges.
• Use GitHub's organization token policy to restrict classic tokens, require approval for fine-grained tokens and set a maximum lifetime. By default, fine-grained tokens can live up to 366 days and classic tokens have no expiry requirement.
• Give each tool its own token, so you can tell which one leaked.

What is the first-hour response when a developer laptop is infected?

The goal is to make stolen material useless, without provoking more damage, and to learn what the attacker can already reach.

Minutes 0 to 10: contain the machine

1. Isolate the laptop from the network. Avoid shutting it down if responders may want memory evidence.
2. Do not log in to anything from it again, including to rotate credentials. Every new token created there goes to the attacker.
3. If the malware is a known worm, follow its advisory before revoking. Some recent npm worms have been reported to react to revocation; our tensorlake write-up describes advisories warning that revoking a GitHub token while the persistence service ran could trigger a wipe of the home directory.
4. Estimate the infection time. It sets the window for every log search.

Minutes 10 to 40: revoke and rotate from a clean machine

Work from a known good device, in order of blast radius:

1. Publish and signing credentials. npm tokens (npm token list, then npm token revoke for each), PyPI tokens, registry credentials, signing keys.
2. Source control. Revoke personal access tokens, OAuth and GitHub App authorizations (including the GitHub CLI), SSH keys, and all sessions.
3. Cloud. Deactivate long-term keys, revoke active role sessions and end single sign-on sessions centrally. Logging out on the laptop does nothing about a copy.
4. Identity provider. Revoke all sessions and refresh tokens, and re-enroll MFA if recovery codes may have been seen.
5. AI agents. Revoke or remove the user's agent access through your organization's account administration, rotate API keys in MCP configs and .env files, and rotate any one year setup-token credentials.
6. Everything in .env files and shell history. Assume every secret that lived on that machine is exposed.

Minutes 40 to 60: look for use and scope the damage

1. Search audit logs for each revoked token's activity since the infection time.
2. Check every package the developer can publish for versions you did not release. Deprecate, ask the registry to remove, and publish a clean version.
3. Check repositories they could write to for new or changed workflows, deploy keys and disabled branch protection.
4. Check prompt histories on the laptop for pasted secrets and rotate those too.
5. Tell downstream users if a malicious version reached them; our compromised dependency playbook covers that.

Then reimage the laptop. Cleaning a stealer by hand is rarely worth the risk.

A step by step hardening walkthrough

Run these in order. Each one shrinks the blast radius of the next infection.

Step 1: Inventory what a laptop holds

Have each developer run a check that lists locations, not secret values:

# Files that commonly hold tokens (existence and permissions only)
ls -la ~/.npmrc ~/.pypirc ~/.git-credentials ~/.docker/config.json \
  ~/.aws/credentials ~/.kube/config ~/.codex/auth.json \
  ~/.claude/.credentials.json 2>/dev/null

# Where the GitHub CLI keeps its token
gh auth status

# Long-term AWS keys in the shared credentials file
grep -c aws_access_key_id ~/.aws/credentials 2>/dev/null

# Forgotten .env files in old checkouts
find ~/code ~/src -name '.env*' -not -path '*/node_modules/*' 2>/dev/null | head -50

Record each long-lived credential, its owner, what it reaches and when it expires. That is your rotation plan for the next infection.

Step 2: Move tokens out of plain text files

• GitHub CLI: if gh auth status reports a plain text location, log out and log in again on a machine with a working credential store.
• Docker: set credsStore in ~/.docker/config.json so registry logins go to the OS keychain.
• Git: use the OS credential manager helper and delete ~/.git-credentials.
• Codex: switch to the keyring.

# ~/.codex/config.toml
cli_auth_credentials_store = "keyring"

Step 3: Replace publish tokens with trusted publishing

For every npm and PyPI package, configure trusted publishing, confirm one release, disallow token publishing, and revoke old automation tokens. On npm, consider stage-only permission so a human approves each release.

Step 4: Replace cloud keys with workload identity and SSO

Use OIDC role assumption in CI. On laptops, follow AWS's IAM Identity Center CLI guide:

aws configure sso
aws sso login --profile my-dev-profile
aws sts get-caller-identity --profile my-dev-profile

The SSO token is cached under ~/.aws/sso/cache and the CLI renews short-lived role credentials while the session lasts. A stealer can still copy the cache, but what it gets expires and can be revoked centrally. Then delete the long-term keys.

Step 5: Put lifetimes and approvals on everything else

Set a GitHub maximum token lifetime well under the 366 day default (90 days or less is a sensible start for human tokens), restrict classic tokens, and require approval. Give npm install tokens read-only scope, an expiry and an IP allowlist. Set organization restricted agent logins in managed settings.

Step 6: Protect the release path and install time code

Protect release branches for administrators too, require reviewers on the release environment, and put code owners on .github/workflows/. Commit lockfiles and install with npm ci. Consider npm config set ignore-scripts true and allow lifecycle scripts only where needed. Open untrusted projects in a container or VM that does not mount your home directory; our guide to running Claude Code safely at work covers the agent side.

Common mistakes

• Rotating from the infected machine. New tokens go straight to the attacker.
• Changing the password and stopping. Sessions and refresh tokens often survive it.
• Rotating only the token you know was stolen. Assume everything the user could read is exposed.
• Forgetting the agent. Agent logins, MCP API keys and one year CI tokens are now on stealer collection lists.
• Treating provenance as proof of safety. If an attacker can trigger the workflow, the poisoned artifact carries valid provenance.
• Adding trusted publishing but keeping the old token. It is still a way in until token publishing is disallowed and the token revoked.
• Wide OIDC trust policies that accept any workflow in the organization.
• One token shared by many tools, so you cannot tell which leaked.
• Pasting secrets into agent prompts, which are stored locally and now targeted.
• Logging full request and response bodies in an LLM gateway. Redact credentials before logging and keep gateways off the public internet.

FAQ

Can an infostealer steal my Claude Code or Codex login?

Yes, if it runs as your user. Gen Digital reported in September 2026 that several stealer families collect coding agent tokens, naming Claude and Codex among targets. Anthropic documents that Claude Code uses the macOS Keychain or a 0600 file on Linux and Windows; OpenAI documents that Codex uses ~/.codex/auth.json or the OS credential store. Keychain storage raises the bar but does not stop malware running as you.

Does MFA stop infostealers?

No. MFA protects sign-in, and stealers take the cookies and tokens issued after it. Device bound sessions, short lifetimes, step-up authentication and fast revocation are what help.

What is the most dangerous token on a developer laptop?

Usually one that can publish a package or trigger a release, because it reaches every downstream user. Next come production cloud credentials and organization owner tokens on your code host.

How do I know if my npm token was used by someone else?

Check your packages' publish history with npm view for versions you did not release, review npm token list, and restrict tokens to your IP ranges so replays from elsewhere fail.

Does trusted publishing stop supply chain attacks?

It stops one route: a stolen long-lived publish token. It does not stop an attacker who can change your release workflow or trigger a release, so it needs branch protection and a protected release environment alongside it.

What should I rotate first after an infostealer infection?

From a clean machine: publish and signing credentials, then source control tokens and sessions, then cloud and identity provider sessions, then AI agent logins and API keys, then everything from .env files and shell history.

Can infostealers read my MCP server configuration?

Yes. MCP configs often hold keys and headers in plain text in your home or project folders, and Gen Digital reports stealers now target them. Pull keys from a secret manager or helper where the client supports it, and scope each key tightly.

Are device bound session cookies available today?

For some services. Google announced in May 2026 that DBSC is generally available in Chrome on Windows and on by default for Google Workspace users. Each site has to implement DBSC for its own sessions.

Should we ban AI coding agents because of this?

Bans tend to push use onto personal accounts you cannot see or revoke. Managed, organization restricted logins, keychain storage, tight MCP scopes and including agent tokens in rotation plans work better.

Fix it without waiting for upstream

When a stolen publish token becomes a poisoned release of a package you depend on, the job is the same as for any bad dependency version: find it, move off it and keep it out. Safeguard helps with that part; it does not protect endpoints, detect infostealers or tell you a token was stolen, which belong to your endpoint and identity tooling.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits after a token theft

When an advisory names a compromised version, the first question is "where do we run it?" Safeguard inventories repositories, container images and SBOM files (safeguard scan --dir ., --image <name> or --sbom <file>, with JSON results under ./output), and the platform shows which projects contain a given component and version. Policies and gates in the platform, and safeguard exec in CI, help keep a removed version from returning. The Safeguard CLI's assistant edits code and runs commands only with your approval, through /permissions modes (Ask, Accept edits, Plan, Auto and Strict). None of this replaces endpoint protection, identity provider session controls or registry token settings; the hardening steps above are where token theft is stopped.

See how Safeguard would help

These are recorded product sessions. They show the dependency and approval side of the problem, not endpoint protection.

This demo is a real CLI session. You ask the assistant to fix a vulnerable lodash version; it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with your approval and pushes nothing. After a poisoned release, the same flow moves a repository off the bad version with a human approving every step.

Click through it at your own pace, or open it full screen.

This demo is a real Android session that sends work to a computer running the Safeguard CLI and approves each command on the phone with Allow once, Allow for turn or Deny. It keeps a human approval on every command, instead of letting an agent run unattended on a machine full of tokens.

Click through it at your own pace, or open it full screen.

This demo sets up the local runner on your own machine, approves it with a device code and scans from the terminal. During an incident, it lets you check a repository from a clean machine you control for the compromised version.

Click through it at your own pace, or open it full screen.

You can download Safeguard and read the CLI documentation to try these flows on your own projects.

Quick check

Sources

• Gen Digital: Infostealers have found a new target, your AI agent
• Cyber Security Agency of Singapore: Advisory AD-2026-009
• CISA: Widespread supply chain compromise impacting npm ecosystem
• LiteLLM: Security incident, 21 October 2026
• Hacker News discussion of the LiteLLM 1.107.0 compromise
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• OWASP Non-Human Identities Top 10 (2025)
• npm Docs: Trusted publishing for npm packages
• npm Docs: About access tokens
• PyPI Docs: Trusted Publishers
• GitHub Docs: OpenID Connect in GitHub Actions
• GitHub Docs: Setting a personal access token policy for your organization
• GitHub Docs: Identifying audit log events performed by an access token
• GitHub CLI manual: gh auth login
• AWS CLI User Guide: Configuring IAM Identity Center authentication
• Claude Code Docs: Authentication
• OpenAI Codex Docs: Authentication
• Chrome for Developers: Device Bound Session Credentials
• Google Workspace Updates: DBSC generally available in Chrome for Windows
• DEV Community: AI Agents Don't Understand Secrets. That's Your Problem.

Last reviewed: 22 October 2026. Token formats, storage locations and registry policies change often; check the linked vendor documentation for current behavior.