An alert says your app was attacked. What you do in the next hour decides whether it stays a log line or becomes an incident. This is the incident response playbook we wrote for App monitoring findings, adapted for anyone who runs a web app: the first 15 minutes, how to tell a real attack from noise, and a step-by-step response for each attack type. The same guide lives in the AgentBeam docs, and every App monitoring finding and alert now links to its section.
| Question | Short answer |
|---|---|
| Does an alert mean I was breached? | No. It means something matched an attack pattern. Check whether it reached your code |
| What do I do first? | Confirm the response, save evidence, pick one person to lead |
| Should I restart or redeploy right away? | Not before copying logs and snapshotting the host, unless it is actively spreading |
| A key leaked into a log. Now what? | Rotate it at the provider now, then check the provider's logs for use |
| The server may be compromised. Clean or rebuild? | Rebuild from a known-good image, after rotating every secret it held |
| When do I escalate? | Code execution, personal data, a used credential, or regulated data |
The first 15 minutes after an attack alert
Most mistakes in incident response happen in the first quarter hour, usually by fixing things before anyone knows what happened. Work through these in order.
- Open the finding. Note the app, severity, time, how many times it repeated and the evidence. In AgentBeam, the alert's Open in Beam link goes there and What to do goes to the matching section of this playbook.
- 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. Search your logs for the same source IP and 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 nobody duplicates work.
- Preserve evidence before changing anything. Copy the relevant logs off the server and snapshot the host or container if compromise is possible.
If you cannot rule out that the attack worked, treat it as if it did and contain first.
Real attack, noise, or expected traffic?
| What you find | What to do |
|---|---|
| A real attack that may have worked | Follow the playbook for its type below and escalate |
| A real attack that failed (blocked, 4xx, already patched) | Mark it reviewed, block the source, tighten the rule that caught it |
| Your own traffic: a scanner you run, a test, a health check | Ignore it with a rule scoped to its path or app so it stops alerting |
| Legitimate but noisy, like a known crawler | Keep it on the dashboard but out of alerts |
In AgentBeam, the last two are Create rule on the finding. Rules only affect future findings, so they never hide an attack that already happened, and every rule is audit-logged.
Playbook: injection attacks in requests
SQL, command and template injection, SSRF, path traversal, Log4Shell-style JNDI strings 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 it against normal responses for that route.
- Find the code path. Locate the handler for the request path 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 or rate-limit it at your load balancer or WAF. If the route is vulnerable and you cannot fix it now, disable it or put it behind authentication.
- Fix and verify. Parameterize queries, avoid shells, allow-list URLs and paths, then replay the payload from the evidence against staging.
- For SSRF, check whether the server reached cloud metadata at
169.254.169.254or internal services. If it could have, rotate the instance's cloud credentials.
A WAF block is containment, not a fix. During PHP2Shell, Cloudflare's managed rules blocked attack traffic before the patch existed, but the origin was still vulnerable until PHP was updated.
Playbook: prompt injection and 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 is not the prompt but what the model could do afterwards. Check tool calls, retrieved documents, emails sent or records changed in that session.
- Check the output. An exfiltration link or a leaked credential in a reply means data may already have left. Find out whether that reply was rendered or clicked.
- Contain. Disable tools the feature does not strictly need, block the sender, and rotate anything a leaked system prompt contained.
- Fix. Treat retrieved content as untrusted, require confirmation before actions with side effects, and render output as plain text where links are not needed. We covered checks for both directions in protecting an LLM feature from prompt injection and key theft.
- Denial of wallet: cap tokens per user and per minute, and check your model provider's usage for the spike.
Playbook: a compromised server (shells, piped scripts, web shells)
Reverse shells, curl … | sh, web shells and cloud metadata access mean an attacker may already be running code. Treat these as critical.
- Isolate the host. Take it out of the load balancer and restrict outbound traffic. Do not 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 own monitoring token.
- Rebuild, do not clean. Redeploy from a known-good image or commit onto fresh infrastructure. A cleaned host can keep a backdoor you did not find.
- Find the way in. Look for the request or dependency that came just before the first sign. That is the bug to fix before the rebuilt host takes traffic.
Bring in your security team or an incident response provider at this point.
Playbook: leaked API keys and credentials
Keys and tokens written to logs or model output, and secret files like .env served to anyone who asks.
- Revoke and rotate now, at the provider, not only in your config. A key in a log has been copied everywhere 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
.envor.git, assume every secret in it is exposed and rotate them all.
For the order to rotate in and how keys end up in logs in the first place, see API keys in logs and env vars. If the leak was your platform's, not yours, the first 24 hours after a vendor breach runbook is the better starting point.
Playbook: reconnaissance and probing
Attack-tool user agents, probes for .env, .git and credential files, and bursts of failed sign-ins. Recon alone rarely needs an incident, but it tells you someone is looking.
- Check that the probes failed (404 or 403). A 200 on
/.envor/.git/configis a leaked 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 persistent sources, and watch for an attack from the same IP in the following hours.
- Quiet the noise. If every bot hits a path you know is safe, keep those findings on the dashboard but out of your alerts.
Playbook: a vulnerable dependency
Known advisories in your lockfiles. Ones on CISA's Known Exploited Vulnerabilities catalog are the urgent ones.
- Check reachability. Is the vulnerable function used, and can attacker-controlled input reach it?
- Upgrade to the fixed version, run your tests, deploy, and re-run the check to confirm. beam cve check does this locally or in CI.
- If you cannot upgrade yet, apply the advisory's workaround or block the vulnerable route, and set a date to finish.
- For actively exploited ones, search your logs for exploitation since the dependency was added, not only since the advisory.
Recover and close out the incident
- Confirm the fix. Replay the attack against staging and check that no new findings arrive for it in production.
- Mark findings reviewed, so the queue shows only what is still open.
- Tune alerting. Add a rule for anything that was noise, and an alert route if this should have paged someone sooner. AgentBeam's alert workflows can send critical findings to PagerDuty and the rest to Slack or Teams.
- Write it up within a week. What happened, how it was found, how long each step took, and what changes so it cannot happen the same way again. Blame the gap, not the person.
When to escalate a security incident
Escalate to your security lead, and through them to legal or leadership, when:
- an attacker ran code on a server, or you cannot rule it out
- customer or personal data may have been read, changed or taken
- an exposed credential was used
- payment, health or other regulated data is involved
Data protection law can set short deadlines once you are aware of a personal data breach. GDPR Article 33 gives 72 hours to notify the supervisory authority. Start that conversation early, not after cleanup.
What app monitoring can and cannot tell you
A finding means a request or log line matched an attack pattern. It does not prove the attack worked, and it does not prove it failed. AgentBeam sees redacted findings, not raw log lines, full requests or what happened inside your app, so your own logs and responses remain the primary evidence. Detection is heuristic: it will miss attacks it has no rule for and flag some legitimate traffic. We wrote more about those limits in what app monitoring can and cannot catch.
What it does give you is the starting point: the time, the app, the evidence and a link to the right playbook, in the channel your team already watches.
Related reading
- After an attack: responding to a finding (docs)
- Monitor a running app for attacks with beam monitor
- API keys in logs and env vars: how they leak and how to catch it
- First 24 hours after a vendor breach
- PHP2Shell patch guide
- October 2026 attacks timeline
- App monitoring
Frequently asked questions
What should I do first after an attack alert on my app?
Confirm whether the request reached your code and got a successful response, then save logs and snapshot the host before changing anything. Restarting, redeploying or rotating keys first can destroy the evidence you need to know what happened.
How do I tell a real attack from noise?
Check the response. A 404 or 403 on a probe is noise. A 200 with an unusual body after an injection payload, a worker spawning a shell, or a credential in a log is real. If you cannot rule out that it worked, treat it as if it did and contain first.
What do I do if an API key leaked into my logs?
Revoke and rotate it at the provider immediately, then check the provider's logs for use of the old key since it was exposed. Remove the logging statement and purge copies from log storage and your log vendor where you can.
Should I clean a compromised server or rebuild it?
Rebuild. Isolate it, capture its state, rotate every secret it could read, then redeploy from a known-good image onto fresh infrastructure. A cleaned host can keep a backdoor you did not find.
When do I need to escalate a security incident?
When an attacker ran code on a server or you cannot rule it out, when customer or personal data may have been read or taken, when an exposed credential was used, or when regulated data is involved. GDPR gives 72 hours to notify the supervisory authority once you are aware of a personal data breach.
Does AgentBeam tell me whether an attack succeeded?
No. A finding means a request or log line matched an attack pattern. AgentBeam does not see raw log lines, full requests or what happened inside your app, so your own logs and responses decide whether it worked.
This playbook is general guidance, accurate as of October 24, 2026, and not legal advice. Check notification duties with your own counsel.