App monitoring
App monitoring for attacks in logs and dependencies
App monitoring watches a running application's logs, HTTP traffic and LLM features around the clock, and flags attacks such as injection, path traversal, reverse shells, prompt injection and attempts to extract API keys. It runs as the open-source beam CLI beside your app or as an SDK inside a Node.js or Next.js app, and it never blocks requests. Detection is heuristic, so findings are leads to review, not verdicts.
The same CLI checks your lockfiles against AgentBeam's CVE database, so one token covers both live traffic and the dependencies you ship.
What beam monitor flags
beam monitor tails log files and HTTP access logs, or piped output with --stdin, and matches lines against attack patterns. Repeats are folded per window, grouped by client IP for traffic, and floods are summarised.
- Injection
SQL, command and template injection
Payloads in query strings, bodies and logged parameters, including JNDI strings of the Log4Shell kind.
- Traversal
Path traversal and secret-file probes
Requests reaching for ../ sequences, .env files, SSH keys and other files that should never be served.
- Payloads
Serialized objects, prototype pollution and XSS
Serialized-object payloads, prototype pollution attempts and cross-site scripting markers.
- Execution
Reverse shells, piped remote code and encoded execution
Commands that fetch and run remote code, open reverse shells or hide the command in an encoding.
- Cloud
Server-side request forgery and cloud metadata
Parameters that point the server at itself, its network or an instance metadata endpoint, and schemes like gopher:// that only an attacker wants fetched.
- AI
Attacks on LLM features
Prompt injection (including text hidden in invisible Unicode or base64), forged chat markers, jailbreaks, system prompt extraction, attempts to get the app's API keys, exfiltration links in model output, and one client flooding your LLM endpoints.
- Leaks
Exposed credentials
LLM and cloud keys written to logs or model output, and a .env or .git/config file actually served. Attack-tool user agents and repeated failed sign-ins are flagged too.
How it behaves, stated plainly
- Levels
- Light (critical only), Standard (high and above), Strict (medium and above), set in the dashboard
- Per-app token
- BEAM_APP_TOKEN, shown once, stored hashed, HTTPS-only, rotatable and revocable
- Dependency check
- beam cve check . exits 2 when something meets --fail-on
- Runtime cost
- Linear-time rules, a hard CPU cap and flat memory; every release is stress-tested at agentbeam.com/releases
- False positives
- Create rule on a finding to ignore findings like it or stop their alerts, for every CLI and SDK version
How you set it up
- 01
Add the app in the dashboard
An owner or admin turns on App monitoring, adds each app (for example "bgremover") and copies its BEAM_APP_TOKEN. The token is shown once.
- 02
Run beam monitor beside the app
Point it at log files, pipe output in with --stdin, or add the SDK to a Node.js app. beam monitor test sends one test finding end to end, and beam monitor configure saves the setup so the service runs with no flags.
- 03
Route findings where your team looks
Findings are filtered per app. Webhooks post to Slack or Discord natively, or send signed JSON, each with its own minimum severity and optional app filter.
Scope of app monitoring
App monitoring needs an AgentBeam workspace with it turned on by an owner or admin. Usage counts toward a monthly allowance that depends on your plan.
Beam does
- Watch log files, HTTP access logs or piped output for attack patterns
- Send redacted findings with severity, grouped per app
- Post to Slack, Discord or signed-JSON webhooks, with a minimum severity per webhook
- Optionally ask an LLM for a second opinion on flagged lines, with your own key (OpenAI, Anthropic, Gemini, Groq and others) or Beam's model. Your key stays on your server
- Tune alerts with rules: ignore false positives, or keep findings on the dashboard without alerting
- Check prompts and model output inside your app with the SDK's prompt() and output()
- Check lockfiles against the CVE database with beam cve check, and raise CISA KEV advisories to critical
- Stream a Railway service's HTTP and app logs through the separate Beam monitor service, without changing the app
Beam does not
- Block requests, act as a WAF or change your application
- Guarantee detection: matching is heuristic, and an attacker can avoid the logs
- Upload raw log lines or full request bodies
- Treat an LLM refusal as benign: a refusal never counts as a clean result
- Let a log line talk the LLM check out of an alert: lines aimed at AI reviewers are never sent to a model
- Replace patching: dependency findings tell you what to upgrade, they do not upgrade it
Questions about app monitoring
Does app monitoring block attacks on my application?
No. It only watches. It never blocks requests, changes your app or sits in the request path, so it cannot take your service down. It tells you an attack pattern appeared; stopping it is up to your own controls.
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 accurate is the detection?
It is heuristic. Pattern matching will flag some harmless lines and miss some real attacks. Strict level surfaces more, Light only critical findings, and the optional LLM second opinion helps triage flagged lines.
Can it use my own OpenAI or Anthropic key?
Yes. beam monitor --llm openai (or anthropic, gemini, groq, openrouter, mistral and others) uses the key already in that server's environment, and the SDK does the same with createAppMonitor({ llm: "openai" }). The key goes only to that provider; AgentBeam receives the verdict, never the key.
What happens to my app if AgentBeam is down?
Nothing. Reports are sent in the background with a 5-second timeout and back off while AgentBeam is unreachable; requests never wait on it. Detection has a hard CPU cap and bounded memory either way.
How does the CVE check work in CI?
beam cve check . reads lockfiles for npm, yarn, pnpm, bun, pip, poetry, uv, Go, Cargo, composer, Bundler, NuGet, Gradle, mix, Swift Package.resolved and GitHub Actions workflows. It sends only package names and versions, and exits 2 when a finding meets --fail-on. In CI it authenticates with BEAM_APP_TOKEN.
Can a coding agent set this up for me?
Yes. Install the bundled skills with npx @agent-beam/beam add skill agentbeam-setup -g --all-agents, and likewise agentbeam-app-monitoring. Beam scans a skill before installing it.
Related
- Monitor a running app with beam monitorTokens, levels, webhooks and dependency checks, end to end.
- Check dependencies against known CVEs in CIFail a build on vulnerable packages with beam cve check.
- Let your coding agent set it upThe agentbeam-setup and agentbeam-app-monitoring skills.
- Monitor an app hosted on RailwayRun beam monitor as a separate service so the app stays untouched.
- API keys in logs and env varsHow keys leak, a rotation order, and the credentials-in-logs rule.
- What to do after an attackThe first 15 minutes, and a playbook for each kind of finding.
- First 24 hours after a vendor breachA rotation and monitoring runbook for OpenCode- and Railway-style incidents.
- What app monitoring can and cannot catchAn honest look at what you still control when your platform is breached.
- Protect an LLM feature in your appCheck prompts and replies for injection, key requests and exfiltration links.
- A leak joke, and the real attacks behind itHow to tell a joke or false claim from a real breach, and what to rotate.
- CVE databaseBrowse the advisories that beam cve check matches against.
- AI agent monitoringThe same idea for the coding agents that build your app.
Know when someone is probing your app
Add an app, run beam monitor beside it, and get redacted findings in Slack, Discord or your own webhook. It works whether or not you already have an AgentBeam account.