When a platform, tool or dependency you rely on discloses a compromise, the first 24 hours are mostly about order: find what the vendor held, rotate by blast radius, then look for use of what leaked. This runbook turns that into five time boxes you can follow without improvising. It uses three October 2026 incidents as examples, OpenCode, Railway and LiteLLM, and it is honest about what app monitoring does and does not give you.
| Question | Short answer |
|---|---|
| What do I do in hour 0 to 1? | Decide whether you are in scope and list every secret and grant the vendor held |
| What do I rotate first? | The credentials with the largest blast radius, rotated at the issuer, not only in the vendor |
| How do I check for misuse? | Provider usage and billing, cloud audit logs, then your own application logs |
| What does app monitoring add? | Evidence about requests and log lines that look like attacks. It cannot prove a breach did or did not happen |
What does beam cve check add? | A lockfile match against known advisories, and a CI gate. It does not detect a new compromise |
| What is the most common mistake? | Deleting a key in the vendor's UI and calling it rotated |
If you want the monitoring and CI parts of this runbook in place before the next disclosure, you can get started with AgentBeam app monitoring. The rotation steps work without it.
Three breaches, three different exposure shapes
The three examples exposed secrets in different places, which is why step one is a list and not a template.
- OpenCode. Per the company, roughly 1.4% of OpenCode Console users had third-party provider keys saved in their workspace that "may have been exposed" after access to a legacy system. The exposure was in the vendor's hosted Console. OpenCode's co-founder said the open-source app and CLI are a separate case, so a key in your own local environment is not in scope by that account.
- Railway. Railway disclosed on October 21, 2026 that an unauthorized third party "may have accessed encrypted environment variables" and for some "obtained the decrypted contents." Its advice to every customer was to roll all environment variables, API keys and private registry credentials. Railway stated the attacker's goal was compromising AI inference providers.
- LiteLLM. Version
1.107.0was published to PyPI and GitHub Container Registry on October 21, 2026 with a credential stealer in it. Here the exposure was not a vendor database. It was whatever the installing environment could read, so the secrets at risk depend on where it ran.
One vendor database, one platform's stored variables and one poisoned package are three different questions. A runbook has to start by asking which one you are in.
Hour 0 to 1: identify the exposure surface
Do not rotate anything yet. Spend the first hour building the list that the rest of the day depends on.
- Read the primary notice. Take the vendor's own wording, not a summary. Note what they say was accessed, the time window, and who they say is affected. Separate stated facts from claims. The OpenCode post shows the pattern: what the company stated, and what is not confirmed.
- Check whether you were notified. Vendors that email affected customers usually say so. No email can mean not impacted by their account, but if the vendor also tells everyone to rotate, as Railway did, do not wait for the email.
- List what the vendor held for you. Environment variables, API keys, OAuth grants, deploy tokens, registry credentials, webhook secrets, stored provider keys, data.
- For a package, list where it ran. Laptops, CI runners, containers, build images. A poisoned release reads the environment of every place it executed, so the list is places, not packages.
- Write down the exposure window and start a timeline in a shared note. You will need it for the log hunt.
Keep that list in one place. Everything below is a pass over it.
Hour 1 to 4: rotate by blast radius
Rank each item by what an attacker could do with it, not by how easy it is to rotate. A credential that can spend money, read customer data or deploy code goes first.
| Priority | Examples | Why |
|---|---|---|
| 1 | Cloud account keys, database passwords, deploy and registry tokens, SSH and signing keys | Can read data, change production or ship code as you |
| 2 | AI provider keys with a spend path | Can be run up as a bill, and Railway named AI inference providers as the attacker's goal |
| 3 | Third-party API keys (payments, email, SMS) | Can cost money or send mail as you |
| 4 | Webhook secrets, session secrets, internal tokens | Can forge requests into your own app |
| 5 | Read-only or low-value keys | Rotate, but later in the day |
Three rules keep rotation from failing quietly.
Rotate at the issuer. Generate a new key at the AI provider or cloud account, deploy it, then revoke the old one there. Cyera's point on the OpenCode incident, as quoted in our coverage, is that removing a key from the vendor "doesn't stop someone who already copied it." Only the issuer can make it stop working.
Rotate from a clean machine. For a package compromise, do not rotate from the environment that ran the bad release. Roll back or pin to the last known good version, rebuild rather than patch in place, then rotate. That is the LiteLLM guidance in our write-up.
Set a spend limit at the provider. A budget inside a gateway or console covers only the spend that runs through it. A stolen key used directly against the provider is outside that budget, so the brake has to live at the provider.
Rotation can be blocked by the incident itself. During the Railway incident, builds were paused platform-wide, so new values were visible but redeploys were blocked until builds resumed. Plan for that: know which secrets you can rotate at the source today and which will take effect only when you can redeploy.
If a secret was committed to a repository or printed to a log at any point, rotate it regardless of the breach, and then look at where it was written. That is a different problem with the same fix.
Hour 4 to 12: hunt for use of what leaked
Now you have fresh credentials and a timeline. The question changes from "what could be exposed" to "was any of it used." Work from the outside in.
- Provider side. Check usage and billing at each AI provider and cloud account for the exposure window onward. Look for requests from unfamiliar places, unusual models, spikes, or accounts suspended for abuse. These are the places a stolen key shows up first.
- Audit logs. Read the audit logs your platforms keep: logins, token creation, role changes, new deploy keys, new OAuth grants. Railway noted that bucket credential revocations by its own employee would appear in audit logs, which is a reminder to read the entries that are expected so you can recognize the ones that are not.
- Your application logs. Search for the window around the disclosure. Look for requests that carry credentials you did not issue, repeated failed sign-ins, and requests aimed at cloud metadata endpoints, which is where a stolen workload credential gets tried.
- Your own code and pipelines. Look for unexpected commits, new workflow files, new dependencies and changed lockfiles.
What app monitoring gives you in this window
If beam monitor was already running, its findings are a ready-made index into step 3. It matches log lines and HTTP access logs against attack patterns: injection shapes, path traversal and secret-file probes, reverse shells and piped remote code, cloud metadata access, credentials written to logs, and repeated failed sign-ins. Findings carry the rule, severity, file, a count and a redacted excerpt of up to 600 characters, and they are grouped by client address, so a scan from one IP reads as one finding with a count.
Concretely, you can open the dashboard, filter to the app and the window, and ask: did anything probe for .env files or metadata endpoints, did a credential show up in a log line, was there a burst of failed sign-ins. That turns a grep across gigabytes into a short list to read.
You can also start a monitor on the day of the incident. It is not retroactive, but it will tell you what hits the app from now on, including attempts to use things that leaked.
What it cannot tell you
This part matters, so plainly:
- It is heuristic and watch-only. A match says a line looks like an attack, not that one succeeded. It never blocks anything and does not sit in the request path.
- It sees only what reaches your logs. A key stolen from a vendor database and used directly against your cloud account or AI provider never touches your application. Your provider and cloud audit logs are the evidence for that, not the monitor.
- A quiet monitor is not an all clear. It will miss payloads its patterns do not describe and traffic that is never logged.
- It was not running yesterday. If you start it today, it has no view of the exposure window.
Treat findings as leads and the absence of findings as no information.
Hour 12 to 24: harden, then add monitoring and a CI gate
By now the urgent rotation is done. Use the rest of the day to make the next disclosure cheaper.
Shrink what a vendor can hold. Prefer scoped, short-lived credentials over broad long-lived ones. Give each service its own key so one leak does not unlock everything. Move high-value secrets to a store with its own audit trail.
Add a spend limit and an alert at each provider, if you did not in hour 1 to 4.
Start app monitoring on the application. Install the CLI where the app runs, set the per-app token, and follow the logs the app already writes:
npm install -g @agent-beam/beam
export BEAM_APP_TOKEN=beam_app_... # from your secret store, never committed
beam monitor --file /var/log/app/app.log
beam monitor test # confirms the whole path with one test finding
The token is shown once, stored hashed, accepted only by the App monitoring endpoints and over HTTPS, and can be rotated or revoked. App monitoring has to be turned on in the dashboard by a workspace owner or admin first. The full options are in the App monitoring docs, and the walk-through is in Monitor a running app for attacks with beam monitor.
Add a dependency gate to CI. A breach like the LiteLLM one is a reason to know exactly which versions you ship:
beam cve check . --fail-on critical
It matches package names and versions from your lockfiles against AgentBeam's CVE database, and exits with code 2 when a finding meets --fail-on. Only names and versions are sent. In CI it uses the same BEAM_APP_TOKEN, stored as a CI secret. Start at critical and tighten as the backlog clears. The pipeline setup is in Check dependencies against known CVEs in CI.
Be clear about its limit. It is not a malware scanner. A freshly poisoned release has no advisory the moment it is published, so a brand-new compromise will not match anything until it is in the database. Pinning versions and delaying upgrades of critical packages are what cover that gap, not the gate.
How AgentBeam handles this
AgentBeam covers two narrow parts of this runbook. beam monitor watches a running app's logs and HTTP traffic and sends redacted findings, which helps with the log hunt and with ongoing watching. beam cve check gives you the lockfile match and the CI gate. Raw log lines stay on your server, and the CLI is open source.
It does not rotate your secrets, reach into a vendor's systems, block attacks, or tell you whether a vendor's data was stolen. Rotation, provider audit logs and the vendor's own disclosure remain the primary evidence, and AgentBeam is a second view alongside them. Its agent-side monitoring is a separate topic, covered in What is AI agent monitoring?. To try it, the getting-started link works whether or not you already have an account.
Paste this to your coding agent
AgentBeam ships a bundled skill for the monitoring step. Install it, then give your agent the prompt below. The skill names come from Let your coding agent set it up.
npx @agent-beam/beam add skill agentbeam-app-monitoring -g --all-agents
Set up AgentBeam app monitoring for this repo using the agentbeam-app-monitoring
skill. Ask me for the app name and confirm I have created the app in the
dashboard and set BEAM_APP_TOKEN. Keep the token out of the repository, then
finish with beam monitor test. Also add a CI step that runs
beam cve check . --fail-on critical with BEAM_APP_TOKEN as a secret.
Do not rotate or change any other secrets.
The last line is deliberate. Rotation touches production and billing, so keep a person in that loop.
Printable checklist
| Window | Action | Done |
|---|---|---|
| 0 to 1 h | Read the vendor's primary notice and note the exposure window | [ ] |
| 0 to 1 h | List every secret, grant and dataset the vendor held | [ ] |
| 0 to 1 h | For a package, list every place it ran | [ ] |
| 1 to 4 h | Rank the list by blast radius | [ ] |
| 1 to 4 h | Rotate at the issuer, deploy, then revoke the old key | [ ] |
| 1 to 4 h | Rotate from a clean machine and rebuild, not patch, for a package compromise | [ ] |
| 1 to 4 h | Set provider-side spend limits | [ ] |
| 4 to 12 h | Check provider usage and billing from the window onward | [ ] |
| 4 to 12 h | Read cloud and platform audit logs | [ ] |
| 4 to 12 h | Search app logs for credential use, metadata probes and failed sign-ins | [ ] |
| 4 to 12 h | Review recent commits, workflows, dependencies and lockfile changes | [ ] |
| 12 to 24 h | Scope and shorten credentials, one per service | [ ] |
| 12 to 24 h | Start beam monitor, confirm with beam monitor test | [ ] |
| 12 to 24 h | Add beam cve check . --fail-on critical to CI | [ ] |
| 12 to 24 h | Write down what happened, and when you will review again | [ ] |
Limits of this runbook
- It assumes the vendor discloses honestly and in time. Several details in the three examples, such as how attackers got in, were not disclosed.
- A claim is not a confirmation. For unverified reports, such as the OpenRouter claim, rotate on the cheap, low-regret items and wait for the company before doing expensive work.
- It cannot see use of a stolen key that never touches your application.
- Evergreen does not mean exhaustive. Your own regulators, contracts and customers may set notification duties this post does not cover.
Related reading
- October 2026 attacks timeline for the incidents referenced here.
- Railway breach: environment variables, AI keys and what to rotate.
- OpenCode Console breach: claimed vs verified.
- LiteLLM 1.107.0 compromise.
- AI API key theft: inside the reseller supply chain for what happens to stolen keys.
- AI agent deployment and incident response for the agent side of the same discipline.
- App monitoring solution page and the CVE database.
- What app monitoring can and cannot catch when your platform is breached
- API keys in logs and env vars: how they leak and how to catch it
- Monitor a Railway-hosted app for attacks with beam monitor
Frequently asked questions
What should I do first when a vendor discloses a breach?
List what that vendor held for you: secrets, tokens, OAuth grants, deploy access and data. You cannot rotate what you have not listed. Do this before touching anything, so the rotation order follows blast radius and not whatever you remember first.
Is deleting a key in the vendor dashboard enough?
No. Removing a key from a vendor does not stop someone who already copied it. Only the system that issues the key, such as the AI provider or cloud account, can make it stop working, so rotate at the source and then update the vendor.
Can beam monitor tell me whether I was breached?
No. beam monitor is heuristic and watch-only. It flags log lines and HTTP requests that look like attacks, and it only sees what reaches your application logs. A quiet monitor is not proof that nothing happened, and a vendor-side theft may never touch your logs.
What does beam cve check do in a breach response?
It matches the package names and versions in your lockfiles against AgentBeam's CVE database and exits with code 2 when a finding meets --fail-on. Only names and versions are sent. It is not a malware scanner, and it will not catch a brand-new compromise before that compromise is in the database.
How long should I keep watching after rotating?
Keep the extra watching for at least the vendor's exposure window plus several days, and keep the provider spend limits and the CI gate permanently. Stolen keys are sometimes tried well after the disclosure, so a clean first day is not an all clear.
When the next disclosure lands, you will want monitoring that was already running. You can set up AgentBeam app monitoring today and keep the checklist above for the rotation work.
Details are accurate as of October 23, 2026. Incident facts come from the vendors' and researchers' statements as cited in the linked posts and may change. App monitoring needs an AgentBeam workspace with it turned on by an owner or admin, and usage counts toward a monthly allowance that depends on your plan.