Agent Secrets Exposure & Rotation Kit

What to do when a host, package or CI system may have leaked the keys your agents use: a 30-minute first-response runbook (pause sending/paying agents, rotate at the issuer, revoke delegated OAuth grants, check for misuse), a secrets inventory template ranked by blast radius, an incident record, and rotation_check.py, which flags unrevoked, stale or unowned credentials and refuses real secret values.

Last reviewed: Oct 22, 2026, 2:05 PM PT. We update this page when Railway or LiteLLM post new information; the newest changes are under “What changed since Oct 21”. This is not legal advice.

The October 21, 2026 attacks: how they worked and what to do

On October 21, two separate disclosures described attacks aimed at the credentials that AI applications depend on. Railway says this is part of "a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." Here is what the primary sources say, which steps cost nothing, and where our kits help.

What changed since Oct 21 (updated Oct 22, 2:05 PM PT)

Railway. Per Railway's status page:

LiteLLM.

Also this week, for agent builders (separate issues with no known link to Oct 21): vLLM 0.31.0 fixes a critical remote-code issue when trust_remote_code is on. The MCP TypeScript SDK 1.32.0 / 2.3.0 fixes five HTTP server and client issues. Node.js 22.23.4 / 24.22.1 / 26.12.1 fix a Brotli decoder RCE and TLS hostname bypasses. Added Oct 22 afternoon: GitHub flagged versions of two coding-agent skill bundles on npm (agentic-awesome-skills, opencode-skills-collection) and a PyPI typosquat, aanthropic, as malware. Next.js 16.4.1 / 15.5.28 fix two critical unauthenticated RCEs. PyJWT 2.14.0 fixes token forgery through an empty-key JWK. See the Cyber Defense Desk for the free first steps.

Timeline (Oct 21, 2026; UTC, with PT in brackets)

Path 1: Secrets stored on a hosting platform (Railway)

What happened. Railway detected anomalous activity in systems that store customer environment variables. Its investigation "indicates that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." Those variables can hold API keys and database and registry credentials. Railway says impact "may be limited to a subset of users" and will email the customers it confirms were affected.

Who is affected. Anyone who stored secrets in Railway environment variables. Railway recommends that all users take action as a precaution.

Free steps first.

  1. Roll every environment variable stored in Railway, including API keys and private registry credentials. Rotate each key where it was issued (the model provider, Stripe, GitHub, your database), then revoke the old one. Changing the value in the panel alone leaves the old key working.
  2. Review provider and service logs for unusual use, especially spend on inference keys.
  3. Set spend limits or alerts on model-provider keys if your provider offers them.

Which kit helps. Agent Secrets Exposure & Rotation Kit: a blast-radius-ordered rotation runbook, an inventory sheet, and a checker that flags keys still unrevoked. Incident Runbooks gives you the severity levels and the kill switch for agents that send, pay or deploy. Coming soon: Inference Key Abuse & Spend Caps Kit (coming soon).

Path 2: A poisoned package release (LiteLLM 1.107.0)

What happened. LiteLLM says its release pipeline was compromised and pushed 1.107.0 to PyPI and Docker. The release contained malware that steals credentials and loads remote code. According to LiteLLM and the OSV record, the official source tag was clean. The artifacts were built from an attacker-controlled lookalike repository, and the malicious files run whenever Python starts, even if your code never imports LiteLLM. OSV lists cloud, Kubernetes, CI, registry and AI developer-tool credentials among what it collects.

Who is affected. Per LiteLLM: anyone who installed an unpinned LiteLLM through pip between 11:39 and 13:23 UTC, or ran the Docker tags above between 11:46 and 14:20 UTC. LiteLLM says its private enterprise registry was not affected.

Free steps first (summarised from LiteLLM's notice, which is the authority):

  1. Check with pip show litellm and look for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Not finding them does not prove an environment is clean.
  2. Don't start with pip install, because any Python start re-runs the payload. Follow LiteLLM's cleanup order, or better, rebuild images and virtual environments from scratch pinned to litellm==1.106.2.
  3. From a clean machine, rotate everything the host could reach: the cloud role, every provider key in the LiteLLM proxy database plus master and virtual keys, the database password, and any secret in the environment.
  4. Pin packages by exact version and containers by digest rather than latest.

Which kit helps. Agent Secrets Exposure & Rotation Kit for the rotation, Incident Runbooks for containment and the postmortem, and Agent Security Audit Kit to review what your agents' hosts can reach. Coming soon: Supply-Chain Pinning & Verification Kit (coming soon).

Path 3: Developer and CI tokens that leaked into logs

What happened. LiteLLM believes the attacker reached an internal LiteLLM deployment that was exposed to the public internet, found an unexpected account there, and obtained GitHub CLI OAuth tokens from its logs. LiteLLM says it observed situations in which an AI coding tool embedded a user's GitHub CLI token in a response body, which then appeared in logs. Three developer credentials were then used: one owner-level token to disable branch protection, one to approve production, and one to delete workflow records. LiteLLM says it is still confirming parts of this chain.

Who is affected. Any team whose AI gateway or proxy logs full request or response bodies, or whose internal tools face the internet.

Free steps first.

  1. Search gateway and agent logs for tokens (for example gho_, ghp_, sk-), purge them, and turn off body logging or add redaction.
  2. Revoke and reissue GitHub CLI and CI tokens. Prefer short-lived, narrowly scoped tokens.
  3. Limit organization-owner accounts, and require more than one person to change branch protection or release workflows.
  4. Take internal admin tools off the public internet, and review user accounts on them.

Which kit helps. MCP & Tool-Access Review Kit to audit which tokens and tools each agent holds, Agent Observability Starter and Real-Time Agent Monitoring Kit to log usefully without logging secrets, and AI Vendor Security Questionnaire for questions to ask hosts and gateway vendors. Coming soon: CI & Registry Credential Hardening Kit (coming soon).

Path 4: Third-party tools that hold OAuth grants for your accounts

This path is a precaution, not a confirmed part of either incident. Apps hosted on an affected platform may store OAuth tokens for your X, LinkedIn, GitHub or Google accounts. You can revoke an app's access from each account's own connected-apps settings, and that works even if the app itself is down. Reconnect only after the vendor confirms rotation. Coming soon: OAuth Grant Revocation Kit (coming soon).

Sources

Agent Field Kit sells editable templates. This page is general defensive information, not legal or security advice, and it summarises others' disclosures, which may change. Check the sources above for the latest.