- Alerts arrive with a cited summary, related events and likely ATT&CK techniques
- Analysts query telemetry in plain language with the generated query shown
- Response actions proposed by AI and executed only after analyst approval
- Incident records aligned with the organisation's incident response framework
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A financial services group ran a security operations centre that took alerts from endpoint protection, identity providers, cloud platforms, email security and network tools. Each tool had its own data format and console. Analysts spent much of their time gathering context: which user, which host, what else happened nearby, has this been seen before. Experienced analysts carried that knowledge in their heads; newer ones escalated more than they needed to.
Leadership wanted to apply AI. The security team's concerns were specific: an assistant that invents findings, one that attackers can manipulate through the very logs it reads, and anything that acts on production systems without a person deciding.
What had to be true
- Every statement cited to the events, alerts or runbooks it came from.
- Read-only by default: the copilot investigates; it does not change systems.
- Human approval for every response action, with the action and its reason logged.
- Consistent data across sources, so the same question gives the same kind of answer.
- Aligned with the incident response process the organisation already followed and was audited against.
Architecture
The data flow, end to end
- IngestAlerts and events mapped to the common schema and linked to entities
- EnrichRelated events, asset criticality and likely ATT&CK techniques attached
- SummariseCopilot drafts a triage summary citing each underlying event
- InvestigateAnalyst asks follow-ups; copilot runs read-only queries and shows them
- ProposeCopilot suggests containment steps from approved runbooks
- ApproveAnalyst approves or edits; playbook runs; incident record updated
Normalisation made the rest possible. OCSF is an open, vendor-agnostic schema for security events, with a framework of data types, an attribute dictionary and a taxonomy2, and it moved under Linux Foundation governance in 20243. MITRE ATT&CK supplied a shared vocabulary for adversary behaviour, so summaries described detections in terms analysts already used4.
The hard part: an assistant that reads attacker-controlled text
Most AI copilots read trusted documents. A security copilot reads email subjects, file names, command lines and web requests, many written by attackers. Prompt injection, listed in the OWASP Top 10 for LLM applications5, is not a theoretical risk here. The design assumed it would be attempted:
- All event content treated as untrusted data, clearly separated from instructions in every prompt.
- Tools read-only by default, with narrow scopes; no tool able to change a system directly.
- Action proposals limited to steps from approved runbooks, and every proposal approved by an analyst.
- Generated queries shown to the analyst, so the reasoning can be checked rather than trusted.
- An evaluation set of past incidents, including deliberately manipulated log content, run before each change.
In a SOC, the AI's input is partly written by the adversary. Design as if every log line is trying to give your copilot orders.
The general controls are covered in prompt injection defence for agents and evaluating AI agents.
How it ran
- Define triage questions
- Rate summaries and proposals
- Approve all actions
- OCSF mappings
- ATT&CK tagging
- Runbook clean-up
- Copilot and tools
- Injection-aware evaluation
- Audit and monitoring
- Map top sources to OCSF
- Entity resolution
- Runbook inventory
- Cited triage summaries
- Shadow mode with analysts
- Evaluation set
- Read-only query tools
- Queries shown to analysts
- Injection testing
- Action proposals
- Approval workflow
- Incident record integration
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Normalise to OCSF first | Let the model read raw vendor formats | Consistent answers and reusable queries across sources |
| Read-only tools by default | Give the copilot SOAR access | Limits the damage from errors or manipulation |
| Approval for every action | Auto-contain high-confidence alerts | Keeps accountability with analysts while trust is built |
| Show generated queries | Show only the answer | Analysts can verify reasoning and learn the data |
| Map to the IR framework | Copilot-specific workflow | Fits existing audits and reporting |
Incident records and handoffs were aligned with NIST SP 800-61 Revision 3, which organises incident response recommendations around the Cybersecurity Framework 2.0 functions1, so the copilot fitted the process auditors already expected. Lessons from incidents fed the approach in AI incident postmortems.
What I'd do again, and differently
Again: normalise data and build the evaluation set from real incidents before writing prompts. Differently: start runbook clean-up earlier. Many proposals were only as good as the runbooks behind them, and some runbooks were out of date.
If you're considering AI in security operations, my AI architecture work covers how I approach it, or analyse your challenge and bring the result to a call.
- 1
- 2Open Cybersecurity Schema Framework (OCSF)OCSF, GitHub
- 3Open Cybersecurity Schema Framework (OCSF) joins the Linux Foundation to optimize critical security dataLinux Foundation · Nov 2024
- 4MITRE ATT&CKMITRE
- 5OWASP Top 10 for LLM ApplicationsOWASP GenAI Security Project