Respond faster without living in the SIEM
Alerts pile up, identity tickets lag, and the war room opens in five tabs. WEXTL enriches signals, revokes access, and escalates incidents on a canvas your team can audit — not another script folder.
Deploys this workflow into your workspace — you'll connect your own accounts.
Workflow enriching security alerts with AI and posting to Slack
- GDPR
- Data Encryption
- 2FA
- Local Data Region
- 40
- alerts overnight before the real one surfaces
- 12
- stale accounts found by hand each quarterly review
- 3
- actions held for a human: revoke, block, escalate
* Illustrative example, not measured customer data.
SecOps automation, at a glance
SecOps playbooks that leave a log
Four workflows security teams clone first — enrich, revoke, escalate, and digest.
Alerts with context attached
Watch incidents, enrich with an agent, and post a structured summary to Slack.
- Trigger — a new event lands from the SIEM export (pulled over HTTP on a schedule) or arrives as a webhook the moment the rule fires.
- Information collected — asset and owner on record, any open ticket already tracking it, and whether this exact alert rule fired on this exact asset before.
- Connected applications — HTTP for the SIEM export or webhook, Jira or InvGate for the existing ticket, Slack for the enriched summary.
- Decision logic — scored against your team's severity/confidence thresholds; a known-noisy rule on a known-noisy asset scores down instead of paging on repeat.
- AI step — drafts what fired, why it matters, and what's different from the last occurrence, in a few sentences.
- Human approval — paging on-call requires the score to clear your threshold; anything within one point of it waits for a person instead of a guess.
- Actions — posts the summary to Slack, opens or updates the ticket, and — when the alert matches a known-bad indicator — proposes adding the source IP to a Cloudflare block list.
- Exception handling — an alert missing asset or owner context is held for manual triage instead of scored blind.
Workflow enriching security alerts with AI and posting to Slack
What a SecOps analyst actually fights every shift
None of it is technically hard. A SIEM alert needs the same five minutes of context-pulling every time — asset owner, prior occurrences, whether it's the known-noisy rule again. An access review finds the same dozen stale accounts every quarter because offboarding a leaver's laptop access is not the same ticket as offboarding their SaaS logins. And the on-call severity call gets made from memory, under pressure, differently depending on who picked up the page.
- Step 1
The overnight queue
Forty alerts by 7am, most of them the same false positive as last Tuesday, and the one real one looks identical until you've opened all forty.
- Step 2
The stale-account surprise
A quarterly access review turns up twelve accounts nobody offboarded — and now it's a finding, not a fix.
- Step 3
Improvised severity calls
Whoever's on call decides what SEV1 means today, because the escalation matrix lives in someone's head, not a doc anyone opens under pressure.
WEXTL is not a SOAR replacement and it doesn't ingest your SIEM natively — it's the canvas that turns an HTTP export or webhook into a consistent enrich-decide-escalate path, with a record of what happened at every step.
Example: automate alert enrichment and escalation
A concrete run, the kind a SOC clones from the template library on day one and adjusts to its own severity matrix.
Trigger: a new event lands from the SIEM export — pulled over HTTP on a schedule, or pushed as a webhook the moment the SIEM fires.
WEXTL checks: the asset and owner on record, whether this exact rule fired for this exact asset before (and how it was closed last time), any open ticket already covering it, and the severity/confidence thresholds your team has configured for that alert type.
Human judgment
Adding an IP to a block list, naming an incident commander, and any score within one point of your threshold stay with the analyst. The workflow enriches and proposes; a person decides what gets blocked and what gets paged.
Example: automate identity risk response
The same discipline applied to identity: a risk signal shouldn't turn into a stale ticket sitting in a queue, and it shouldn't turn into an account getting disabled on a hunch either.
Trigger: Microsoft Entra ID raises a risk signal — impossible travel, a leaked-credential match, an offboarding event pushed from HR — or a scheduled access review flags an account inactive past your policy window.
Sources combined: the risk signal itself, sign-in location and device history, the account's role and owner, and whether it's flagged as a service account, shared mailbox, or a registered AI agent identity rather than a person.
Human judgment
A service account, a shared mailbox, or an account on the sensitive-role list never gets auto-revoked — those wait for a security lead. The workflow flags and proposes; a person decides where breaking access outweighs the risk of leaving it open.
1. Risk signal fires
Entra ID raises a score change, or a scheduled access review flags an inactive account.
2. Pull sign-in history, identify the owner
Location, device, and timing context for the flagged session, matched to a manager or system owner before anything happens to it.
3. Check account type and apply policy
Human, shared mailbox, service account, or a registered AI agent identity each follows a different policy path — only high risk plus a human account clears auto-revoke.
4. Draft the summary
AI writes a plain-language explanation of what was seen and why the threshold was crossed.
5. Hold for approval where policy says so
Service accounts, shared mailboxes, and any account on the sensitive-role list wait for a security lead, no exceptions.
6. Revoke or flag
Disables or suspends the account in Entra ID, or files it for manual review if it didn't clear the policy path.
Judgment showed up exactly where it mattered — the account outside policy, the alert with no history to score against. Everything else followed the same path it followed last night.
Who SecOps automation is for
Not every security function needs this on day one. It's built for the parts of the job that repeat across a lot of alerts, a lot of accounts, or a lot of on-call shifts.
SOC analysts triaging overnight queues
— The same enrichment steps run on every alert, awake or not.IAM/identity admins inside security
— Risk-based revoke and access reviews follow policy, not whoever's available.Incident responders and on-call leads
— The same escalation matrix fires whether it's the senior analyst's shift or a new hire's first week.Compliance and audit-facing security engineers
— Every automated identity and escalation action needs an exportable record for the next audit.Security engineering supporting multiple teams
— The same enrich-and-escalate logic runs per team's ticket queue, not rebuilt for each.Teams tracking non-human identity sprawl
— Service accounts and AI agent identities need the same offboarding discipline as people, and usually don't get it.
Confirmed indicators, blocked without a ticket detour
A confirmed-bad IP doesn't need a ticket, an assignment, and a deploy window before it's blocked — it needs the block applied and the team told it happened.
When an alert matches a known indicator, WEXTL can add it to a Cloudflare block list and post the change to the channel in the same run, with the analyst's confirmation gate still in front of it.
- Step 1
Block proposed, not applied
The IOC match triggers a proposed block-list change, held for confirmation.
- Step 2
Applied at the edge
Once confirmed, the block runs in Cloudflare — no separate change ticket.
- Step 3
Channel gets the record
What was blocked, which alert triggered it, and who confirmed it — posted where the team can see it.
Connect the security stack your SOC already runs
You don't get to pick a clean-slate stack. The SIEM, the identity provider, the ticket queue, and the escalation channel are already fixed — automation has to meet them where they are.
These are the integrations most SecOps workflows actually use. An HTTP step reaches your SIEM's export or webhook, and anything else with an API.
- Microsoft Entra IDRisk scores, sign-in anomalies, and the account actions — revoke, suspend, notify — that identity workflows actually take.
- Microsoft Entra Agent IDGoverns non-human identities — the AI agents and automations with their own credentials — with the same offboarding discipline as people.
- CloudflareEdge block-list changes for confirmed indicators, applied and logged in the same run.
- Google SheetsDigest rows appended on a schedule for retention and trend review.
