Introduction: the autonomous SOC marketing gap
SOC vendors in 2026 attach "agentic" and "autonomous" labels to products that range from chat summarisation over alerts to policy-bounded endpoint isolation. Buyers cannot compare offerings because there is no shared definition of what was automated, what evidence was produced, who approved it, or what happens when the automation is wrong.
CISOs need a maturity model that answers a different question: which outcomes can your SOC deliver repeatedly, under policy, with audit evidence and rollback — and which are still aspirational?
This article introduces the AiRAT Five-Level Agentic SOC Maturity Model, the pillar framework for AiRAT's security operations cluster. It connects to AI-compressed attack timelines, SOC automation and evidence auditability and threat-informed detection engineering.
Last verified: 3 August 2026
Direct answer: An agentic SOC matures through five levels, Level 0 (fragmented manual operations) to Level 4 (bounded autonomy), where only low-risk reversible actions run automatically and everything higher-risk stays approval-controlled. Score maturity across fifteen dimensions — evidence, rollback, agent governance — not by counting AI features on a vendor's datasheet. Level 4 is the ceiling by design: there is no Level 5, because fully autonomous unsupervised response is not a goal this model rewards.
Why "autonomous SOC" is an imprecise buying term
| Vendor claim | What it might actually mean |
|---|---|
| "AI-powered SOC" | Alert summarisation only |
| "Agentic investigation" | Enrichment scripts with an LLM wrapper |
| "Autonomous response" | One reversible playbook, no evidence schema |
| "Closed-loop SOAR" | Actions without rollback or approval latency measurement |
Without a maturity model, procurement optimises for demos — not operational resilience. The model below is falsifiable: each level has entry criteria, exit criteria and metrics.
How to use the maturity model
- Self-assess current level per dimension (see scoring table below).
- Identify the binding constraint — the lowest-scoring dimension caps effective maturity.
- Set target level — most regulated enterprises should target Level 3 minimum, Level 4 for high-volume SOCs with evidence infrastructure.
- Progress one level per planning cycle — skipping levels produces automation theatre.
- Re-assess quarterly — maturity decays when detections rot, staff turnover erodes runbooks, or vendor changes break playbooks.
Level 0 — Fragmented and manual
Profile: Analysts pivot across consoles. No agreed incident evidence model. Automation is isolated or absent.
- Telemetry — gaps across cloud, SaaS, endpoint
- Triage — fully manual; no standard case record
- Response — ad hoc; no response class policy
- Evidence — screenshots, chat threads
- Metrics — MTTD unreliable; no approval latency data
Exit criteria to Level 1: Unified case management; minimum evidence fields defined; AI assist pilot on summarisation only.
Level 1 — Assisted triage
Profile: AI summarises alerts and retrieves context. Humans make every decision and action. Evidence quality and analyst time are measured.
- Summarisation — grounded in linked telemetry, with hallucination checks
- Retrieval — asset, user and threat-intel context pulled into the case automatically
- Human gate — 100% of actions human-initiated, no exceptions
- Measurement — analyst minutes per case; summarisation acceptance rate
Exit criteria to Level 2: Deterministic enrichment automated; correlation rules version-controlled; detection engineering practice established.
Level 2 — Orchestrated investigation
Profile: Deterministic enrichment and correlation run automatically. AI forms hypotheses and recommends next steps. No unapproved production actions.
- Enrichment — automated WHOIS, asset and threat-intel lookups, each with source attribution
- Correlation — rule-based, tested in CI like any other production logic
- Hypothesis — AI-assisted, but an analyst validates before any action is taken
- Boundary — probabilistic (AI) and deterministic (rule-based) stages stay clearly separated
Connects to the AiRAT Defender Time Budget — Level 2 compresses enrich and hypothesise stages under human validation.
Exit criteria to Level 3: Response class policy (A/B/C) published; in-console approval; reversible playbooks in dry-run.
Level 3 — Approval-controlled response
Profile: Agents prepare and execute actions after explicit approval. Action scope, rollback and evidence are enforced. Human decision latency is measured.
- Prepare-execute — the agent drafts an action; a human approves it in-console before it runs
- Evidence — pre/post state, policy version and approver ID captured on every action
- Rollback — tested for every approved action class, not assumed to work
- Metrics — approval latency (P50/P95) and false-containment rate, tracked continuously
SOC automation and evidence auditability defines the evidence primitive Level 3 requires.
Exit criteria to Level 4: Class A reversible actions proven in production; kill switch tested; policy engine enforces scope.
Level 4 — Bounded autonomy
Profile: Low-risk, reversible actions execute automatically. Higher-risk actions remain approval-controlled. Continuous policy enforcement, kill switches, rollback and post-action verification are mandatory.
- Class A automation — reversible actions only, and only when evidence-complete
- Policy engine — runtime scope enforcement, not tribal knowledge encoded in a playbook
- Kill switch — organisation-wide disable, tested quarterly, not just documented
- Post-action verify — automated confirmation, with rollback on failure
- Agent governance — tool permissions scoped per agent, with explicit delegation limits
This is the target operating state. Level 4 is not "fully autonomous." Destructive, customer-visible and wide-blast-radius actions remain Class B or C per policy.
There is no Level 5. Rewarding unsupervised destructive automation would misalign incentives with regulatory and operational reality.
Maturity dimensions and scoring
Score each dimension 0–4 matching the level definitions above.
| Dimension | Level 0 | Level 2 | Level 4 |
|---|---|---|---|
| Telemetry coverage | Major gaps | Core sources ingested | Comprehensive + validation |
| Data normalisation | None | Common schema | Entity-resolved |
| Detection quality | Noisy / stale | Peer-reviewed rules | Continuous tuning + retirement |
| Correlation | Manual | Automated deterministic | Cross-domain automated |
| Enrichment | Manual | Automated deterministic | Automated + AI-assisted hypothesis |
| Case management | Fragmented | Unified | Unified + evidence schema |
| Identity and access | Ad hoc | RBAC on SOC tools | JIT; agent identities scoped |
| Agent / tool governance | N/A | Inventory started | Permission envelopes enforced |
| Response automation | None | Dry-run playbooks | Class A in production |
| Human oversight | Implicit | Documented gates | Policy-encoded; measured latency |
| Observability | Siloed logs | SIEM-centric | Full pipeline metrics |
| Evidence and audit | Screenshots | Structured fields | Immutable store; legal hold ready |
| Rollback | Rare / untested | Tested in staging | Quarterly production drills |
| Evaluation | None | Tabletop exercises | Continuous purple validation |
| Operating model | Hero analysts | Documented runbooks | Metrics-driven; automation-off drills |
Overall maturity level = median dimension score, unless any safety dimension (evidence, rollback, human oversight, agent governance) scores below 2 — in which case cap reported level at 2 until remediated.
Five-level maturity matrix (summary)
| Level | Name | Automation scope | Human role | Evidence | Target org |
|---|---|---|---|---|---|
| 0 | Fragmented manual | None | All work | Ad hoc | Starting baseline |
| 1 | Assisted triage | Summarise / retrieve | All decisions | Basic case notes | SOC AI pilot |
| 2 | Orchestrated investigation | Enrich / correlate | Validates hypothesis | Source attribution | Detection-led SOC |
| 3 | Approval-controlled response | Prepare actions | Approves execution | Pre/post state | Regulated enterprise |
| 4 | Bounded autonomy | Class A reversible | Oversees policy | Immutable audit | High-volume mature SOC |
Self-assessment: 20 questions
Answer yes/no. Count yes responses; interpret alongside dimension caps.
Evidence and audit (1–5)
- Can the SOC reconstruct every automated decision from structured logs?
- Does every automated closure include a reason code and policy version?
- Is evidence stored in an immutable or WORM-capable store?
- Can you produce a complete case pack for audit within one business day?
- Are legal hold procedures integrated with SOC evidence storage?
Agent and automation governance (6–10)
6. Are tool permissions scoped per agent or playbook — not shared admin?
7. Are containment actions reversible with a tested rollback?
8. Is analyst approval latency measured and reported?
9. Has the automation kill switch been tested in the last quarter?
10. Are deterministic enrichment steps separated from probabilistic AI reasoning?
Detection and operations (11–15)
11. Do detection rules have owners, versions and last-tuned dates?
12. Are false containment events tracked and reviewed weekly?
13. Can the platform prove which evidence supported each response action?
14. Has the SOC operated without automation successfully in the last quarter?
15. Are noisy rules retired with documented rationale?
Multi-tenant and safety (16–20)
16. Can one tenant's data enter another tenant's investigation context? (Answer no for yes-point)
17. Is MTTD measured per severity tier — not organisation-wide average only?
18. Are Class A/B/C response rules written and legal-reviewed?
19. Does purple team validation feed a prioritised detection backlog?
20. Is recommendation acceptance rate for AI hypotheses tracked?
Interpretation (guidance, not a certified score):
| Yes count | Indicative level |
|---|---|
| 0–5 | Level 0–1 |
| 6–10 | Level 1–2 |
| 11–15 | Level 2–3 |
| 16–19 | Level 3 |
| 20 (with safety dimensions ≥3) | Level 4 candidate |
Apply dimension cap rule before declaring Level 4.
Metrics by maturity level
| Metric | L1 target direction | L4 target direction |
|---|---|---|
| Alert duplication rate | Decreasing | Low stable |
| Analyst minutes per case | Measured | Decreasing without quality loss |
| Enrichment completeness | >80% fields | >95% automated |
| Evidence completeness | Partial schema | Full schema every case |
| Recommendation acceptance rate | Tracked | Stable; bias-reviewed |
| False closure rate | Tracked | Near zero |
| Approval latency | N/A | P95 within policy |
| Automated containment rate | 0% | Class A only; measured |
| Rollback success | N/A | Tested quarterly |
| Policy violation rate | N/A | Tracked; near zero |
| MTTD / MTTR | Baseline | Improving on high severity |
Measure against your own baselines — do not treat these as industry benchmarks.
90-day progression plan (example: Level 2 → Level 3)
| Month | Milestone |
|---|---|
| Month 1 | Publish Class A/B/C policy; define evidence schema; baseline approval latency |
| Month 2 | Deploy in-console approval; dry-run reversible playbooks; kill switch test |
| Month 3 | Promote first Class B playbook to production; time-budget exercise; re-assess dimensions |
Advancing to Level 4 requires proven Class A track record at Level 3 — typically a subsequent 90-day cycle.
Common failure modes
- Feature-count maturity — symptom: Level 4 claimed the week an AI module is purchased. Mitigation: score all fifteen dimensions, not the vendor's own label.
- Skip-level deployment — symptom: autonomous containment enabled with no evidence trail behind it. Mitigation: enforce entry and exit criteria per level, no shortcuts.
- Probabilistic overreach — symptom: the AI executes actions without a deterministic boundary. Mitigation: enforce the Level 2 separation rule between probabilistic and deterministic stages.
- Approval theatre — symptom: approval gates exist but function as rubber stamps. Mitigation: measure approval latency and sample-audit real decisions.
- Metric gaming — symptom: noisy alerts get auto-closed to make the numbers look good. Mitigation: track false-closure rate as its own metric.
- Automation dependency — symptom: a SOAR outage stops the SOC from functioning at all. Mitigation: run quarterly automation-off drills.
- Tenant bleed — symptom: one customer's context leaks into another's investigation in an MSSP setting. Mitigation: review isolation architecture directly, don't assume it holds.
Key takeaways
- Maturity is measured by repeatable, policy-bound outcomes with evidence and rollback — not AI feature count.
- Levels 0–4 progress from fragmented manual operations to bounded autonomy; there is no Level 5 "fully autonomous."
- Fifteen dimensions score telemetry, detection, enrichment, response, agent governance, evidence, rollback and operating model.
- Level 3 (approval-controlled response) is the minimum credible state for most regulated enterprises; Level 4 is the target for high-volume SOCs.
- Self-assess with twenty yes/no questions; apply safety dimension caps before declaring maturity.
- Progress one level per 90-day cycle with explicit entry and exit criteria.
Frequently asked questions
What is an agentic SOC?
A security operations centre that uses AI agents for triage, investigation and — at higher maturity — policy-bounded response, with human oversight, evidence and rollback encoded in the operating model.
What are the levels of SOC automation maturity?
AiRAT defines five levels (0–4): fragmented manual, assisted triage, orchestrated investigation, approval-controlled response, and bounded autonomy. Each has defined automation scope and evidence requirements.
Is an autonomous SOC fully automated?
No — and it should not be. Level 4 bounded autonomy automates only low-risk reversible actions. Destructive, customer-visible and wide-impact actions require human approval or human-led response.
Which SOC actions can safely be autonomous?
Deterministic enrichment, correlation, ticket documentation, and Class A reversible containment (e.g. non-production isolation) — with evidence, rollback and kill switches. Production isolation and account disable require approval.
How do you measure AI value in a SOC?
Track analyst minutes per confirmed incident, enrichment completeness, approval latency, false closure rate, recommendation acceptance rate, and rollback success — not raw alert volume closed.
What is bounded autonomy?
Automation that operates within explicitly policy-defined boundaries: reversible actions only, evidence-complete, kill-switchable, with higher-risk tiers escalated to humans.
How can a SOC move from manual triage to agentic response?
Progress level by level: unify evidence (0→1), automate deterministic enrichment (1→2), implement approval-controlled response (2→3), then prove Class A reversible automation (3→4). Skipping levels creates unsafe gaps.
Sources
- AiRAT, SOC automation and evidence auditability (internal framework reference): https://airat.in/blog/soc-automation-evidence-auditability
- European Central Bank, Letter on AI-enabled cybersecurity threats (2026): https://www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2026/ssm.2026_letter_on_AI_enabled_cybersecurity_threats.en.pdf
- NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
- MITRE ATT&CK for ICS / Enterprise — detection planning: https://attack.mitre.org/
- SANS SOC Survey (structural reference for SOC operating models): https://www.sans.org/white-papers/
Related: AI-compressed cyberattack timelines · SOC automation and evidence · Threat-informed detection engineering · SOC product · ADR · Hawkeye platform · Enterprise XDR · Methodology · Services · Resources
