CI, Registry & Release-Pipeline Credential Kit

1. python3 ci_credential_check.py --selftest prints selftest ok.
2. python3 ci_credential_check.py .github/workflows on your repo lists risky permissions, unpinned actions, long-lived registry tokens and release jobs without protected environments.
3. Fill build_token_inventory.csv (names and scopes only, no values) and work through 01 until every row has revoked_old=yes.
4. Apply 02 and re-run the script until it exits 0.
5. Dashboard: add --afk-json to any command above and save the output as results/ci-credentials.json; load it in the Agent Cyber Defense Dashboard. Python 3.9+, no installs. Read-only: nothing is changed, sent or uploaded.

Oct 21 incident response: registry, CI and git-host tokens

Facts we rely on (Oct 21, 2026; wording follows the sources)

• Railway says an unauthorized party may have accessed encrypted environment variables and, for some, obtained decrypted contents. It believes this is part of a series of attacks targeting platform companies to compromise AI inference providers, and notified upstream providers to revoke keys. It recommends all users roll every variable and private registry credential and review logs. (https://blog.railway.com/p/security-disclosure-wednesday-october-21st)
• Railway later reset bucket S3 credentials and the GitHub tokens it held, and invalidated all Railway API tokens. GitHub tokens stored as registry credentials still work on GitHub until you revoke them. (https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset, https://status.railway.com/incident/QH8L8B3E)
• Railway published provider-specific guides to check for unexpected Anthropic and xAI (Grok) usage. (https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-anthropic-usage, https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-grok-usage)
• LiteLLM says its release pipeline was compromised and litellm==1.107.0 (PyPI, 11:39-13:23 UTC) plus Docker/GHCR tags v1.107.0, latest, main-latest, main-stable (from 11:46 UTC) contained credential-stealing malware. The attacker used leaked developer GitHub CLI OAuth tokens found in logs of an internal deployment. (https://docs.litellm.ai/blog/security-incident-oct-21-2026, https://osv.dev/vulnerability/MAL-2026-2144)

Steps

1. Revoke on GitHub, not just in Railway. Railway says GitHub tokens it stored as registry credentials were removed from Railway but still work on GitHub until you revoke them. Revoke those PATs in GitHub settings, then reconnect Railway's GitHub app. (https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset)
2. Roll every private registry credential that was a Railway variable or present on a host that ran litellm 1.107.0 (Docker Hub, GHCR, npm, PyPI, cloud registries). (https://blog.railway.com/p/security-disclosure-wednesday-october-21st, https://docs.litellm.ai/blog/security-incident-oct-21-2026)
3. Recreate Railway API tokens used by CI or scripts; Railway invalidated all of them. (https://status.railway.com/incident/QH8L8B3E)
4. Check developer CLI tokens. LiteLLM's attacker used developers' GitHub CLI OAuth tokens found in proxy logs. Run gh auth status on dev machines; revoke and reissue tokens that touched an exposed log store, and stop logging full LLM response bodies. (https://docs.litellm.ai/blog/security-incident-oct-21-2026)
5. Audit your org's log for branch-protection overrides, workflow file changes, deleted workflow runs and new deploy keys on Oct 21-22. Those were the steps used against LiteLLM.
6. Verify recent artifacts. For anything you published Oct 21-22, compare the artifact digest with a rebuild from your tagged source.