Third-Party OAuth Grant Revocation Kit

1. python3 oauth_grant_check.py --selftest prints selftest ok.
2. python3 oauth_grant_check.py grants_register.csv --incident-vendor railway --today 2026-10-22 flags the example grant to a Railway-hosted app and exits 1.
3. List your own grants from each platform's connected-apps page (02). Names and scopes only.
4. Revoke, fill revoked_on, re-run until it exits 0.
5. Dashboard: add --afk-json to any command above and save the output as results/oauth-grants.json; load it in the Agent Cyber Defense Dashboard. Python 3.9+, no installs. Read-only: nothing is changed, sent or uploaded.

Oct 2026 update (section 04)

• [ ] MCP server connections listed in every coding agent and added to the register.
• [ ] Unrecognized servers removed and their OAuth grants revoked at the identity provider.

Oct 21 incident response: third-party app 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)

Who this is for

You connected accounts (GitHub, Google, Slack, X, LinkedIn, Microsoft) to a tool that runs on Railway, to a tool that ran litellm 1.107.0, or to Railway itself. Railway's disclosure covers secrets stored in environment variables; whether a given vendor kept user tokens there is something to ask that vendor. Revoke as a precaution.

Steps

1. List vendors at risk: tools you know are hosted on Railway or use LiteLLM, plus Railway's own GitHub connection. Ask each vendor to confirm; don't wait for the answer to revoke.
2. Revoke at the platform (02), not inside the vendor's app. This works even if the vendor is offline.
3. Check activity on each account from Oct 21: posts, DMs, emails, repo pushes, new deploy keys, forwarding rules, new OAuth apps.
4. Re-grant only when needed, with the narrowest scopes, after the vendor confirms it has rotated its own secrets.
5. For GitHub: reconnect Railway's GitHub integration per Railway's guide and revoke any PATs you stored there. (https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset)
6. Record each revocation in grants_register.csv.