App monitoring watches your own application. It cannot see inside the platform your application runs on, and it would not have stopped the OpenCode Console or Railway breaches. Both incidents happened on the vendor side: provider keys saved in a vendor's Console workspace in one case, customer environment variables in the other. A monitor reading your app's logs has no view of either place. This post is about the part you still control when the breach is upstream, and about where log-based monitoring is genuinely useful and where it is not.
The two incidents are examples. The lessons should hold for the next platform breach too, whoever it hits.
| Question | Short answer |
|---|---|
| Would app monitoring have prevented a provider-side breach? | No. It cannot see inside a vendor's systems, and it never blocks anything |
| What can it show you? | Your own app being probed, secrets printed into logs, abuse traffic, repeated failed sign-ins |
| What protects you upstream? | Fewer and shorter-lived secrets, scoped keys, spend limits, fast rotation |
| Does it help after an incident? | Yes, as a dated record of findings to review alongside provider logs |
| Does it check dependencies? | Yes, beam cve check, which is a separate job from watching logs |
| Is detection reliable? | No. It is heuristic: some misses, some false positives |
If you want to see what your own app is exposing, you can start with app monitoring while you read; it works whether or not you already have an account.
What the two breaches have in common
Per our OpenCode write-up, OpenCode told about 1.4% of Console users that provider keys saved in their workspace "may have been exposed" after unauthorized access to a legacy system. The company's co-founder said the open-source app and CLI were not affected because those keys never come to OpenCode. Entry method and key misuse were unconfirmed in that post.
Per our Railway write-up, Railway said an unauthorized party "may have accessed encrypted environment variables" and obtained decrypted contents for some of them, and advised every customer to rotate all environment variables, API keys and private registry credentials. The root cause was not disclosed in that post.
The common shape is simple. A secret that you handed to a third party was stored on the third party's systems, and it left from there. Nothing on your servers or laptops had to be touched. The October attacks timeline tracks how these incidents cluster, and the OpenRouter claim is the third in that run.
Why app monitoring cannot catch this
beam monitor follows your application's log files and HTTP access logs, or piped output, and matches lines against attack patterns on the server where it runs. It reads what your app writes. It does not read the vendor's database, key store or internal logs, and it is not in the request path.
So when a vendor's storage is read by an attacker, there is nothing in your logs. The first sign is usually a vendor email or a strange charge on a provider bill. That is a limit of the approach, not a bug to be fixed with a better rule. Anyone who tells you a log monitor on your side would have caught a vendor-side breach is selling something.
Two more limits worth stating plainly:
- It never blocks.
beam monitordoes not block requests, change the application or sit in the request path. It raises findings for a person. - Detection is heuristic. It will miss attacks it has no rule for, and some legitimate traffic will match. Keep your firewall or WAF, input validation and patching.
What you still control
If the breach is upstream, your leverage is in how much a stolen secret is worth by the time someone uses it. These are the levers, roughly in order of payoff.
1. Keep fewer secrets in fewer places
A key pasted into a vendor Console, a platform variable, a developer .env and a CI secret is four copies to rotate. Before an incident, list where each production secret lives. After an incident, the list is your rotation plan. The Railway post makes the same point: rotating the platform variable does not rotate a copy sitting elsewhere.
2. Prefer short-lived and scoped credentials
A key with an expiry date and a narrow scope is worth less to a thief. Where a provider supports expiring keys, per-project keys or workload identity, use them. OpenAI's API key safety guidance, as quoted in our OpenCode post, recommends a unique key per team member and keys with an expiration date.
One key per service also means a leak names its own source. If the key from one app is abused, you know which app to look at.
3. Set spend limits at the provider
This is the control that caps the damage when everything else fails. Per the OpenCode post, budgets inside a vendor Console cover only spend that runs through that vendor, so a stolen key used directly against the provider sits outside them. The only brake is a limit set at the provider that issued the key. Set it on every AI provider account, with alerts below the limit.
4. Know what your own app logs
This is where monitoring earns its place. Credentials written to logs are a frequent root cause of exposure: a debug line prints an Authorization header, and a log shipper copies it into other systems. beam monitor has a rule for credentials in logs: private keys, provider API keys, bearer tokens and KEY_NAME=value secrets. A finding tells you which file and which rule, with the secret redacted in the excerpt, so you can fix the logging statement and rotate what leaked.
5. Rotate fast, and rehearse it
Rotation is slow when nobody knows which services read which key. Write the runbook while nothing is on fire: where the key is issued, where it is stored, what reads it, and how to roll it without downtime. The Railway disclosure is a useful example of the friction. New values could be set while builds were paused, but could not be redeployed until builds resumed.
6. Keep an evidence trail
After a vendor disclosure, the question is whether anyone used your secrets. Provider usage logs answer part of it. Your own app logs and findings answer another part: did anything probe your app, reach for .env or cloud metadata endpoints, or hammer your sign-in? A dated record makes that review faster. It cannot prove nothing happened, only show what your app saw.
What app monitoring does show you
Used for what it is, beam monitor gives you a view of your own surface. From the docs, it looks for:
- Probing and injection attempts: SQL, command and template injection, path traversal, JNDI lookups, and requests for
.env,.gitand credential files. A secret file actually served with a 2xx response is a high-severity finding. - Attempts to get at API keys: requests asking your app for its keys or environment, relevant if your app passes user text to a model.
- Credentials in logs and model output: the leak in point 4 above.
- Reconnaissance and abuse: attack-tool user agents, floods from one address, and repeated failed sign-ins.
You can tune the noise. A workspace owner or admin picks a level (Light alerts on critical only, Standard on high and critical, Strict on medium and above), and can create a rule to ignore a false positive or keep a finding on the dashboard without alerting. Findings go to the dashboard and to up to five webhooks (Slack, Discord or signed JSON).
For dependencies, beam cve check . reads your lockfiles and compares package names and versions against AgentBeam's CVE database. It exits with code 2 when a finding meets --fail-on, which suits a CI gate. See Check dependencies against known CVEs in CI. It tells you about known vulnerabilities in what you ship, which is a different problem from a vendor's breach.
Using it after a disclosure
When a vendor announces an incident, a reasonable sequence is:
- Rotate at each provider, AI keys first, then databases, payments, auth secrets and registry tokens. Revoke the old keys only after the replacements work.
- Review provider usage from before the disclosure for spikes, unfamiliar models and odd hours.
- Review your own findings and logs for the same window: probing, served secret files, repeated failed sign-ins, secrets in logs.
- Tighten limits: spend caps, key scopes, one key per service.
- Write down the gaps you found, such as a key you could not locate quickly, and fix those before the next one.
Step 3 only works if monitoring was already running. A monitor started after the incident has no history from before it.
Honest limitations
- It cannot see inside OpenCode, Railway or any other platform. A vendor-side breach produces no line in your logs.
- It does not block, rotate keys, or stop a stolen key from being used.
- Detection is pattern-based. A novel payload, or an attacker whose traffic never reaches your logs, will not be flagged.
- An app that answers 200 to every path, such as a single-page app's catch-all, can trip the served-file rule, so expect to tune.
- Usage counts toward a monthly allowance that depends on your plan, and App monitoring has to be turned on by a workspace owner or admin first. When the allowance runs out, capture pauses until it resets; your application is never affected.
- The optional LLM review reduces noise but is not a verdict you should rely on alone. The docs say its hardening makes manipulation hard, not impossible.
- Railway-hosted apps can be watched without changing the app, but the docs warn that the Railway project token it needs can read every variable in its project and can deploy. Prefer the in-app SDK when you can change the app. Given the subject of this post, take that warning seriously.
How AgentBeam handles this
AgentBeam covers the part of the problem that sits on your side of the line. beam monitor watches your running app's logs and access logs, matches lines locally, and sends only redacted findings: the rule, severity, file, a repeat count and an excerpt capped at 600 characters. Raw log lines stay on your server. Per-app tokens are least-privilege, shown once, stored as a SHA-256 hash, rotatable at once and audit-logged, and Beam's redaction removes beam_app_ tokens from evidence. beam cve check covers dependencies.
What it does not do is watch your vendors. Treat it as a smoke alarm in your own building: useful, but no help if the fire is in the landlord's wiring. You can get started with app monitoring. See the app monitoring solution page and the beam monitor guide.
Paste this to your coding agent
Install the skill first, using the commands from Let your coding agent set up AgentBeam:
npx -y @agent-beam/beam add skill agentbeam-app-monitoring -g --all-agents
Beam scans the skill before it installs. Read the scan report, then paste:
Use the agentbeam-app-monitoring skill to add AgentBeam app monitoring to this repo.
App name: "<your app name>".
Rules:
- Do not write the app token into any file or into this chat. Read it from the
BEAM_APP_TOKEN environment variable, and tell me where to set it in my secret store.
- Find where this app runs (Railway, Docker, a server or CI) and pick the least
invasive way to watch its logs.
- Add beam cve check . to CI.
- Finish by running beam monitor test.
- Show me the diff before committing anything.
Also list every place this repo, its CI and its deploy config reads a secret from,
so I know what to rotate after a vendor breach. Do not print any secret values.
Create the app in the dashboard first (getting started), since an owner or admin has to turn App monitoring on and add the app.
Related reading
- OpenCode Console breach: provider keys, claimed vs verified
- Railway breach: environment variables accessed, rotate every secret
- OpenRouter breach claim and the AI key theft campaign
- Monitor a running app for attacks with beam monitor
- Check dependencies against known CVEs in CI
- October 2026 attacks timeline
- Vibe coding security checklist
- 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
- Your first 24 hours after a vendor breach: a rotation and monitoring runbook
Frequently asked questions
Would app monitoring have prevented the OpenCode or Railway breach?
No. Both compromises happened inside the vendor's own systems, which a monitor running next to your app cannot see. App monitoring watches your application's logs and HTTP access logs, flags what looks like an attack, and never blocks anything.
What can beam monitor still do when a platform is breached?
It can show your own app being probed, flag secrets printed into logs, surface abuse traffic and repeated failed sign-ins, and give you a dated record of findings to review afterwards. It is heuristic, so it will miss some things and flag some harmless ones.
What should I do first when a vendor says secrets may have been exposed?
Rotate at the provider that issued each secret, starting with the ones that cost money fastest, such as AI provider keys. Then review usage and logs from before the disclosure, and set spend limits so the next leak is capped.
Does beam monitor send my logs to AgentBeam?
No. Lines are matched on the server where it runs, and only findings leave: the rule, severity, file, a repeat count and a redacted excerpt of up to 600 characters. Dependency checks send package names and versions only.
How do I set up app monitoring quickly?
Run npx -y @agent-beam/beam add skill agentbeam-app-monitoring -g --all-agents and ask your coding agent to add monitoring to your app. Create the app in the dashboard, set BEAM_APP_TOKEN in your secret store, and finish with beam monitor test.
If this post made you want a list of your own secrets and a record of what your app sees, set up app monitoring before the next disclosure, not after.
Accurate as of October 23, 2026. Incident details come from our earlier posts and may have changed since; check the vendors' own disclosures. Product behavior follows the App monitoring docs at that date and may change in later releases.