After an attack: responding to a finding

A finding means Beam saw something that matches an attack pattern. It doesn't prove the attack worked, and it doesn't prove it didn't. This guide walks through the first hour after an alert, then gives a playbook for each kind of finding. Work through it in order; skipping to cleanup before you know what happened is how evidence gets lost.

The first 15 minutes

Open the finding. The alert's Open in Beam link goes to App monitoring. Note the app, severity, time, how many times it repeated (×N), and the redacted evidence.
Decide whether it reached your code. Did the request get a 2xx response? Did the line come from your app's own log, or only the access log? A blocked or 404'd probe is noise; a 200 on a payload is not.
Check for more. Filter App monitoring by the same app, then by severity. Search your own logs for the source IP and the request path around that time. One finding is often the visible tip of a scan.
Pick a lead. One person owns the incident and keeps notes: times, what was checked, what was changed. Post in the channel the alert went to, so others don't duplicate work.
Preserve evidence before changing anything. Copy the relevant logs off the server and snapshot the host or container if compromise is possible. Restarting, redeploying or rotating keys first can destroy the trail.

If you can't rule out that the attack worked, treat it as if it did and contain first.

Decide: real, noise, or expected

What you find	What to do
A real attack that may have worked	Follow the playbook below for its category. Escalate.
A real attack that failed (blocked, 4xx, patched)	Mark it reviewed. Consider blocking the source and tightening the rule that caught it.
Your own traffic: a scanner you run, a test, a health check	Use Create rule → Ignore on the finding, scoped to its path or app, so it stops alerting.
Legitimate but noisy (a known crawler, an internal tool)	Create rule → Keep it here, don't alert: it stays on the dashboard but out of alert workflows.

Rules only affect future findings, so they never hide an attack that already happened. Every rule is audit-logged and can be removed.

Attacks in requests

SQL, command and template injection, SSRF, path traversal, Log4Shell and cross-site scripting payloads in URLs and query strings.

Check the response. A 200 with a large or unusual body after an injection payload is the signal that matters. Compare against normal responses for that route.
Find the code path. Locate the handler for the request path in the evidence and check how it uses the parameter: string-built SQL, shell calls, template rendering, server-side fetches of user-supplied URLs, file paths built from input.
Contain. Block the source IP or rate-limit at your load balancer or WAF. If the route is vulnerable and you can't fix it now, disable it or put it behind authentication.
Fix. Parameterize queries, avoid shells, allow-list URLs and file paths. Deploy, then re-send the payload from the evidence against staging to confirm.
For SSRF, check whether the server reached cloud metadata (169.254.169.254) or internal services. If it could have, rotate the instance's cloud credentials.

Attacks on AI features

Prompt injection, hidden instructions, jailbreaks, system prompt extraction, exfiltration links in model output, and floods from one sender.

Read what the model did next. The danger isn't the prompt; it's what the model was allowed to do afterwards. Check tool calls, retrieved documents, emails sent or records changed in that session.
Check output. An exfiltration link or leaked credential in a reply means data may already have left. Find whether that reply was rendered or clicked.
Contain. Disable tools the feature doesn't strictly need, block the sender, and if the system prompt or a canary leaked, rotate anything it contained.
Fix. Treat retrieved content as untrusted, require confirmation before actions with side effects, and render model output as plain text where links aren't needed. beam.prompt() and beam.output() in the SDK return what they matched so your app can refuse.
Denial of wallet: cap tokens per user and per minute, and check your LLM provider's usage for the spike.

Signs of compromise

Reverse shells, piped remote code (curl … | sh), web shells and cloud metadata access. These are critical for a reason: they suggest an attacker is already running code.

Isolate the host. Take it out of the load balancer and restrict outbound traffic. Don't shut it down yet if you need memory or process evidence.
Capture state. Running processes, network connections, recently changed files, cron jobs, new users and SSH keys.
Rotate everything the host could read. Environment variables, database credentials, cloud keys, API tokens, and the app's BEAM_APP_TOKEN (Rotate token in App monitoring settings).
Rebuild, don't clean. Redeploy from a known-good image or commit onto fresh infrastructure. A cleaned host can keep a backdoor you didn't find.
Find the way in. Look for the request or dependency that preceded the first sign. That's the bug to fix before the rebuilt host takes traffic.

Bring in your security team or an incident response provider at this point, and see when to escalate.

Exposed credentials

API keys, cloud keys, private keys and tokens written to logs or model output, and secret files like .env served to anyone who asked.

Revoke and rotate now, at the provider, not just in your config. A key in a log has been copied wherever those logs go.
Check the provider's logs for use of the old key since it was exposed: unfamiliar IPs, regions, or API calls.
Stop the leak. Remove the logging statement or redact the field; for a served secret file, block the path and move the file out of the web root.
Purge copies from log storage, your log vendor and backups where you can.
For a served .env or .git, assume every secret in it is exposed and rotate them all.

Reconnaissance

Attack-tool user agents, probes for .env, .git and credential files, and bursts of failed sign-ins.

Recon on its own usually doesn't need an incident. It does tell you someone is looking.

Check that the probes failed (404 or 403). A 200 on /.env or /.git/config is an exposed credential, not recon.
For failed sign-in bursts, confirm rate limiting and lockouts work, and check whether any targeted account then signed in successfully.
Block or slow the source if it's persistent, and watch for an attack from the same IP in the following hours.
Quiet the noise. If every bot on the internet hits a path you know is safe, a "don't alert" rule keeps it on the dashboard without paging anyone.

Vulnerable dependencies

Known advisories in your lockfiles from beam cve check. Ones on CISA's Known Exploited Vulnerabilities list are critical.

Check reachability. Is the vulnerable function used, and is it reachable from input an attacker controls?
Upgrade to the fixed version shown in the finding, run your tests, deploy, then run beam cve check . again to confirm it's clear.
If you can't upgrade yet, apply the advisory's workaround or block the vulnerable route, and set a date to finish.
For actively exploited ones, search your request findings and logs for exploitation since the dependency was added, not just since the advisory.

Device alerts

Beam was tampered with, stopped, uninstalled or logged out on a teammate's machine.

Ask the person first. Most are upgrades, reinstalls or someone switching machines. Confirm through a channel other than the one that machine uses.
If they didn't do it, treat the machine as possibly compromised: review its recent agent sessions and risks in Beam, revoke the device under Agents, and follow your endpoint process.
Repeated stops by the same person are a policy conversation, not just a technical one.

Recover and close out

Confirm the fix. Replay the attack against staging and check no new findings arrive for it in production.
Mark findings reviewed in App monitoring and Risks, so the queue reflects what's still open.
Tune alerting. Add a rule for anything that was noise, and an alert workflow if this should have paged someone sooner.
Write it up within a week. What happened, how it was found, how long each step took, and what changes so it can't happen the same way again. Blame the gap, not the person.

When to escalate

Escalate to your security lead, and through them to legal or leadership, when:

an attacker ran code on a server, or you can't rule it out;
customer or personal data may have been read, changed or taken;
a credential was exposed and the provider shows it was used;
payment, health or other regulated data is involved.

Data protection laws can set short deadlines once you're aware of a personal data breach (GDPR's is 72 hours to notify the supervisory authority). Start that clock conversation early rather than after cleanup.

Beam records what its rules matched and what your team did in the dashboard, and every change is in the audit log. It does not see raw log lines, full requests or what happened inside your app, so your own logs remain the primary evidence.