Monitor a Running App for Attacks with beam monitor: Logs, Tokens, Webhooks and Dependency Checks

beam monitor watches a running application's log files and HTTP access logs, around the clock, and flags attacks as they appear. It is the newest part of the open-source beam CLI, and it extends AgentBeam from the coding agents that build your software to the application that results. This post explains what it detects, what leaves your server, how per-app tokens and webhooks work, and how to get a first finding into Slack in a few minutes. If you only want the one-page summary, see the app monitoring solution page.

Why watch the app and not only the agent

Most of what AgentBeam has covered so far is the agent side: what Claude Code, Codex and similar tools run, read and write on a developer machine. That part has not changed. But the code those agents write ends up in a service, and that service gets scanned and probed from the first hour it is public. Anyone who has tailed an access log on a new server has seen requests for .env, ../../etc/passwd and /wp-login.php within minutes.

The useful question is not whether probing happens. It does. The useful question is whether any of it contains something worth acting on: a payload that matches a known injection shape, a request aimed at your cloud metadata endpoint, a credential that your own code printed into a log line. App monitoring exists to surface those lines so a person looks at them, instead of leaving them buried in gigabytes of routine traffic.

It is also a good fit for small teams and solo builders, which is where much AI-assisted development happens. You may not run a SIEM or a managed WAF. You probably do have log files.

What beam monitor flags

beam monitor reads application log files and HTTP access logs, or piped output when you pass --stdin, and matches lines against a set of attack patterns. The categories are:

• Injection: SQL, command and template injection, plus JNDI strings of the kind used against Log4Shell.
• File access: path traversal and probes for secret files such as .env or key material.
• Payloads: serialized-object payloads, prototype pollution and cross-site scripting.
• Execution: reverse shells, piped remote code (curl ... | sh shapes) and encoded execution.
• Cloud: requests that reach for cloud-metadata endpoints.
• Leaks and abuse: credentials written to logs, prompt injection in logged prompts, attack-tool user agents and repeated failed sign-ins.

Two of these are worth a closer look because they are easy to overlook. Credentials in logs are not an attack in the usual sense, but they are a frequent root cause of breaches: a debug statement prints an Authorization header, and the log shipper copies it into three other systems. Prompt injection in logged prompts matters if your product passes user text to a model and you log the prompt. A line that tells the model to ignore its instructions is something you want to see.

What it does not do

Detection is heuristic. A pattern match tells you a line looks like an attack, not that an attack succeeded. An attacker whose traffic never reaches your logs, or who writes a payload your patterns do not describe, will not be flagged. That is the nature of log-based detection, and it is why this is a watching tool and not a protection layer. Keep your WAF, your input validation and your patching. Think of beam monitor as the smoke alarm that tells you something is worth a look.

What leaves your server

This is the question security teams ask first, so here is the exact boundary.

Raw log lines stay on the server. What the CLI sends is a finding: the rule that matched, a severity, the file it came from, a count, and a redacted excerpt capped at 600 characters. Redaction runs before anything is sent, so a credential in a flagged line does not travel with it.

Noise control happens on your side too. Repeats of the same finding are folded within a window and shown with a count. For web traffic, findings are grouped by client IP, so one scanner hammering you with two thousand requests reads as one finding with a count and a source, not two thousand alerts. If a flood arrives, it is summarised rather than forwarded line by line.

Levels: how much noise you want

You choose how sensitive the monitor is in the dashboard, not in a config file on the server:

Because the level lives in the dashboard, you can raise or lower it while the monitor keeps running, without redeploying anything.

Per-app tokens

App monitoring is organised around apps. An owner or admin opens the App monitoring page in the dashboard, adds an app by name (for example bgremover), and receives a token for it, exposed to the CLI as BEAM_APP_TOKEN.

The token is designed to be a low-risk thing to put on a server:

• It is shown once, and stored hashed, so it cannot be read back later.
• It is least-privilege: it is only accepted by the App monitoring endpoints, not by the rest of the workspace API.
• It works over HTTPS only.
• It can be rotated or revoked at any time.
• Each app has per-app rate limits, and token use is audit-logged.

Per-app tokens also give you filtering for free. Findings are filtered per app in the dashboard, and a webhook can be limited to specific apps, so the team that owns the billing service does not get alerts about the image service.

Webhooks: sending findings where people look

Findings appear in the dashboard, but most teams want them in chat. Webhooks support three shapes:

• Slack and Discord have native formats, so you paste the channel webhook URL and get a readable message.
• Anything else receives signed JSON. Each request carries an X-Beam-Signature header, an HMAC-SHA256 over timestamp.body, so your receiver can verify that Beam sent it and that it is fresh.
• Each webhook has its own minimum severity, so you can send only critical findings to a pager channel and everything at Standard or above to a quieter one.

If you write your own receiver, verify the signature before trusting the body. Compute the HMAC over the timestamp, a dot and the raw request body with your webhook secret, compare it in constant time, and reject requests whose timestamp is old.

Setting it up

You need an AgentBeam workspace with App monitoring turned on by an owner or admin. Usage counts toward a monthly allowance that depends on your plan. The getting-started link works whether or not you already have an account.

1. In the dashboard, open App monitoring, add your app, and copy its token.
2. Install the CLI and set the token on the server that runs your app:

npm install -g @agent-beam/beam
export BEAM_APP_TOKEN="<token from the dashboard>"

3. Start the monitor next to your app. If your logs go to standard output, pipe them in:

node server.js 2>&1 | tee -a app.log | beam monitor --stdin

For log files, point beam monitor at them directly. The App monitoring docs list the exact options.

4. Confirm the whole path works with one test finding, then check the app, level and usage:

beam monitor test
beam monitor status

beam monitor test sends a single test finding end to end, through the same route a real finding takes, so you find out about a wrong token or a blocked outbound connection before an attack does. beam monitor status shows which app the token belongs to, the level in effect and your usage.

Hosted on Railway

If your app runs on Railway, you do not have to touch the app. The beam-cli repository includes a separate Beam monitor service under deploy/railway-monitor. It streams a Railway service's HTTP logs and application logs into beam monitor, so the monitored app stays exactly as it was.

An optional second opinion from an LLM

Pattern matches produce false positives. For flagged lines you can ask a model for a second opinion. This is optional, and it works in chunks with a small model by default. There are two ways to use it:

• Your own model, from the CLI. Set the BEAM_LLM_* environment variables to point at any OpenAI-compatible endpoint, including a local Ollama or vLLM server. Flagged lines then go to a model you control.
• Beam's model, from the dashboard. Turn it on in the dashboard if you would rather not run one.

One design choice matters here: a refusal never counts as benign. If the model declines to analyze a line, which can happen when the line contains attack text, the line stays flagged. A "no" from the model is not treated as "safe".

Checking dependencies with the same token

Attacks in logs tell you what is hitting you today. Dependencies tell you what is waiting to be exploited. The same CLI reads your lockfiles and compares the packages against AgentBeam's CVE database:

beam cve check .

It understands npm, yarn, pnpm and bun lockfiles, pip, poetry, uv and Pipfile, go.mod, Cargo, composer, Gemfile, NuGet, Gradle, mix, Swift Package.resolved, and GitHub Actions workflows. It sends only package names and versions, never your source. It exits with code 2 when a finding meets --fail-on, which makes it usable as a CI gate with BEAM_APP_TOKEN set. Advisories listed in CISA's Known Exploited Vulnerabilities catalog are raised to critical in monitor findings. The full CI walk-through is in Check dependencies against known CVEs in CI, and you can browse the advisories themselves in the CVE database.

A sensible first week

If you are rolling this out for the first time, a gradual path avoids alert fatigue:

1. Day one: run beam monitor test, then start the monitor at Standard level with only the dashboard as the destination. Look at the first day of findings with your own eyes.
2. Days two and three: add one webhook to a team channel at a high minimum severity. Tune out anything you decide is routine, such as a vulnerability scanner you run yourself.
3. End of week: move to Strict for a day to see what medium findings look like, and decide whether you want them. Add beam cve check . to CI.

Treat every finding as a lead. A flagged SQL injection string in a request that returned 404 is information about who is probing you. The same string followed by a 200 and an unusual response size deserves an immediate look at the code behind that route.

Related reading

• App monitoring solution page for the short version.
• Check dependencies against known CVEs in CI.
• Let your coding agent set it up with the bundled skills.
• What is AI agent monitoring? for the agent-side counterpart.
• The CLI source is on GitHub under AGPL-3.0, and the package is @agent-beam/beam on npm.
• Monitor a Railway-hosted app for attacks with beam monitor
• 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
• Protect an LLM feature from prompt injection and key theft with the Beam monitor SDK

Also new in the CLI: beam judge lets agent hooks get an allow, review or deny second opinion from any OpenAI-compatible model or from your own HTTP decision service, alongside TypeSafe Jev. It is off by default and observes unless you pass --mode enforce.

Frequently asked questions

What does beam monitor do?

It watches a running application's log files and HTTP access logs, or piped output when you pass --stdin, and flags attack patterns such as SQL, command and template injection, JNDI strings, path traversal, XSS, reverse shells and credentials written to logs. Findings are redacted and sent to your AgentBeam workspace.

Does beam monitor block attacks?

No. It only watches. It never blocks requests, changes your application or sits in the request path, so it cannot cause an outage. Blocking stays with your firewall, WAF or application code.

Do my raw logs leave my server?

No. Raw log lines stay on the server. Only redacted findings are sent: the rule, severity, file, a count and a redacted excerpt of at most 600 characters.

How reliable is the detection?

It is heuristic. Pattern matching flags some harmless lines and misses attacks that never reach a log. Use the monitoring level to tune noise, and the optional LLM second opinion to triage flagged lines.

What is BEAM_APP_TOKEN?

A per-app token created on the App monitoring page of the dashboard. It is shown once, stored hashed, only accepted by the App monitoring endpoints over HTTPS, and can be rotated or revoked. Each app gets its own.

Do I need an AgentBeam account?

You need an AgentBeam workspace with App monitoring turned on by an owner or admin. The getting-started link works whether or not you already have an account, and usage counts toward a monthly allowance that depends on your plan.

Details are accurate as of October 23, 2026. App monitoring availability and allowances depend on your plan, and detection is heuristic.