Executive Snapshot

  • Client type: Mid-sized managed security service provider supporting approximately 35 client organizations
  • Industry: Cybersecurity and managed security services
  • Core problem: Analysts had to find a small number of serious incidents within thousands of fragmented, mostly low-risk alerts
  • Why agentic AI: The work required several specialized retrieval, correlation, planning, and drafting steps that had to share state but remain subject to client-specific rules and human approvals
  • Deployment stage: Prototype
  • Primary result: A redesigned workflow moves evidence collection and documentation to six coordinated agents while preserving human authority at every consequential security, business, legal, and communication decision

1. Business Context

SentinelBridge Managed Security Services operates a centralized 24/7 Security Operations Center for clients in financial services, healthcare, retail, logistics, manufacturing, and cloud software. Its monitoring systems generate an illustrative 18,000 raw alerts per day across endpoint, identity, email, firewall, cloud-security, vulnerability, and data-loss-prevention products. About 1,200 alerts reach the analyst queue; 50–70 require extended investigation, and 5–10 become probable or confirmed incidents. The provider must acknowledge critical alerts within minutes, but it cannot treat every anomaly as an emergency. A suspicious login may be an attacker, an employee travelling, or an approved administrator using a new network. Delayed escalation can increase loss, while an unnecessary isolation or account shutdown can interrupt a client’s business.

2. Why Simpler Automation Was Not Enough

A fixed rule could enrich an IP address or close an exact duplicate, but the operating workflow did not follow one stable path. Analysts had to combine client-specific asset criticality, identity privilege, maintenance windows, approved exceptions, historical tickets, threat intelligence, and signals that appeared at different times in different systems. A chatbot could summarize one alert, but it would not reliably maintain an evolving incident state, re-open an investigation when new evidence appeared, or enforce the difference between recommending containment and authorizing it.

The analytical point used in this case is evidence-state centralization with risk-tiered human authority. The selected research converges on a workflow design in which specialized agents collect and cross-check evidence, a shared incident record preserves the evolving state, and autonomy is bounded according to the consequence and uncertainty of each decision.12345 The transformation is therefore not “analysts replaced by an autonomous SOC.” It is a change in where coordination occurs: machines organize evidence and prepare actions; humans resolve ambiguity and exercise authority.

3. Pre-Agent Workflow

Before the agent system, an alert moved through a long chain of analyst searches, interpretations, and handoffs:

  1. A Level 1 analyst opened the alert, verified the client tenant and affected entity, and then manually searched endpoint, identity, cloud, asset, ticketing, and exception records.
  2. The analyst checked whether the activity matched an approved administrator action, maintenance window, prior false positive, or known client behavior, then searched external and internal threat-intelligence sources.
  3. Related endpoint, login, email, firewall, and cloud alerts were manually assembled into a provisional timeline. The analyst assigned severity and confidence, closed an evident benign case, or handed the record to Level 2.
  4. Level 2 reconstructed the incident, requested missing business context from the client when necessary, and escalated novel, ambiguous, privileged-account, or critical-asset cases to Level 3 or an incident commander.
  5. The team selected a client runbook, wrote response recommendations, sought approval for disruptive actions, updated the record as evidence changed, drafted the client notice, and later assembled the post-incident report. Service delivery management reviewed SLA performance and approved changes to rules, exceptions, and runbooks.

Pre-agent cybersecurity incident workflow

Key pain points:

  • Evidence was copied between tools and tickets, so each handoff could omit context or repeat work.
  • Separate alerts from one attack were sometimes investigated independently until an experienced analyst recognized the relationship.
  • Severity, closure rationale, and investigation depth varied with analyst experience and queue pressure.
  • Senior analysts spent time checking basic evidence collection and rewriting notifications instead of concentrating on difficult investigations.
  • Client business context and approval authority remained outside the technical alert, creating delays whenever an action could disrupt operations.

4. Agent Design and Guardrails

  • Inputs: Tenant-scoped alerts, identity and asset records, endpoint and cloud telemetry, prior tickets, approved exceptions, runbooks, threat-intelligence sources, and client notification templates
  • Understanding: Entity extraction, alert enrichment, deduplication, temporal and entity correlation, indicator extraction, historical-case retrieval, and evidence tagging
  • Reasoning: Client-specific severity logic, confidence and evidence-gap assessment, incident grouping, runbook selection, response sequencing, prerequisite checks, and approval routing
  • Actions: Update the incident record, propose investigative queries and response steps, draft client notifications, and compile post-incident reports
  • Memory/state: A tenant-isolated, timestamped incident record containing source evidence, correlations, working hypotheses, confidence changes, tool calls, human decisions, action outcomes, and document versions
  • Human review points: Initial disposition; ambiguous or high-impact investigation; response-plan review; containment approval; client-notification approval; breach and regulatory decisions; high-severity closure; final-report approval; and production changes to rules, runbooks, access policies, or autonomy thresholds
  • Out-of-scope actions: Independently isolating systems, disabling accounts, revoking credentials, interrupting production, notifying clients, declaring a breach, contacting regulators, or closing a high-severity incident

The post-agent workflow begins with a governance layer rather than an LLM prompt. Every request is bound to a client tenant, role, approved connector, and audit record. The Alert Enrichment Agent gathers user, device, asset, privilege, exception, and recent-activity context. The Incident Correlation Agent groups duplicate and related alerts and maintains the incident timeline. The Threat Intelligence Retriever combines structured indicator checks with retrieval from approved reports. These outputs form an evidence-grounded triage package for a Level 1 analyst.

Suspicious cases move to Level 2, which can request targeted re-enrichment, re-correlation, or refreshed intelligence. The Response Runbook Planner then proposes steps with evidence, prerequisites, operational risk, reversibility, and required approvers. After approved actions are executed, the correlation agent incorporates their outcomes and any new alerts. The Client Notification Drafter and Post-Incident Report Agent generate documents from the same validated record, reducing reconstruction and copy-and-paste work. Human edits and approvals remain part of the permanent incident history.

Agent-enabled cybersecurity incident workflow

5. One Workflow Walkthrough

A client identity platform generated an impossible-travel alert for a finance administrator. Minutes later, the email gateway reported a new mailbox-forwarding rule, and the cloud platform recorded an unusually large file download. The Alert Enrichment Agent retrieved the user’s privilege level, assigned devices, recent logins, current travel exceptions, and the criticality of the accessed repository. The Incident Correlation Agent linked the three alerts through the user identity and time window rather than leaving them in separate queues. The Threat Intelligence Retriever found that the source IP had recent malicious associations, but marked the intelligence as contextual rather than confirmed evidence.

The Level 1 analyst rejected benign closure and escalated the incident. Level 2 requested confirmation of the administrator’s travel status; the client contact reported no authorized travel or maintenance. The Response Runbook Planner proposed revoking active sessions, disabling the account, isolating the associated endpoint, and preserving mailbox and cloud audit logs. The incident commander and client approved session revocation and account disabling immediately but deferred endpoint isolation until device evidence was confirmed. The notification agent drafted the client update, which humans revised and approved. Every source, recommendation, approval, action, and change of confidence remained attached to the incident record.

6. Results

  • Baseline period: Illustrative operating baseline defined in the case profile; not a measured historical study
  • Evaluation period: Not yet completed; an 8–12 week shadow-mode pilot is recommended
  • Workflow scope/sample: Analyst-reviewed identity, endpoint, email, firewall, and cloud incidents; exact pilot sample remains to be defined
  • Process change: Repeated searching, copying, correlation, runbook lookup, and document drafting move from serial analyst work to coordinated agent steps
  • Decision/model change: Recommendations become evidence-linked, confidence-scored, tenant-specific, and reviewable; serious actions remain human-approved
  • Business effect: Expected faster validation and escalation, more consistent records, less duplicate investigation, and more Level 2/3 capacity for difficult cases
  • Evidence status: Planned

No realized time or cost saving is claimed at the prototype stage. The pilot should measure acknowledgement-to-validation time, escalation latency, analyst handling time, reopened cases, false-positive and false-negative rates, human overrides, evidence completeness, notification preparation time, SLA attainment, and any cross-tenant or unauthorized-action event. Coverage should be reported alongside accuracy: a system that makes recommendations only for high-confidence cases may improve precision while leaving a substantial share of the queue to analysts, as shown in prior guided-response work.5

7. What Failed First and What Changed

The first workflow design treated correlation as a one-time step before triage. That was inadequate because incidents evolve: a low-severity login alert can become serious when a later mailbox rule, endpoint process, or cloud download arrives. The design was changed so that the Incident Correlation Agent maintains a persistent, append-only incident state and triggers human reassessment whenever scope, severity, confidence, or attack stage materially changes. The same state now feeds response planning, notifications, closure, and reporting. The remaining limitation is upstream context quality. Stale exception lists, incomplete asset inventories, weak telemetry, or poisoned external content can still produce a well-structured but wrong recommendation, so source quality, guardrails, analyst review, and controlled rollback remain necessary.134

8. Transferable Lesson

  • Design agents around operational roles and evidence handoffs, not around a single general-purpose “SOC analyst” prompt.
  • Treat the shared incident record as the core product: recommendations, approvals, actions, communications, and learning should all derive from the same traceable state.
  • Allocate autonomy by consequence. Automate retrieval and drafting aggressively, but place explicit human gates before disruptive, legal, external, or irreversible actions.

This case shows that agentic AI works best when it compresses coordination around an auditable evidence state while making human authority more explicit, not less.

  1. Bowen Wei et al., “CORTEX: Collaborative LLM Agents for High-Stakes Alert Triage,” arXiv:2510.00311, 2025. https://arxiv.org/abs/2510.00311 ↩︎ ↩︎

  2. Ahmad Mohsin et al., “A Unified Framework for Human–AI Collaboration in Security Operations Centers with Trusted Autonomy,” arXiv:2505.23397, 2025. https://arxiv.org/abs/2505.23397 ↩︎

  3. Amine Tellache et al., “Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence,” arXiv:2508.10677, 2025. https://arxiv.org/abs/2508.10677 ↩︎ ↩︎

  4. Anes Abdennebi et al., “LanG – A Governance-Aware Agentic AI Platform for Unified Security Operations,” arXiv:2604.05440, 2026. https://arxiv.org/abs/2604.05440 ↩︎ ↩︎

  5. Scott Freitas et al., “AI-Driven Guided Response for Security Operation Centers with Microsoft Copilot for Security,” arXiv:2407.09017, 2024. https://arxiv.org/abs/2407.09017 ↩︎ ↩︎