Environment variables are where most apps keep their secrets, and logs are where those secrets quietly spread. AI provider keys, database URLs, payment keys and registry tokens usually sit in env vars, which makes them the prize for anyone who gets near your platform, and a single careless log line can copy one into a dozen other places. This post covers why env vars and API keys are targeted, the ordinary ways keys end up in logs, a rotation checklist ordered by blast radius, and where beam monitor and its credentials-in-logs rule fit in, including what it cannot do.
TL;DR
| Question | Short answer |
|---|---|
| Why are env vars the target? | They hold keys that are directly useful: inference on your bill, database access, payments |
| How do keys get into logs? | Debug prints, logged Authorization headers, error and request dumps, log shippers |
| What do I rotate first? | Whatever can spend money or reach customer data fastest, then work outward |
Can beam monitor prevent a provider breach? | No. It watches your own app's logs and cannot see or stop a breach at a provider or platform |
| Does it block anything? | No. It never blocks requests, changes your app or sits in the request path |
| Do raw logs leave my server? | No. Only redacted findings of up to 600 characters leave |
If you want the monitoring part running while you read, the getting-started link works whether or not you already have an AgentBeam account.
Why env vars and provider keys are the prize
Two incidents from October 2026 show the pattern. They are examples, and the details below come only from what the companies and our own write-ups have said.
- OpenCode Console. OpenCode's maker 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 keys lived in the vendor's storage, so nothing on a developer laptop would have seen them leave. See OpenCode Console breach: claimed vs verified for what is confirmed and what is not.
- Railway. Railway disclosed that a third party "may have accessed encrypted environment variables" and obtained decrypted contents for some of them, and told every customer to roll all environment variables, API keys and private registry credentials. The root cause and how values were decrypted were not disclosed. Details are in the Railway breach post.
The common thread is not a specific bug. Model API keys can be monetized directly: run inference on someone else's bill, resell access, or harvest model output at scale. A place that stores many customers' secrets is a concentrated source of them. For the cloud-billing version of the same economics, see LLMjacking via hijacked billing accounts, and for the wider pattern across the month, the October 2026 attacks timeline.
A breach at a provider or platform is outside your app. Nothing in your logs will show it, and no log monitor can prevent it. What you control is how many copies of a secret exist, how fast you can replace it, and whether your own app is leaking it.
The quiet ways keys end up in logs
Most log leaks are not attacks. They are ordinary code doing something helpful during a bad afternoon.
- Debug prints.
console.log(config)orprint(os.environ)during a deployment problem, then merged and forgotten. - Authorization headers. Request logging middleware that records all headers writes
Authorization: Bearer ...or anx-api-keyheader on every call, including outbound calls to a provider. - Error and request dumps. An exception handler that serializes the failing request or the HTTP client's config. Many client libraries include headers or the full URL in their error objects, and a key in a query string lands in the access log.
- Connection strings. A database URL with the password inside it, logged on startup or in a failed-connect message.
- Log shippers and aggregators. Once a line is in a file, an agent forwards it to a log platform, a metrics vendor, and maybe a chat channel. One leak becomes several copies, each with its own retention and its own access list.
- Verbose modes left on. Trace-level logging in production, or a library's debug flag that prints request bodies.
- Model output and prompts. If your app logs prompts and replies, a user (or an injected document) can get the model to print an environment value, and the log keeps it.
Log lines are also often readable by far more people than the secret manager is. Treat a key in a log as exposed to everyone who can read that log, now and for as long as it is retained.
Rotate fast: a checklist ordered by blast radius
The order below follows the rotation order from the Railway write-up, because some keys are abused within hours. Rotate at the source, not just in the variable.
- AI provider keys. OpenAI, Anthropic, Google, OpenRouter, Mistral, Groq and any other inference key. Create a new key, update your services, then revoke the old one at the provider. Removing a key from a third-party console does not revoke it; only the provider can make it stop working.
- Database and cache credentials. Change the password or credential at the database, not only the connection string.
- Payment and messaging. Stripe secret and webhook signing keys, email and SMS providers.
- Auth secrets. OAuth client secrets, JWT signing keys and session secrets. Rotating these signs users out, so plan for it.
- Source and registry access. GitHub tokens and deploy keys, npm and container registry credentials.
- Cloud and storage. AWS, GCP and Azure keys, bucket keys, Cloudflare tokens.
- Webhooks and integrations. Slack and Discord webhooks, analytics and monitoring keys.
Practical points that save you from a second incident:
- Overlap, then revoke. Where the provider supports two active keys, deploy the new one first and revoke the old one immediately after the redeploy lands.
- Set spend limits at the provider. A budget in a third-party console does not cap a stolen key used directly against the provider.
- Check usage from before the suspected exposure. Look at provider usage and billing for unfamiliar models, regions or volume.
- Search your logs for the old key. If it appears in a log, you now know which systems held a copy.
Catch it early with beam monitor
beam monitor follows an application's log files and HTTP access logs, flags lines that look like an attack or a compromise, and sends findings to your workspace and its webhooks. One of its rules covers credentials written to logs or model output: private keys, LLM and other provider API keys, bearer tokens and KEY_NAME=value secrets. A related rule looks for attempts to get at API keys, such as requests asking the app for its environment (printenv, cat .env), and a .env, .git/config or credentials file actually served with a 2xx response. Those are high severity, so they alert on the default level. A single-page app that answers 200 to every path can trip the served-file rule.
Install it where the app runs, set the per-app token, and point it at the logs the app already writes. These commands come from the App monitoring docs:
npm install -g @agent-beam/beam
export BEAM_APP_TOKEN=beam_app_... # better: from your secret store, never committed
beam monitor --file /var/log/nginx/access.log --file /var/log/app/app.log
beam monitor test # a test finding appears on the dashboard and at the app's webhooks
If your app writes to standard output, pipe it in: node server.js 2>&1 | beam monitor --stdin. beam monitor status shows the app, the level and this month's usage. App monitoring must first be turned on by a workspace owner or admin. The full setup is in Monitor a running app for attacks with beam monitor.
What leaves your server
Lines are matched on the server where beam monitor runs, and raw log lines are never sent. A finding carries the rule, severity, file, a repeat count and a redacted excerpt of up to 600 characters. Redaction removes credentials, bearer tokens, URL userinfo, email addresses and your policy's custom detector matches. Query strings are kept, because in an access log the query is usually the attack.
The per-app token follows the same thinking: it can only send that app's findings, it is stored as a SHA-256 hash, and Beam's redaction removes beam_app_ tokens from evidence, with the credential rule flagging one written to a log.
Tuning noise with rules
A credentials rule can fire on harmless text, such as a documented example key in a log or a test fixture. Owners and admins can click Create rule on a finding in the dashboard:
- Ignore it for a false positive. Matching findings are dropped before they are stored, metered or alerted on.
- Keep it here, don't alert to leave findings on the dashboard but skip Slack, Discord and webhooks.
A rule matches the finding's detection rule and either an exact request path, a path prefix such as /blog/, or the rule anywhere, in one app or every app. Rules are applied by AgentBeam when findings arrive, and creating or removing one is audit-logged. Prefer the narrowest rule that works: ignoring the credentials rule everywhere would switch off the very check you want.
What beam monitor will not do
This is the honest part.
- It cannot prevent provider-side or platform breaches. If a vendor stores your key and is breached, nothing in your logs shows it. Rotation and provider-side spend limits are the defense.
- It does not stop leaks. It watches and reports. It never blocks requests, redacts your own log files or changes your app. Fix the logging code and filter secrets at the source.
- It is log based and heuristic. It sees only what reaches the logs it reads, will miss secrets in formats it has no rule for, and some legitimate lines will match.
- It will not find a key sitting in a repository or an env var that was never logged. Use secret scanning for that.
- It has costs and requirements. It needs a connected AgentBeam workspace with App monitoring on, and findings count toward a monthly allowance.
Use it alongside a firewall or WAF, careful logging, secret scanning and regular rotation.
How AgentBeam handles this
AgentBeam handles the log side of the problem: it reads the logs your app already writes, flags credentials and attempts to reach your keys, redacts the evidence on your server, and sends only the redacted finding to the dashboard, Slack, Discord or a signed webhook. It also checks dependencies for known vulnerabilities with beam cve check, covered in Check dependencies against known CVEs in CI. On the agent side, the same redaction idea applies to what coding agents read and run; see What is AI agent monitoring. It does not manage your secrets, rotate keys for you or protect a vendor's storage. To add your first app and get its token, start at app.agentbeam.com.
Paste this to your coding agent
AgentBeam ships a skill your agent can follow. Install it, then paste the prompt below. The install command is from the App monitoring docs, and the skills are described in Let your coding agent set up AgentBeam.
npx -y @agent-beam/beam add skill agentbeam-app-monitoring -g --all-agents
Use the agentbeam-app-monitoring skill to add AgentBeam app monitoring to this
project. Find where the app runs and where it writes logs, keep BEAM_APP_TOKEN
out of the repository (use my platform's secret store), and finish by running
beam monitor test. Also search the codebase for places that log request
headers, config objects or full error objects, and list them for me without
changing anything. Show me the diff before committing.
Review what the agent proposes. A skill is text your agent follows, so read it as you would a script.
Next step
Rotate what you have to, fix the logging code that leaked it, and put a watcher on the logs so the next slip is seen in minutes. You can set up App monitoring here.
Related reading
- Monitor a running app for attacks with beam monitor
- OpenCode Console breach: claimed vs verified
- Railway breach: environment variables and AI keys
- OpenRouter breach claim: claimed vs verified
- Let your coding agent set up AgentBeam
- October 2026 attacks timeline
- What app monitoring can and cannot catch when your platform is breached
- Monitor a Railway-hosted app for attacks with beam monitor
- Your first 24 hours after a vendor breach: a rotation and monitoring runbook
- Protect an LLM feature from prompt injection and key theft with the Beam monitor SDK
Product behavior described here follows the AgentBeam App monitoring documentation as of October 23, 2026. Incident details are examples drawn from the linked posts and may have been updated since, and the CLI, rules and limits can change in later releases.