TL;DR: AI-native MDR is emerging as a response to rising alert volume, expanding tooling sprawl, and analyst scarcity, with AirMDR describing AISOC as a model where machine-led investigation handles triage, enrichment, and response recommendations while humans retain approvals and accountability. The real shift is not more automation, but a SOC operating model that can scale investigation quality without depending on linear headcount growth.
At a glance
What this is: This is an analysis of how AI-native MDR and AISOC are changing SOC operations by moving investigative work from human-heavy triage to machine-led investigation.
Why it matters: It matters to IAM and security teams because the same governance questions that shape NHI and agentic AI security now appear in SOC workflows, especially around escalation, explainability, and human approval.
By the numbers:
- The managed detection and response market reached $9.6B in 2025 and is projected to reach $46.9B by 2035 (17.2% CAGR), driven by expanding attack surfaces and the global shortage of skilled analysts.
- AirMDR says only ~3% of alerts require human touch in its service model, enabling 24/7 coverage without human fatigue.
Context
AI-native MDR is a response to a simple operational problem: alert volumes keep rising faster than SOC teams can investigate them. Traditional MDR still depends on human triage at scale, which makes consistency, transparency, and speed harder to maintain as environments and telemetry expand. In this article, AirMDR frames AISOC as a new operating model for detection and response.
The identity connection is real because modern SOC investigation increasingly relies on identity telemetry, access events, cloud sign-ins, and privilege signals to explain what happened. For IAM, PAM, NHI, and agentic AI programmes, that means the same governance issues show up in detection workflows: who approved access, what context the system used, and when a machine should escalate to a human.
This is not a pure theory piece. The article starts from a common enterprise starting point, where teams want faster outcomes but cannot staff or standardise the process manually at the level they need.
Key questions
Q: How should security teams govern AI-led MDR when investigation is partly automated?
A: Teams should treat AI-led MDR as a governed decision system, not just an efficiency layer. Define which investigations the machine may complete, which actions require approval, and which cases must always escalate. The control objective is to preserve auditability and accountability while still reducing triage backlog and response delay.
Q: Why do identity signals matter in AI-driven SOC investigations?
A: Identity signals matter because many security decisions depend on who acted, from where, with what access, and whether the behaviour fits the user's normal pattern. Without identity context, an investigation may misclassify benign business activity as malicious or miss privilege abuse hidden inside ordinary-seeming events.
Q: What breaks when AI SOC tools cannot explain their reasoning?
A: Case quality breaks first, then trust, then operational accountability. If analysts cannot see the evidence trail, confidence level, and escalation logic, the SOC may approve actions it cannot defend during audit or incident review. Explainability is therefore a control requirement, not a nice-to-have feature.
Q: Should organisations replace human SOC analysts with AI-native MDR?
A: No. The better model is split accountability, where AI handles repeatable investigation work and humans retain judgement, approvals, and exception handling. That preserves governance while reducing fatigue and improving consistency. Organisations should replace manual process, not human responsibility.
Technical breakdown
What machine-led investigation changes in MDR
Machine-led investigation shifts the SOC from alert triage to evidence construction. Instead of routing every case through a human analyst, the system collects telemetry, correlates identity, endpoint, cloud, SaaS, and network events, and tests hypotheses before deciding whether to escalate. In practice, this compresses the investigative loop and standardises reasoning across cases. The architectural implication is that the AI layer is not just summarising alerts. It is performing the investigative sequence itself, which raises governance requirements around data quality, decision boundaries, and auditability.
Practical implication: define which investigative steps can be machine-executed and which must remain human-approved.
Why explainability matters in AI SOC workflows
Explainability is not a reporting extra in AI SOC. It is the control that makes an AI-driven case defensible. If a platform cannot show the alert, evidence sources, reasoning path, and confidence level, then the SOC may gain speed but lose trust, especially when response actions affect access, accounts, or business operations. That matters for identity-linked events because the system may be interpreting sign-ins, token use, or privilege activity at machine speed. A useful AI SOC therefore needs evidence traceability, not just outcome summaries.
Practical implication: require case records that show evidence sources, reasoning, and escalation thresholds.
How identity and telemetry correlation supports AI-native MDR
Modern SOC correlation depends on joining identity signals with other telemetry types. Authentication events, cloud audit logs, EDR data, network flow logs, and SaaS activity often need to be interpreted together to separate benign automation from suspicious behaviour. That becomes more important as AI systems and service accounts generate more machine activity that looks operational until it is not. The architectural challenge is not ingesting more data. It is preserving context across sources so the system can determine whether a pattern reflects routine access, a misconfiguration, or compromised credentials.
Practical implication: map identity, cloud, and endpoint telemetry into one investigation path before trusting AI-led triage.
Threat narrative
Attacker objective: The attacker aims to hide malicious activity inside high-volume operational telemetry long enough to retain access and complete the compromise.
- Entry begins when attackers exploit compromised credentials or exposed access paths that generate identity signals inside the SOC telemetry stream.
- Escalation follows when those credentials are used to probe cloud, SaaS, or endpoint activity, creating noise that can hide malicious intent inside normal operational events.
- Impact occurs when the SOC fails to separate legitimate automation from abuse quickly enough, allowing credential abuse, data access, or lateral movement to continue.
NHI Mgmt Group analysis
AI-native MDR is not just automation, it is governance of machine-led judgement. Once a platform begins making investigative decisions, the question shifts from workflow efficiency to control design. Security leaders must decide where the machine can conclude, where it can only recommend, and where it must stop. That is especially relevant in identity-heavy investigations, where account context and privilege scope drive response decisions. The practitioner conclusion is simple: AI SOC needs a governance model, not only a detection model.
Machine-led investigation exposes a new operational boundary between observability and accountability. Traditional MDR often fails because it scales analyst labour, not decision quality. AISOC changes that by standardising how evidence is collected and interpreted across cases. The market signal is that buyers now want reproducible case quality and auditable decisions, not just alert coverage. For practitioners, that means evaluating whether the service can show its work when identity, cloud, and endpoint signals intersect.
Identity telemetry is becoming central to SOC outcome quality. The article reflects a broader shift in which access events, sign-ins, and privileged activity are no longer just IAM data. They are core inputs into detection, triage, and response. That creates a named governance gap we can call the investigation trust gap: if the SOC cannot trust how machine reasoning handles identity evidence, it cannot safely automate response. Practitioners should treat identity context as a first-class SOC control surface.
The market is moving toward split accountability, not full autonomy. AirMDR's model reflects a wider pattern in security operations: machines absorb repeatable work, humans retain approvals and exception handling. That is more realistic than trying to remove people from the loop entirely. It also means programme owners must align SOC policy, IAM policy, and escalation policy. The conclusion for teams is that response authority must be explicitly bounded before AI-led investigation can be trusted at scale.
What this signals
AI-native MDR will push more security programmes to formalise decision authority, because the operational question is no longer only what the SOC sees, but who or what is allowed to decide. That affects every identity-connected response path, from account containment to privileged access review. For teams building broader identity governance, the lesson is that machine action needs the same policy discipline as human access.
Investigation trust gap: as AI systems absorb more triage and correlation work, organisations will need a defined boundary between machine reasoning and accountable human approval. That boundary should be tested against identity events, since sign-ins, tokens, and service accounts are often the evidence most likely to shape response. The practical signal is whether the SOC can explain why it acted, not just what it saw.
For practitioners
- Define machine decision boundaries Document which SOC actions AI can recommend, which it can execute, and which require human approval before any account, token, or access action is taken.
- Correlate identity telemetry with SOC cases Ensure authentication logs, cloud audit trails, SaaS activity, and EDR events are available in the same investigation path so the SOC can separate routine automation from compromise.
- Test explainability on identity-linked incidents Review whether the platform can show evidence sources, reasoning steps, and confidence levels for sign-in anomalies, privileged access events, and token misuse.
- Align response approvals with IAM and PAM policy Make escalation and containment rules consistent with account lifecycle, privileged access, and emergency response policy so AI-driven triage does not bypass governance.
Key takeaways
- AI-native MDR is changing SOC delivery by shifting investigation from manual triage to machine-led evidence building.
- The operational value comes with governance demands around explainability, approval boundaries, and identity-aware correlation.
- Teams should evaluate AI SOC tools by how well they preserve accountability, not just by how quickly they close alerts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | SOC telemetry correlation and monitoring sit at the heart of this AI MDR discussion. |
| NIST SP 800-53 Rev 5 | AU-6 | Automated case reasoning and evidence trails depend on auditable review of security events. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0007 , Discovery | The article’s identity-linked SOC use case depends on detecting credential abuse and contextual discovery. |
| NIST AI RMF | GOVERN | AI-led MDR needs clear accountability for machine decision-making and human oversight. |
Map AI SOC workflows to DE.CM-1 and verify telemetry sources cover identity, cloud, endpoint, and SaaS activity.
Key terms
- AI-SOC: An AI-SOC is a security operations model where AI systems help triage alerts, investigate events, and trigger response actions. In practice, it is valuable only when the automation is observable, bounded, and tied to accountable identity and evidence records.
- Machine-led Investigation: Machine-led investigation is the use of AI to gather evidence, correlate telemetry, test hypotheses, and reach a provisional conclusion before a human steps in. It shifts the SOC from manual triage to structured, repeatable case analysis.
- Investigation Trust Gap: The investigation trust gap is the difference between a system that can process alerts quickly and a system that can explain its reasoning well enough to be trusted. In AI SOC contexts, this gap determines whether automation can safely support response decisions.
- Split Accountability: Split accountability is an operating model where AI handles routine execution and humans keep decision authority for approvals, exceptions, and high-impact actions. It is useful in SOC and identity workflows because it preserves governance while reducing manual workload.
What's in the full article
AirMDR's full report covers the operational detail this post intentionally leaves for the source:
- Case-by-case explanation of how AI SOC handles detection, triage, investigation, and escalation in production.
- Examples of what the platform records for audit trails, reasoning traces, and case evidence.
- Implementation detail on how the service connects SaaS, SIEM, EDR, cloud logs, and identity signals.
- Operational distinctions between the platform model and the managed service model.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the policy discipline needed to govern identity-heavy automation across modern security programmes.
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org