Security Alert Triage

The problem

When an IT or security admin spots suspicious activity on a user account — a strange login location in their SIEM, an alert in their Datadog dashboard, a tip from a manager — the first 15 minutes are the most expensive. The admin needs to suspend the account quickly, but the suspension itself needs an audit trail that distinguishes "investigation in progress" from "this person was offboarded" so downstream evidence reports stay clean.

What AscendCore does

An IT or security admin invokes /alert-triage <user-email> [reason] from Slack (or types the equivalent message in Microsoft Teams). AscendCore resolves the user in Okta, posts a propose-confirm card to the admin channel showing the user, current Okta status, and the admin's free-form reason, with two buttons: Suspend Pending Investigation (destructive) or Clear — No Action. On approval, the Okta account is suspended via /api/v1/users/{id}/lifecycle/suspend. On clear, no action is taken. Either outcome writes a row to the tamper-evident SHA-256 audit chain under the account_triage.* verb namespace, distinct from the offboard.* verbs so SOC-2 evidence reports separate security-investigation events from lifecycle events.

Commands

# Slack
/alert-triage <user-email> [optional reason text]

# Teams (DM the bot or @mention)
alert-triage <user-email> [optional reason text]

Examples:

• /alert-triage sarah@acme.com suspicious login from new IP at 03:14
• /alert-triage marcus@acme.com session from foreign country, manager flagged
• /alert-triage ben@acme.com — reason omitted; admin will add context in audit notes

Workflow

1. Invoke — IT/security admin types the slash command (Slack) or message (Teams) with the user email and optional reason
2. Resolve — Okta lookup; surfaces disambiguation if multiple matches
3. Propose — admin channel card with user identity, current Okta status, and the admin's reason; two buttons (Suspend / Clear)
4. Approve — admin clicks Suspend (destructive) or Clear (no action)
5. Execute — on Suspend, Okta suspendUser API call; on Clear, no Okta change
6. Notify — requester DM'd by the bot with the outcome
7. Audit — account_triage.suspended or account_triage.cleared row appended to the SHA-256 hash chain, distinct from offboard.* verbs

Integrations

• Okta — Account suspension via POST /api/v1/users/{id}/lifecycle/suspend
• Slack + Microsoft Teams — Admin-invoked entry point and approval surface, with full Block Kit and Adaptive Card parity

Inbound webhook foundation (Q4 2026 roadmap extension)

A unified Datadog + PagerDuty webhook receiver is live in production at /api/automation/alerts — it normalizes inbound alerts, classifies severity via Claude Haiku, auto-acknowledges low-severity alerts, and posts informational cards for medium/high alerts. The post-Q4 2026 roadmap extends that receiver to optionally trigger an alert-triage propose-confirm flow when the inbound alert payload includes a correlatable user identifier (Okta user_id, email, or AAD object_id). Until that lands, admins manually invoke /alert-triage after seeing the system-level alert.

Status

Live in production — admin-invoked flow shipped May 2026 with Slack + Teams parity, Okta suspension execution, and tamper-evident audit chain integration. Inbound webhook auto-correlation extension on the post-Q4 2026 roadmap as a separate enhancement.