How AI-Native MDR Handles Incident Response for Mid-Market Teams

What 'AI-native MDR' actually means at mid-market scale

Buying language has drifted faster than the operations it describes. The same RFP still calls the same service an MDR, an MXDR, a managed SOC, and a '24×7 SOC' as if those were interchangeable — they aren't. Mid-market teams that grew up buying analyst headcount now find the buying question is about what an autonomous agent decides on a low-confidence signal at three in the morning, and what evidence is left behind when it decides.

AI-native MDR names the operational shape, not the marketing word. An autonomous triage agent sits in front of the human rota, runs the four-station loop on every signal, writes an audit row before any notification, and escalates to a named human only on the triggers the contract names. The mid-market operator sees this in their portal — the same row the agent writes is the same row the underwriter reads, with an export shape that changes by tier and nothing else.

What runs without a human on the page

Every signal lands in the same four-station loop — Watch, Patch, Contain, Escalate — and the agent runs the first three without paging anyone. The loop is the same regardless of the source: an EDR alert, an identity-graph anomaly, and a SaaS audit event all enter the same queue and reach the same handoff. The agent is not the operator; it is the operator's queue with explicit guardrails around what it may close on its own.

The four-station cycle is described verbatim on pricing page — the language there matches the language used in the portal — and the audit row that each station writes is the only artifact that survives an underwriter review. Out-of-window changes (anything that crosses a maintenance window the customer declared) are not auto-contained: the agent holds the action and surfaces it to a named human for sign-off, rather than acting and writing the row after the fact.

Watch — signal ingest from EDR, identity, and SaaS

Endpoint telemetry, identity-graph state, and SaaS audit events enter the same queue. The agent does not pick a favorite source; the correlation engine treats them as peers so a token revoke that follows a SaaS event surfaces as one incident, not three.

Patch — low-confidence auto-containment

Process quarantine on the host, token revocation where the identity graph allows, and egress restriction on the network path. Each of those is a reversible action: the row that performs it also carries the action it would take to undo it.

Contain — isolation outside the blast radius

The agent does not stop at the host that raised the alert. Where the correlation engine names peer endpoints or peer identities inside the same lineage, containment extends to those peers in the same incident row.

Escalate — hand off to a named human on a named trigger

Three named escalation triggers route to a human: the agent confidence threshold, a governance review (out-of-window or hold-and-review), and a cyber-insurance notification trigger. The handoff row names which trigger fired and where to find the named human on the contract.

Notify — after the row, not before

The audit row is written first; the paging event lands second. The order matters: if the notification could fire before the proof, the proof could be retrofitted to a story rather than recorded as a fact.

Hold — out-of-window changes wait for sign-off

Anything that crosses a maintenance window the customer declared on the portal does not auto-contain. The agent writes the would-be row, marks it held, and surfaces it to the named operator for sign-off — a recorded decision, not a silent skip.

What the audit log records on every action

Every agent action — containment, hold, revoke, escalate, even a no-op close — writes the same row shape. The shape is identical across all three tiers; the export shape is what differs. The log itself is appended-only and Merkle-anchored, the same claim already on the FAQ (Objection 02), so a regulator reading the export yesterday reads the same chain the agent wrote this morning.

Timestamp

UTC, microsecond resolution, taken at row-write — not at notification, not at export.

Actor

Whether the row was written by the agent, by the named operator on the contract, or by the named technician during a declared maintenance window. The actor field tells the underwriter who acted, not who was paged.

Event class

One of a small fixed dictionary (containment, revoke, hold, escalate, notify, close). The dictionary is the same on the contract and on the export — there is no fuzzy "critical event" verb on either side.

Lineage ID

A correlation key that joins every row in the same incident — the same lineage ties the SaaS event, the token revoke, the peer-host quarantine, and the eventual escalation into one readable chain.

Before / after hash

A hash of the affected state before and after the action. Reversible actions carry both halves; the reversal row itself is its own entry, so the underwriter sees what changed, where it changed, and that the change reversed in the same lineage.

Reversal row

If the action is reversed, the reversal writes its own row inside the same lineage. The agent never updates a row in place — append-only is a hard property of the Merkle anchor, not a policy claimed on the marketing page.

What triggers a human escalation

The agent closes most of what it sees on its own. The handoff to a named human is named in the contract, not decided mid-incident. Three escalation triggers route to one of three named humans, and four named cyber-insurance notification triggers fire the audit trail an underwriter reads — the same dictionary already on the FAQ (Objections 03 and 04), so the buyer does not have to translate between the contract and the evidence.

Trigger 1 — confidence threshold

When the correlation engine reports below-confidence on a containment action, the agent writes the held row and pages the named operator for the tier. Above the threshold the agent acts and writes the row; the threshold itself is recorded on the contract, not improvised per signal.

Trigger 2 — governance review

A change that crosses a declared maintenance window, or that lands on the hold-and-review list of risk-tiered patches, is surfaced to the named operator — never auto-contained. The held row stays on the log; the sign-off row is a second row inside the same lineage.

Trigger 3 — cyber-insurance notification

A named insurance-trigger event fires the audit trail the underwriter reads. The four triggers below are the dictionary — anything fuzzier than those four is not in scope, and the underwriter will know it.

Insurance trigger — containment lineage change

A confirmed change to the containment lineage (a peer enters the lineage, a peer exits, or a containment extends) writes a row tagged for the underwriter. The lineage itself is the artifact; the audit tag indexes into the same log.

Insurance trigger — Complete-tier escalation

A Complete-tier escalation is itself an insurance trigger. The named technician on call during a declared maintenance window receives the page; the row is the same row the export will read back tonight.

Insurance trigger — audit anchor divergence

When the published anchor hash diverges from the locally computed hash at any point in the chain, the divergence fires the trigger. The agent does not rewrite history to fix it — the divergence, the page, and the resolution are all rows on the log.

Insurance trigger — identity- or token-graph mutation

A mutation in the identity graph or the token graph (a privilege change, a token revoke, a token issuance outside the baseline) fires the trigger. The mutation row and the resolution row live in the same lineage.

What the customer sees in the portal

The portal reads the same log the agent writes — there is no second source. Each tier changes only the export shape around that log, so a Starter customer can hand the same CSV to a peer and a Complete customer can hand the same CSV plus an attestation pack to an underwriter, without the two ever disagreeing about a row. The named-human matrix is the only other variable: Starter pages a named operator above the confidence threshold with no published SLA; Standard adds a 15-minute acknowledgment SLA on that page; Complete names the technician on call during the maintenance windows the customer declared.

The audit story is the same at every tier; the export shape is what follows the price. A reader who can spot a divergence between the row the agent wrote on Tuesday and the row the operator resolved on Friday will be the same reader whether the customer is on Starter or Complete, and the answer will be the same — the same audit trail the underwriter reads. The full tier-by-tier description is on the pricing page — that page is the source of truth for what runs at each price, and the portal renders to it. The contact page is the route for a buyer who wants a named operator on the contract before the maintenance window is declared.