Business case and benefits
- CISO
- A · Accountable
- SOC manager
- R · Responsible
- Solutions architect
- C · Consulted
- Technical PM
- C · Consulted
- Engineers
- I · Informed
- Security
- C · Consulted
- DPO
- I · Informed
Every alert enriched, related alerts grouped into one probable incident, and a triage summary drafted before an analyst opens it. Analysts decide every containment step and every escalation, and no high-severity alert is ever closed by the AI.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
A SOC sees thousands of alerts a day from the SIEM, the EDR, email security and the cloud platforms. For each one, an analyst opens four or five consoles: who is this user, what is this machine and how important is it, has this IP or file hash been seen before, what else happened on this host in the last hour, have we had this alert before and what did we decide. Most of an analyst's time goes on gathering that context, not on judgement.
The result is familiar. Low-value alerts are closed in bulk to keep the queue down, related alerts on the same host are worked by different people, and the one that matters waits behind the noise. Notes are thin, so the next shift starts again. When something turns out to be a personal data breach or a reportable incident, the clock has often been running for a day before anyone realises.
AI can do the gathering and the first write-up. But alert content is written by whoever triggered it: a file name, a command line, an email subject or a user agent string can all be chosen by an attacker. The NCSC warns that prompt injection may never be fully fixed. So a triage agent must never be able to close, downgrade or contain anything on its own. It reads, groups and drafts; an analyst decides.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
From alert to an analyst's decision, for high and critical alerts.
ExampleDown by half
Hands-on time spent gathering context, measured on a sample.
ExampleDown by 40–60%
Alerts the agent marked likely benign that a second analyst, reviewing a weekly sample, found to be real.
ExampleZero accepted; each one reviewed
Checked automatically from the case history.
ExampleZero
Groups an analyst had to split or merge. Too much grouping hides a second attack.
ExampleTracked weekly, falling
Personal data breaches and reportable incidents notified within the 72-hour limits, with reasons recorded for any not notified.
ExampleEvery one
Cross-sector rules are on the UK regulation map.
The CAF is the standard NIS regulators use. Version 4.0 raised the bar on security monitoring and on detecting abnormal behaviour, and covers AI-related risk throughout. A triage agent supports objective C (detecting cyber security events) and D (minimising impact). It's also a new system in your estate, so it needs its own access control (B2), logging and a place in your incident response plan.
Operators of essential services must tell their competent authority about incidents with a significant effect on the essential service without undue delay and within 72 hours of becoming aware. Relevant digital service providers report substantial incidents to the ICO. The agent flags incidents that may meet your thresholds and drafts the facts. A named person decides when the organisation is aware and whether to report.
A breach likely to risk people's rights and freedoms must be reported to the ICO within 72 hours of becoming aware of it, and people told without undue delay if the risk is high. Every breach must be recorded, reported or not. The agent flags alerts that touch personal data and drafts the breach record. The DPO decides on reporting. SOC data is also personal data about staff, so do a DPIA and keep it in UK regions.
Alert text is attacker-controlled input. The NCSC advises limiting impact rather than hoping to block every injection: the agent's own identity, least privilege, short-lived credentials, protected logs and an emergency stop. Here the agent's tools are read-only, containment runs in a separate approved workflow, and the agent's own activity is monitored by the SOC.
A voluntary baseline of 13 principles for securing AI systems, including threat modelling, human oversight and monitoring. Use it to assure the triage agent like any other security tool, and ask the same of any supplier's AI features.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Detection sources
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Alert intakeTake alerts after your SIEM's correlation, not raw logs. Keep each alert's original ID so replays and retries are harmless. | EventBridge and SQS, fed by your SIEM's API or webhooks; Security Hub for AWS findings | Event Hubs and Service Bus, fed the same way; Microsoft Sentinel if it's your SIEM | Apache Kafka |
| Security data lake (optional)Only if you need longer look-backs than your SIEM keeps. The agent queries it through fixed, read-only searches. | Amazon Security Lake (OCSF format) | Microsoft Sentinel data lake | OpenSearch |
| Enrichment toolsNamed lookups: asset and owner, user and recent sign-ins, indicator reputation, EDR process tree, related alerts in a time window. No free-form queries, no write calls. | AgentCore Gateway in front of read-only APIs | API Management in front of read-only APIs | Kong or your existing API gateway in front of read-only APIs |
| Threat intelligenceInclude the NCSC and sector feeds you already receive. Record where each indicator came from. | Your threat intelligence platform, or MISP on EC2 or EKS | Your threat intelligence platform, or MISP on Azure VMs or AKS | MISP (open source) on Kubernetes |
| Runbooks and past incidents (retrieval)Your approved runbooks and closed incident write-ups, so suggested next steps cite your own procedures. | Bedrock Knowledge Bases | Foundry IQ, built on Azure AI Search | OpenSearch, or PostgreSQL with pgvector |
| Reasoning and draftingBoth clouds offer a choice of models, including Claude. Many SOCs keep log data on-prem; open-weight models on your own GPUs make that possible. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Cloud providers' own security AIUseful for each provider's own estate. Check where prompts are processed and what's shared before turning them on. Security Copilot's data sharing is on by default. | GuardDuty and Security Hub for AWS workloads; the GuardDuty investigation agent is in preview (London included) | Security Copilot, with prompt evaluation set to the UK and data sharing reviewed | Not applicable: use your own models |
| Containment workflowRuns only an approved action from a fixed list (isolate host, disable account, block indicator), after the analyst's approval is recorded. High-impact actions need the incident lead too. | AWS Step Functions, with its own scoped role | Logic Apps, with its own managed identity | Temporal or n8n, with its own scoped service account |
| Link to case managementGroups, summaries and drafts land as notes on the case. Only analysts change status or severity. | API Gateway, plus your existing integration platform | API Management, plus your existing integration platform | Kong or your existing API gateway, plus your existing integration platform |
| GuardrailsConfigure them so they don't block malware names and attack strings the SOC needs to see. They help, but the real control is the tool permissions. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, privileged accessSeparate identities for the agent and the containment workflow. Neither uses an analyst's account. | IAM roles for the agent, KMS, Secrets Manager | Entra ID workload identity, Key Vault, Privileged Identity Management | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditThe agent is a target too. Its tool calls, refused calls and outputs go to the SOC, in storage that can't be altered. | CloudWatch, CloudTrail, into your SIEM | Azure Monitor, Log Analytics, into your SIEM | Prometheus, Grafana, OpenTelemetry, into your SIEM |
| UK data residencySecurity logs are sensitive. Keep processing in the UK, including any provider AI feature. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
Your SIEM, EDR management, domain controllers and anything that can contain or change a system stay where they are. Many SOCs also keep raw logs on-prem, and that works with this design.
Uses cloud AI
The agent, the runbook index and the drafting can run in a UK cloud region, or on your own GPUs with open-weight models if log data must not leave your estate. They receive alerts and the results of read-only lookups, never credentials.
How they connect
Alerts flow outbound over AWS Direct Connect, Azure ExpressRoute or a VPN. Lookups come back in through one read-only gateway inside your network that decides what can be asked and logs every call. Approved containment actions are pulled from a queue by a worker inside your network.
If the link drops
Analysts work alerts exactly as before, from the SIEM and their own consoles. Alerts queue and are enriched when the link returns, and nothing in detection or response depends on the AI being up.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
SOC triage agent
Where a person signs offAn analyst makes every triage decision and approves every containment action, and the incident lead also approves high-impact ones such as isolating a server. The DPO and the NIS lead decide on reporting. High and critical alerts always get a full analyst review. The agent's permissions are enforced by the platform's identity and policy controls, the read-only gateway and the separate containment workflow, not by instructions in a prompt.
The SIEM stays the source of alerts and the case tool stays the system of record. Alerts are copied onto a queue with their original IDs. If the agent is slow or down, alerts reach analysts exactly as they do today; the agent adds notes when it catches up.
Every lookup goes through a read-only gateway inside your network. Each tool is a named query with a fixed scope and a rate limit, so enrichment can't overload the SIEM during an incident. Raw alert fields are passed to the model as clearly marked data, and the analyst always sees the original evidence next to the summary.
Containment is a separate path. The analyst approves an action in the case tool, an event is raised, and the containment workflow checks the approval and runs one action from a fixed list with its own scoped identity. Rules outside the model decide the minimum review: high and critical alerts can't be marked benign, whatever the model says.
Measure today's alert volumes, time to triage and time per alert. Pick three to five high-volume alert types. Agree the read-only tool list and containment boundary with security architecture.
Gate · must be true to passBaseline measured, tool list approved, DPIA started, reporting owners named.
Enrichment, grouping and summaries in shadow mode for the chosen alert types. Analysts work as normal and compare.
Gate · must be true to passMissed true positives and grouping errors within agreed limits, all injection tests contained by the platform, SOC manager signs off.
Summaries and likely-benign marking live for the pilot alert types, with containment drafts and the approved containment workflow.
Gate · must be true to passSupport model in place, analysts trained, agent logs monitored by the SOC, emergency stop tested.
More alert types, longer look-backs through the data lake, and the same pattern for threat hunting notes and post-incident reviews.
Gate · must be true to passEach new alert type passes the same shadow gate; each new tool passes its own security review.
| Activity | CISO | SOC manager | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | SecurityI can fill this | DPO |
|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed |
| Target architecture and tool boundary | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Informed |
| Containment approval rules | Accountable | Responsible | Consulted | Informed | Informed | Consulted | Informed |
| DPIA and reporting owners | Accountable | Consulted | Consulted | Informed | Informed | Consulted | Responsible |
| Build and SIEM and case integration | Informed | Consulted | Accountable | Responsible | Responsible | Consulted | Informed |
| Injection and permission testing | Informed | Consulted | Responsible | Consulted | Responsible | Accountable | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Consulted | Informed |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the alert pipeline, the read-only enrichment boundary, the separate containment path, the integration with your SIEM and case tool, and the gates. I'd work closely with your SOC manager and report to your programme board.
Option B
If your partner or your own team already has an architect, I'd take on the agent, its tool gateway and the integrations under their lead, and give them a second senior opinion on privileged access and on how the design holds up when the alert itself is the attack.
Goes wrong
A malicious file name tells the agent the alert is a test, and it closes it.
How the design avoids it
The agent has no tool to close or downgrade alerts, rules outside the model set the minimum review, and injection tests run before go-live.
Goes wrong
The agent is given an analyst's SIEM account, with rights to edit rules and suppressions.
How the design avoids it
Its own identity, read-only named queries through a gateway, and the account reviewed like any other privileged one.
Goes wrong
Grouping hides a second, separate attack inside a noisy incident.
How the design avoids it
Analysts can split groups, splits are measured, and critical assets are never grouped away.
Goes wrong
Analysts start trusting the summary and stop reading the evidence.
How the design avoids it
Evidence shown beside every summary, a weekly second review, and regular work without the drafts.
Goes wrong
The 72-hour clock for a breach report started days before anyone noticed.
How the design avoids it
Early flags to named owners, with timestamps, and the owners decide when the organisation became aware.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Build reporting thresholds and timers as configuration, and make the agent's draft hold the facts a 24-hour notice will need. If an outside provider runs part of your SOC, check its new duties.
Map the triage agent and its controls to CAF v4.0 now, so the next update is a review, not a rebuild.
If you use Sentinel, build the agent's integration against the APIs and workflows that carry on after the move, not the Azure portal experience.
Build to the interim advice now: the agent's own identity, least privilege, protected logs and a tested emergency stop.
Record the cryptography on the alert feeds, the gateway and the private links, and choose components where it can be updated.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.