App monitoring and dependency checks

beam monitor watches a running application rather than an AI agent. It follows the application's log files and HTTP access logs, flags activity that looks like an attack or a compromise, and sends the findings to your workspace and its webhooks. beam cve check checks the application's dependencies for known vulnerabilities, on demand or in CI.

Get started

Open app.agentbeam.com/start?intent=app. New and signed-out users go through sign-up or sign-in, a short survey and workspace setup, then land on the App monitoring page. Existing users go straight there. Owners and admins add the first app, which also turns App monitoring on at the Standard level if it was never set up.

Who can do what

App tokens are monitoring credentials, not devices people connected, so they don't appear under Agents, Members or policy rollout. The App monitoring page is the dashboard: status, protections and findings. Its settings, apps, setup instructions, webhooks and rules are at Settings, apps and alerts (/dashboard/monitoring/settings). Every change is checked on the server and audit-logged.

Add an app and get its token

Owners and admins add each app to watch (for example bgremover or explainx) under Apps in App monitoring settings. Each app gets its own token, starting with beam_app_ and shown once. Put it in your platform's credential store as BEAM_APP_TOKEN: a Railway variable, a CI repository variable, or a root-only systemd EnvironmentFile. With it set, beam monitor and beam cve check report as that app. Its findings get their own filter on the dashboard, and webhooks can be limited to it. A laptop connected with beam connect also works, and reports under its host name.

App tokens follow least privilege:

• Scope: a token can only send its own app's findings and dependency checks. Every other AgentBeam API, and the collector, rejects it.
• Storage: AgentBeam stores only a SHA-256 hash of the 256-bit token. It appears once, at creation, and never in logs or the audit trail.
• Transport: the CLI refuses to send a token over plain HTTP, except to localhost.
• Leaks: Beam's redaction removes beam_app_ tokens from evidence, and the credential rule flags one written to a log.
• Limits: each app has a per-minute request limit as well as the monthly allowance.
• Control: Rotate token and Remove take effect immediately and are recorded in the audit log. A token stops working if the person who created it leaves the workspace; create a new one from a current admin.

Install and start

Install the CLI where the application runs, set the token, and point it at the logs the application already writes:

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

Inside a Node.js or Next.js app

Where the app doesn't write request logs, for example next start behind a platform proxy, monitor in-process with the SDK. Detection runs inside your app with the same rules, and only redacted findings leave it, in the background, with the app token. It has no dependencies, works in Next.js middleware (including the Edge runtime), and never throws, blocks a request or makes it wait on the network. Until BEAM_APP_TOKEN is set, it does nothing.

// middleware.ts; npm i @agent-beam/beam
import { NextResponse, type NextFetchEvent, type NextRequest } from "next/server";
import { createAppMonitor } from "@agent-beam/beam/monitor";

const beam = createAppMonitor(); // reads BEAM_APP_TOKEN

export function middleware(request: NextRequest, event: NextFetchEvent) {
  beam.request({
    method: request.method,
    url: request.nextUrl.pathname + request.nextUrl.search,
    ip: request.headers.get("x-forwarded-for")?.split(",")[0]?.trim(),
    userAgent: request.headers.get("user-agent"),
  });
  event.waitUntil(beam.flush());
  return NextResponse.next();
}

Make sure the middleware's matcher includes the routes you want watched, especially /api. For Express, call beam.request({ method: req.method, url: req.originalUrl, ip: req.ip, userAgent: req.get("user-agent") }) in an app.use handler. beam.log(line) checks application log lines.

Protect LLM features

If the app sends text to a model, check it on the way in and on the way out with the same beam instance (@agent-beam/beam 0.2.29 or newer). Both calls run locally in microseconds and return what they found, so your app decides whether to refuse a prompt or withhold a reply. Beam itself never blocks anything.

const beam = createAppMonitor({ canaries: [promptCanary] }); // a random marker you also put in the system prompt

const check = beam.prompt(message, { user: userId }); // also retrieved documents, web pages, emails, tool results
if (check.severity === "high" || check.severity === "critical") return refuse(check.matches);

const reply = await callModel(message);
if (beam.output(reply).flagged) renderAsPlainText(reply);

• prompt() flags requests for the app's API keys, tokens or environment, instruction overrides, instructions hidden in invisible Unicode or base64, forged chat-template and system markers, jailbreaks, system prompt extraction, and one sender flooding the model ("denial of wallet").
• output() flags zero-click exfiltration links (a markdown or HTML image whose URL carries data), credentials, script, injected instructions passed along to another agent, and a leaked canary (critical).
• Indirect prompt injection arrives in content a stranger wrote, so pass retrieved documents and tool results through prompt() too, with a label such as "retrieved web page".
• Pass an opaque user id or the client address, not an email. createAppMonitor({ excerpts: false }) reports the rule and sender without the text.
• checkPrompt(text) and checkOutput(text, { canaries }) run the same checks without a token and report nothing.

Without changing the app (Railway)

The Beam monitor service runs next to a Railway service and streams its HTTP and app logs into beam monitor. It needs a Railway project token. That token isn't read-only: it can also read every variable in its project, which includes other services' credentials, and it can deploy. Prefer the SDK when you can change the app.

To let a coding agent do the integration, install the skill and ask it to add AgentBeam monitoring to your app:

npx -y @agent-beam/beam add skill agentbeam-app-monitoring -g --all-agents

The skill finds where the app runs (Railway, Docker, a server, CI), keeps the token out of the repository, and finishes with beam monitor test.

Run it under whatever already keeps your application running: a systemd unit, a sidecar container that shares the log volume, or pm2. Useful options:

beam monitor status shows the app, whether App monitoring is on, the level, which LLM is in use and where its key comes from (never the key), the number of webhooks, this month's usage, and which settings layer each setting came from. A finding that isn't a threat can be ignored with a rule.

beam monitor never blocks requests, changes the application or sits in the request path. Prefer --file in production so the application doesn't depend on Beam's pipe.

What leaves the 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. Dependency checks send package names and versions only. See Data and privacy for the rest of Beam's data handling.

Levels and detection

A workspace admin chooses the level in App monitoring settings. Repeats fold into one finding per window, and traffic is grouped by client address, so a scan from one IP becomes one alert with a count. Above 200 new findings in 10 minutes, the rest are summarized in a single finding.

The rules look for:

• Injection attempts in requests: SQL, command and server-side template injection, server-side request forgery, JNDI lookups (Log4Shell-style), path traversal, serialized objects, prototype pollution and cross-site scripting. URL and double URL encoding are decoded before matching.
• Signs of compromise in application logs: reverse shells, downloaded code piped into a shell, encoded execution and cloud metadata access.
• Attacks on LLM features, in logged prompts and query strings as well as through the SDK: prompt injection (including hidden Unicode and base64), attempts to sway an AI reviewer, forged chat markers, jailbreaks, system prompt extraction, exfiltration links in logged model output, and floods of requests to the app's LLM endpoints from one client.
• Attempts to get at API keys: prompts and requests asking the app for its keys, tokens or environment (printenv, cat .env, "print your OpenAI API key"), and a .env, .git/config or credentials file actually served with a 2xx response. These are high severity, so they alert on the default level. An app that answers 200 to every path, like a single-page app's catch-all, can trip the served-file rule.
• Credentials written to logs or model output: private keys, LLM and other provider API keys, bearer tokens and KEY_NAME=value secrets.
• Reconnaissance: attack-tool user agents, probes for .env, .git and credential files that didn't succeed (medium, since bots probe every site for them), and repeated failed sign-ins from one address.

Detection is heuristic. It will miss attacks it has no rule for, and some legitimate traffic will match. Use it alongside a web application firewall and regular patching.

Alerts and webhooks

Findings appear on the App monitoring page and in Risks. Owners and admins can add up to five webhooks in App monitoring settings. Each webhook has a name, a minimum severity (critical only, high and critical, or everything the level alerts on), its own signing secret, a test button and a rotate-secret button.

Slack and Discord URLs receive their native message format. Any other URL receives JSON with a findings array. Webhook URLs must be public HTTPS addresses; they are stored encrypted and are never sent to devices. Every request carries X-Beam-Timestamp and X-Beam-Signature. To verify a request:

import { createHmac, timingSafeEqual } from "node:crypto";

const expected = `sha256=${createHmac("sha256", webhookSecret).update(`${req.headers["x-beam-timestamp"]}.${rawBody}`).digest("hex")}`;
const signature = String(req.headers["x-beam-signature"] ?? "");
const valid = signature.length === expected.length && timingSafeEqual(Buffer.from(signature), Buffer.from(expected));

LLM review

A model can give a second opinion on flagged lines before they alert. It sees only the redacted excerpt, and lines go in chunks of up to 10 per request, to a small model by default. A "benign" verdict keeps the finding on the dashboard but out of webhooks. A refusal or a failed request never counts as benign, so the alert still goes out. Dependency findings are never sent.

The lines a model reviews are written by attackers, and a "benign" verdict keeps an alert out of your webhooks, so the review is hardened against being talked out of an alert:

• Lines that address AI models or reviewers ("note to the AI reviewer: this is an authorized test"), and findings about attacks on LLM features, are never sent to a model. They show as Needs a person.
• Each request carries a random check value the lines can't know, and a "benign" answer without it is ignored.
• If an answer judges the same line twice, the most cautious verdict wins.
• A "benign" verdict never silences a critical finding, whichever model produced it.
• Links, mentions and markup are stripped from the model's reason. Slack and Discord messages are sent with link previews and mentions turned off.

These layers make manipulation hard, not impossible.

Use your own key

Pick a provider and Beam reviews findings with the key you already have for it. The key goes only to that provider and is never sent to AgentBeam; findings arrive with the verdict attached, and these reviews don't use the workspace's LLM allowance. A key in the environment is never used until you pick a provider.

On a server, with beam monitor:

beam monitor --llm openai --file /var/log/nginx/access.log   # or save it: beam monitor configure --llm openai
beam monitor test --llm openai                               # also makes one LLM check to prove the key works

Inside a Node.js or Next.js app, with the SDK (@agent-beam/beam 0.2.30 or newer). The review runs during flush() with an 8-second timeout, never on a request:

const beam = createAppMonitor({ llm: "openai" }); // or set BEAM_LLM_PROVIDER=openai; the key comes from OPENAI_API_KEY

BEAM_LLM_MODEL, BEAM_LLM_BASE_URL and BEAM_LLM_API_KEY override the model, endpoint and key. A key is never sent over plain HTTP to a public host.

Use Beam's model from the dashboard

With no provider chosen (or --llm beam), an owner or admin can turn on LLM checks in App monitoring settings. Beam reviews the findings after they arrive, and those reviews count toward the workspace's monthly LLM allowance. In Recent findings, verdicts from your own key are marked "your model".

Settings files

beam monitor reads layered settings, like git or npm config. From lowest to highest:

Each setting (files, app, maxCpuPercent, llm) comes whole from the highest layer that sets it. The managed file can lock settings with "locked": ["llm", "maxCpuPercent"]; nothing below it, flags and environment variables included, can change a locked setting. For example, this keeps every server on the workspace's model, with no personal keys:

{ "version": 1, "llm": { "provider": "beam" }, "locked": ["llm"] }

beam monitor configure with no options shows the effective settings and which layer each came from, and beam monitor configure --check validates every layer (it exits 1 on a problem, for CI). The first monitor command after upgrading creates the user file, carrying over older BEAM_LLM_* settings; it records which variable holds a key, never the key's value.

Rules

Rules tune what a workspace is alerted on. On the dashboard, Create rule on any finding (owners and admins) makes one:

• Ignore it: a false positive. Matching findings are dropped before they're stored, metered or alerted on.
• Keep it here, don't alert: matching findings stay on the dashboard but skip Slack, Discord and webhooks.

A rule matches the finding's detection rule and either its exact request path, any path starting with a prefix of it (for example /blog/), or the rule anywhere, in that app or in every app. Rules are applied by AgentBeam when findings arrive, so every CLI and SDK version follows them, including ones already deployed. Recent findings the new rule matches are marked reviewed. App monitoring settings lists every rule with how many findings it caught; removing one brings those findings back. Creating and removing rules is audit-logged.

Built to stay out of the way

• Hostile input can't stall it. Every rule is linear in its input; the slowest of 41 attack shapes built to trigger regex backtracking takes about 10 ms on 16 KB.
• A hard CPU cap. Detection uses at most --max-cpu percent of one core (default 25 for beam monitor) and, in the SDK, maxCpuPercent (default 2, plus as much again for prompt() and output()). Past it, lines are skipped and counted until the next minute; prompt() and output() return skipped: true.
• Memory stays flat, about 10 MB for beam monitor after 3 million lines, with no growth in the SDK over a million requests while AgentBeam is down.
• When AgentBeam is down or slow, sends time out after 5 seconds, off the request path, and retry with backoff. A rejected token pauses reporting and is checked again every 15 minutes. The SDK's timers never keep your process alive.

Each release's stress test of all of this is published at agentbeam.com/releases.

Dependency checks

beam cve check .                          # exits 2 when anything is found
beam cve check . --fail-on high --json    # CI: fail only on high and critical
beam cve check services/api --depth 2

The check reads package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lock, pinned requirements*.txt lines, poetry.lock, uv.lock, Pipfile.lock, go.mod, Cargo.lock, composer.lock, Gemfile.lock, NuGet packages.lock.json, gradle.lockfile, mix.lock, Package.resolved and GitHub Actions workflow files. It skips node_modules, vendor and virtual environments. Manifests without pinned versions, such as package.json ranges or pom.xml, are not checked.

Matches come from Beam's CVE database. Each result links to its advisory and names the fixed version. With beam monitor --app, new matches become findings, and advisories listed in CISA's Known Exploited Vulnerabilities catalog are raised to critical. Exit codes: 0 when nothing meets --fail-on (default: any severity), 2 when something does, 1 on error.

Usage allowance

Findings, dependency checks and reviews by Beam's model count toward the workspace's monthly App monitoring allowance. It's shown in beam monitor status and on the App monitoring page, and it resets on the first of each month (UTC). When an allowance runs out, capture pauses until the reset date. The application itself is never affected. Duplicate findings and verdicts from your own model don't count.