SecOps Triage Agent
A Slack-native AI security analyst that triages alerts, learns from your team, and watches the network on its own.
Track: New Slack Agent
The problem
Security operations teams drown in alerts. Every alert means moving between a SIEM, a threat-intel portal, an asset inventory, and the tribal knowledge buried in chat ("we dismissed this exact thing last week"). The most of them are false positives; the few real incidents are hidden in the noise. Triage is slow, repetitive, and the institutional memory that makes a senior analyst good lives in people's heads not in the tools.
Meanwhile, the security team already lives in Slack. So that's where triage should happen.
What it is
SecOps Triage Agent turns Slack into the first-response surface for security triage. It's built on Slack's new Agent messaging experience (shipped June 30, 2026 , this app runs on Slack's newest agent surface): open the agent from your sidebar and just talk to it ("triage WKS-4471", "has anyone mentioned this host?"), starting from suggested prompts pinned at the top of the conversation. Or let it auto-triage incoming alerts into interactive cards in a channel.
For every alert, the agent pulls context from a custom MCP server, asset criticality, threat intel, alert history, incident correlation, and prior analyst decisions searches the live workspace for relevant team chatter via the Real-Time Search API, reasons over all of it, and returns a severity call and a recommended action with its full reasoning shown. The analyst clicks Escalate or Dismiss, and that decision becomes memory the agent recalls next time.
The agent is hosted 24/7 so it's a running service, not a demo script.
What makes it different
Most "AI in Slack" projects are a chatbot reading data handed to it. This one does four things that step past that:
- It learns, but not blindly. Every Escalate/Dismiss is stored and recalled on the next similar alert. A false positive a human dismissed last week is not re-escalated this week the agent reads the prior human ruling and defers to it. And if new evidence contradicts a stale dismissal (say, that "benign" pattern is now part of an active kill chain), it explicitly overrides and explains why. Institutional memory, encoded , with judgment.
- It watches. A proactive monitor scans for new activity on its own, triages it, and decides what's worth surfacing to a human. Suppressing noise, escalating real incidents, unprompted. It's a process, not just a request/response bot.
- It correlates. It reads an ordered chain of alerts as a single incident and follows lateral-movement pivots (workstation → server), raising severity when an attacker is on the move.
- It reasons over live team context. Via Real-Time Search it folds in what the team has already said. For example, catching a teammate's note that a "patch window explains the service restarts" does not explain a confirmed-malicious hash, and using that to raise urgency rather than lower it.
How it uses the three technologies
All three of the hackathon's qualifying technologies do real work remove any one and the product is meaningfully worse:
- Slack AI capabilities - a native Slack agent on the new Agent messaging experience: AGENT badge, suggested prompts, conversational triage in the agent's Messages tab, with an immediate "Investigating…" acknowledgment while it works. (The code also retains Bolt
Assistantsupport for workspaces still on the legacy assistant-pane experience.) - MCP server integration - a custom MCP server exposes five context tools (
get_asset_context,get_threat_intel,get_alert_history,get_related_alerts,get_analyst_feedback) that the agent calls in whatever combination each alert needs. - Real-Time Search API - mid-investigation, the agent calls
assistant.search.context(using the action token delivered on the message event) to search the live workspace for prior discussion of a host or indicator, and quotes what it finds in its verdict.
How it works
Slack surfaces --> Claude reasoning loops --> MCP server (5 tools) + Real-Time Search
• agent Messages tab • conversational agent • asset / threat-intel / history
• triage cards • triage agent • correlation / analyst memory
• Escalate/Dismiss • proactive monitor • live workspace search
- The agent conversation and the triage cards are two front doors to the same brain.
- Each reasoning loop runs on Claude (Anthropic API) and decides which tools to call.
- The MCP server reads seeded datasets (assets, history, alert stream), live threat intel from AbuseIPDB, and the analyst memory store.
- Escalate/Dismiss writes to memory, which the
get_analyst_feedbacktool recalls — closing the learning loop. - The proactive monitor runs the same triage on new activity and autonomously decides surface-vs-suppress.
Demo highlight
Ask the agent: "has anyone mentioned SRV-DB-07? then triage it." It searches the workspace, finds a teammate's note about a maintenance window, recognizes the human's explicit caveat that "anything hash-flagged is NOT part of that," pulls the malicious-hash verdict from threat intel, recalls that an analyst escalated this exact hash on this exact host before, correctly rules out an unrelated dismissal on a different host — and returns a single ESCALATE / CRITICAL verdict that ties all of it together. Four context sources, one coherent call, in a native Slack conversation.
Impact
SOC triage is one of the most expensive, highest-burnout workflows in security — analysts spend hours a day on alerts that are mostly noise. An agent that triages in seconds, remembers team decisions so the same false positive isn't re-litigated, and proactively surfaces only what matters, directly attacks alert fatigue and mean-time-to-triage. Because it's Slack-native and the MCP tools are thin adapters, the same pattern generalizes to any team that triages a queue inside Slack — IT, on-call/SRE, trust & safety, fraud.
Tech stack
Python · Slack Bolt (Socket Mode) · custom MCP server (FastMCP) · Anthropic Claude · AbuseIPDB (live) · Slack Real-Time Search API · hosted on Railway. Fully tested with an offline suite (no API key required) covering the memory store, RTS parsing, the card builder, the proactive monitor, and the full agent tool-call loop.
What's next
Swap the seeded datasets for real connectors (a CMDB, a SIEM, VirusTotal), persist memory to a shared store for multi-analyst teams, and let the agent open and update tickets directly from a card.
Log in or sign up for Devpost to join the conversation.