Identity, endpoints and patching are where sysadmin work carries real blast radius — and where admin copilots, access-review agents and autonomous RMM remediation are arriving fastest. This module teaches the operating pattern for all of them: AI drafts and recommends at scale; the human owns approvals, ring promotions and a sampling audit that catches the dangerous recommendation.
Ravi is an M365 and Entra admin at a Mumbai financial-services firm, eleven years in. In Q2 his company enabled the Entra Access Review Agent for the quarterly recertification — AI recommendations for each of 1,400 access assignments, based on sign-in activity and peer-group analysis, delivered to reviewers in Teams. The pitch was honest: reviewers rubber-stamp recertifications anyway (everyone knows it), so AI recommendations grounded in actual usage data should make the review more rigorous, not less.
Three weeks in, Ravi did what this track had trained him to do with any AI recommendation stream: he pulled a sample of 40 and audited them. Thirty-six were sound — genuinely better-reasoned than the average human rubber-stamp. Three were arguable. And one recommended removing a service account from a privileged group because it had "no interactive sign-in activity in 90 days." Of course it had none: it was a service account. It ran the end-of-day settlement batch through a non-interactive flow the agent's activity model weighted differently. Accepting that recommendation would have failed the settlement run at month-end, in a regulated firm, with the failure surfacing at 2 a.m. as a batch error nobody would connect to an access review for hours.
Ravi rejected the recommendation, documented why, and — this is the part that made his quarter — sent the audit log to the compliance team before they asked. Because the question auditors have started asking about AI-assisted reviews is exactly the one his log answered: who verified the AI?
That is this module in one story. Every surface it covers — joiner/mover/leaver automation, access reviews, admin copilots, patch cycles, agentic RMM — has the same shape: AI takes the volume, and one human habit (the sampling audit, the console verification, the ring decision) keeps the volume from carrying a catastrophe through.
Joiner/mover/leaver is the service desk's most repetitive identity work, and the most consequential to get wrong — a stale leaver account is a standing security hole; a botched mover strands a colleague on day one in a new role. The AI play is not "let an agent provision people." It is: turn your JML runbooks into parameterized scripts and workflows, with AI doing the drafting and the human owning the policy.
Feed the runbook — usually a wiki page of tribal knowledge — to your assistant and have it draft the parameterized implementation: PowerShell/Graph scripts or Entra lifecycle workflows taking role, department, site and manager as inputs, applying Module 4's full review protocol before anything runs. What stays human is everything the runbook never wrote down:
Access requests get rubber-stamped for a structural reason: the approver cannot see what they are approving. "Add Anjali to SG-FIN-APPS-L2" tells a manager nothing about the three nested groups, the finance-app admin role and the shared-mailbox rights that membership actually confers. AI fixes the legibility problem precisely: from Entra/AD exports (or Security Copilot in Entra where licensed), generate a plain-language grant summary — this group confers X, Y, Z, including via nesting; the riskiest item is Y; peers in this role typically hold X only. The decision stays exactly where it was, with the human approver — but now it is informed consent instead of ritual. Desks that deploy this see approval quality rise without adding a minute of approver effort, because the effort was never the bottleneck; the opacity was.
Ravi's story is the pattern, so here is the pattern extracted. AI-assisted recertification — Entra Access Review Agent is the worked example, but the pattern is vendor-neutral — produces recommendations at a scale no reviewer matches. You operate it with the same discipline as Module 1's triage gate, scaled up in consequence:
The dormant-but-critical service account flagged for removal is this domain's signature trap — it appears in Lab 9 and in the AAP-IT assessment because it appears in production. Inactivity data is real, the reasoning is plausible, and accepting it breaks something important weeks later at maximum distance from the cause.
Endpoint administration now ships with a copilot in the console. Copilot in Intune is this module's deep example because it is the most built-out: natural-language device queries, policy-conflict detection, setting explanations ("what does this CSP actually do?"), KQL built from plain English for Advanced Analytics, and agents for triage and vulnerability prioritization — folding into M365 E5 from July 2026, which means Indian enterprises and GCCs will have it by default. The skills transfer directly to Jamf's assistant and RMM-suite equivalents; learn the pattern once, vendor-neutrally.
The operating rule for all of them is a single sentence: the copilot answers from its view; the console is the truth. Copilot output is a hypothesis about your estate, verified the same way Module 2 verified log summaries:
BL-Baseline-v3 and BL-Finance-Override on encryption method — confirmed in the policy report, realTwo minutes of console checking: two findings actioned, one wrong claim caught before it redirected the afternoon.
Used this way, copilots are a large, real win: policy-conflict detection alone finds the misconfigurations that generate weeks of mystery tickets, and natural-language KQL opens Advanced Analytics to admins who were never going to learn Kusto. The failure mode is only ever the same one: treating the copilot's fluent answer as the console's state.
Patching is the sysadmin's highest-stakes recurring change, and it is composed almost entirely of draftable artifacts. Module 2 taught advisory analysis; here is the full cycle:
| Stage | AI drafts | Human owns |
|---|---|---|
| Applicability | Advisory set × asset inventory → what applies, what conflicts, what's urgent | Verify against vendor bulletins; catch the advisory that doesn't apply |
| Pilot ring | Ring composition rationale — coverage of hardware/app diversity without critical-path exposure | Sign off ring membership; know who feels a bad patch first |
| Deployment | Schedules, maintenance-window comms, per-ring success criteria | The go decision per ring |
| Failure triage | Cluster failure logs into probable-cause groups (driver conflict vs disk space vs timeout) | Verify the clusters; decide fix vs defer vs exception per group |
| Exceptions | Exception documentation: device, reason, compensating control, revisit date | Approve each exception; own the risk it records |
| Promotion | Evidence summary from ring telemetry | Ring promotion is a human decision, always |
The promotion rule is the load-bearing one. Everything else in the table is text and analysis where AI errors are caught by review; promotion is the act that turns a bad patch from a pilot-ring incident into an estate outage. The AI assembles the evidence; you read it and decide — and "the copilot said the pilot ring looked fine" will never be an acceptable sentence in a post-incident review.
Vulnerability remediation gets the same treatment with one extra boundary: AI turns scanner output (Defender, Qualys exports) into an effort-ranked, business-aware remediation plan — grouping findings by fix action, flagging quick wins, estimating blast radius. What it does not own is exploitability judgment: whether CVE-2026-XXXX is being actively exploited against your industry is the security team's call, made with threat intelligence you do not hold. Route the prioritized plan to them for that overlay; do not let a language model improvise threat assessment.
Boundary reminder — this module owns desk-and-sysadmin operations. SRE-grade incident automation belongs to the DevOps/SRE track, and SOC-grade security judgment to the security track. Knowing where your AI-assisted output hands off is itself an assessed skill.
The RMM market has split, instructively. Atera ships agentic AI that autonomously remediates device issues — disk space, hung services, common faults — and markets it hard (claiming 500% sales growth in 2025; a vendor figure, treat accordingly). NinjaOne, just as deliberately, has shipped no autonomous agentic layer. Both are rational positions, and the split itself is the lesson: autonomous remediation is a governance decision wearing a product feature's clothes.
If your shop runs (or is evaluating) the autonomous layer, you are its governor, and governance has three concrete duties:
The autonomy-ladder logic from the Common Core applies verbatim: an agent earns wider scope with a clean action-log history, and loses it on wrong-fixes — the scope is a dial you own, not a switch the vendor set.
Two smaller surfaces round out the operations day. Alert clustering: the RMM and monitoring flood — hundreds of alerts, mostly noise, occasionally a pattern — is a clustering problem AI handles well at desk scale: group by probable common cause, summarize for the morning sweep, and leave thresholds and paging judgment human. Change documentation: AI drafts CAB-ready change requests from your implementation notes — description, risk assessment, test evidence, rollback plan — in minutes instead of an hour, raising CAB pass rates for the boring, correct reason that complete documentation gets approved. The risk rating stays yours: the model has no idea that the "routine" switch is the one carrying the trading floor.
Across identity, endpoints and patching, the pattern never changes: AI drafts, summarizes and recommends at a scale you cannot match; you verify at a depth it cannot reach — the sampled audit, the console check, the ring promotion, the rejected removal of the service account that runs settlement. The auditor's question is the whole module: who verified the AI? The answer must always be a name, and the name is yours.