Automated Security Alert Triage From alert fatigue to a ranked queue
Every security alert is enriched, correlated and assessed within minutes; analysts see only what needs a person.
- Installed for you · one-time$249
- Run for you$297/month
- Custom build · this process$6,000–12,000 one-time
- Starts whenSIEM / EDR event (alert created)
Covers one SIEM or EDR source and up to 20,000 alerts a month. Multiple sources, SOAR-style response playbooks or a self-hosted model for sensitive telemetry are a custom build. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
Automated Security Alert Triage is an automation Agentmelt installs in your own tools. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $297/month, with setup and maintenance included. A custom build of this process is $6,000–12,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-17.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is automated security alert triage?
Automated security alert triage takes each alert from the SIEM or EDR, enriches it with the asset owner, user context, threat intelligence and related recent events, scores it against your rules and known-benign patterns, auto-closes the noise with a documented reason, and hands analysts a ranked queue where the investigation has already started. It automates the first thirty minutes of every alert, not the response.
- Analysts close hundreds of alerts a day and most of them were benign; the real one was in the pile.
- Every alert needs the same five lookups before anyone can judge it.
- The SOAR platform we bought needs a developer for every playbook.
- Nobody can say what share of alerts were noise last month, or why.
- Compliance wants a record of how each alert was handled, and it lives in people's heads.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Security teams drown in alerts, most of them benign. The workflow takes each alert from the SIEM or EDR, enriches it — asset owner, user context, threat intel, recent related events — scores it against your rules and known-benign patterns, auto-closes the noise with a documented reason, and gives analysts a ranked queue where each alert already has the timeline, the enrichment and a suggested first action.
- 02:13 An alert fires. The host, user and IP are enriched with owner, criticality and recent activity.
- 02:13 Related alerts from the last 24 hours are pulled together so it is seen as one story.
- 02:14 A score is computed; above the noise line, an analyst-style assessment is written.
- 02:15 Known-benign patterns close with the reason recorded; a high score pages the on-call analyst with the assessment.
Analysts spend most of their shift on alerts that turn out to be nothing, each one requiring the same lookups. Real incidents wait in the same queue. Tuning is never done because nobody has time to analyse which rules produce noise.
Benign patterns are closed automatically with an audit trail. Analysts open a queue ranked by risk where every alert carries the context they would have spent twenty minutes collecting. Mean time to triage falls, escalations are more accurate, and the weekly noise report tells the team exactly which detection rules to tune.
Trigger, then 8 steps.
All eight steps run without anyone; a person sees only what the guardrails escalate.
SIEM / EDR event (alert created)
Receive and normalise the alert
Source, rule, severity, entities (host, user, IP, hash, domain), timestamps and raw event, normalised into a common schema regardless of source.
Enrich entities
Asset owner and criticality from the CMDB, user role and recent auth activity from the identity provider, IP and domain reputation from threat-intel feeds, file hash lookups, and geolocation.
Correlate with recent activity
Related alerts and events for the same entities in the last 24 hours, so a single alert is seen as part of a sequence when it is one.
Score and classify
Deterministic score from severity, asset criticality, user privilege, intel hits and correlation count; known-benign patterns (scheduled scans, approved admin tools, backup jobs) match against an allowlist maintained by the team.
Analyst-style assessment
For alerts above the noise threshold, the agent writes the assessment: what the activity looks like, what is unusual for this entity, the most likely benign and malicious explanations, and the first three investigation steps with the exact queries to run.
Auto-close or queue
Allowlisted patterns close with the reason recorded; low scores close after the assessment confirms benign; everything else enters the queue ranked by score with the assessment attached.
Notify and escalate
High-score alerts page the on-call analyst with the assessment; critical patterns (credential dumping, ransomware indicators) trigger the incident channel and the playbook immediately.
Weekly tuning report
Alerts by rule, auto-close rate, analyst dispositions vs workflow scores, and the top ten noise-producing rules with suggested tuning.
No step waits for a person.
What the workflow hands to someone, by rule:
- The workflow never takes containment actions (isolate host, disable user) on its own; it recommends and a human executes, or a separate approved playbook runs with explicit authorisation.
- Auto-closed alerts keep the full enrichment and reason and are sampled weekly for false-negative review.
Benign patterns are closed automatically with an audit trail
Benign patterns are closed automatically with an audit trail.
No decisions needed. Anything the guardrails flag is handed to a person; the rest ran alone.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
Data it touches
- SIEM / EDR alerts (Splunk, Sentinel, Elastic, CrowdStrike, SentinelOne)
- CMDB / asset inventory
- Identity provider logs (Okta, Entra ID)
- Threat intelligence (VirusTotal, AbuseIPDB, MISP, vendor feeds)
- Allowlist of known-benign patterns and the incident playbooks
Guardrails
- The workflow never takes containment actions (isolate host, disable user) on its own; it recommends and a human executes, or a separate approved playbook runs with explicit authorisation.
- Auto-closed alerts keep the full enrichment and reason and are sampled weekly for false-negative review.
- Critical patterns bypass scoring and page immediately.
- The allowlist is versioned, owned by the security lead, and every match is logged.
Enrichment first, model second
The analyst's twenty minutes per alert are mostly lookups: who owns this host, is this user an admin, is this IP known-bad, what else happened on this machine today. Every one of those is an API call, and the workflow makes all of them before anyone — or any model — looks at the alert. Deterministic scoring on the enriched alert then closes the obvious noise. The language model is reserved for the alerts that survive, where its job is to write the assessment an analyst would write after those lookups, with the next queries ready to paste.
Auto-closing safely
Auto-close is where security teams rightly hesitate. The workflow's answer is transparency and sampling: every closed alert keeps its full enrichment and the specific reason (allowlist match X, or score below threshold with assessment Y), and a random sample of closures is reviewed weekly. If the sample finds a false negative, the pattern or threshold is changed that week. This is stricter than the current state at most teams, where alerts are closed in bulk with no reason recorded.
The tuning report is the real product
Alert fatigue is a detection-engineering problem: a handful of rules produce most of the noise. The weekly report ranks rules by noise contribution and shows analyst dispositions against workflow scores, so the team can tune or retire rules with data. Teams that act on the report see alert volume fall month over month, which no amount of triage automation achieves on its own.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Ingestion, enrichment, scoring, routing, reporting |
| Claude | Analyst-style assessments and investigation steps |
| Splunk / Sentinel / CrowdStrike | Alert sources |
| VirusTotal / AbuseIPDB / MISP | Threat intel |
| Slack / PagerDuty | Notifications and paging |
Want this running without building it?
$297/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$6,000–12,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Covers one SIEM or EDR source and up to 20,000 alerts a month. Multiple sources, SOAR-style response playbooks or a self-hosted model for sensitive telemetry are a custom build.
Also sold one-time, installed in your own accounts, as part of the cybersecurity analysts package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $297/month, setup and maintenance included. Three things move it to a custom build ($6,000–12,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
More than one SIEM or EDR source feeding the same queue.
SOAR-style response playbooks — isolating a host, revoking a token, opening a case — run from the triage step.
A self-hosted model for telemetry that cannot be sent to a hosted API.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Can it isolate hosts or disable users?
Not by default. Containment actions are recommended in the assessment and executed by an analyst. Approved response playbooks with explicit authorisation and logging can be added as a custom build for specific high-confidence scenarios.
Is telemetry sent to a third-party model?
Only alerts above the noise threshold reach the model, with entity values that can be pseudonymised; the provider does not train on the data. A self-hosted model is available for teams that require it.
How is this different from a SOAR platform?
SOAR platforms are broad and expensive; the workflow does the triage and enrichment part inside your own automation account, with your allowlist and scoring, for a fraction of the cost. Teams with a SOAR can run it as the enrichment and assessment layer in front of it.
How do you automate triage in cybersecurity without missing real incidents?
Enrich first, decide second, and never let the model be the only gate: auto-close only patterns that your rules — written by the team — mark as benign, log the reason on every closure, sample closed alerts for review each week, and keep any containment action (isolating a host, disabling a user) with a person. The weekly tuning report shows the false-close rate, which is the number that matters.
What are the compliance requirements for using AI agents in security operations?
The requirements that come up in SOC 2, ISO 27001 and sector audits are about traceability and control: every automated action logged with its inputs and reason, no automated action outside a written rule, human approval on anything that changes access or availability, and telemetry not leaving your environment without a data-processing agreement. The workflow's audit trail and its no-containment rule are designed to those points.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- MITRE ATT&CK attack.mitre.org/
- NIST SP 800-61 Rev. 3 — Incident response recommendations csrc.nist.gov/pubs/sp/800/61/r3/final
- VirusTotal — API reference docs.virustotal.com/reference/overview