Security teams do not have a detection problem. They have a remediation problem and a communication problem, and those are the two places where AI in security actually pays for itself. A modern scanner will happily hand you 800 findings against a compliance benchmark. The findings are not the hard part. The hard part is that most of them never get fixed, and the ones that do get fixed are invisible to the people who approve the budget. This post is a 101 on the two AI features I think address that directly: automated remediation with an approval gate, and AI-generated reporting for non-technical readers. I will use Aether365, a Microsoft 365 security platform, as the running example. Full disclosure up front: Aether365 is my product. Judge the arguments on their merits.

One principle to hold onto: read-only is the default. Nothing gets write access to your tenant unless you explicitly consent to it, separately.

The two gaps every security scanner leaves open

Run any posture scan against a real Microsoft 365 tenant, CIS benchmark, EIDSCA, CISA ScuBA, and you get the same shape of output: a long list of failed checks with severities attached. Two predictable things happen next.

First, the findings queue outlives everyone's attention span. Each fix means looking up the right admin center, the right PowerShell cmdlet, or the right Microsoft Graph call, then making a change in a production identity system where a mistake locks out actual humans. Multiply by a few hundred findings and the queue becomes a backlog, and backlogs are where findings go to age.

Second, the scan report never leaves the security team. It is written in control IDs and configuration paths. The people who decide headcount and budget see none of it, or they see a compliance score with no story attached. A tenant can sit at 60 percent compliant for a year, and leadership will only learn what that meant during the incident retrospective.

Notice that neither gap is about detection quality. Better detection makes the first gap wider. This matters because most "AI in security" marketing is about detecting more. The interesting work is downstream of detection.

AI Pilot: remediation with a human approval gate

AI Pilot is Aether365's answer to the first gap, and its design is a useful case study in how agentic remediation should work, whoever builds it. The loop has four stages: scan, propose, approve, apply and verify.

The scan produces findings. For each finding, the system generates a concrete fix mapped to the exact Microsoft Graph change it will make, not a prose suggestion, the actual mutation. You then review each proposed change individually and approve or reject it per item. Only approved changes get applied, and each applied change is verified and written to an audit trail.

The 101 lesson here is the permission model, because this is where agentic systems in production either earn trust or lose it. Read-only access is the default and stays the default. AI Pilot requires a separate, explicit Microsoft write-consent connection that you opt into. If you never enable it, the platform physically cannot change your tenant. This is what makes the tool usable for EU and regulated tenants that must remain read-only: the write path is not a toggle inside the app, it is a consent boundary enforced by Microsoft's own authorization layer.

Compare that with the failure mode: a fully autonomous agent with standing write access that fixes things as it finds them. It sounds efficient until it "fixes" a Conditional Access policy at 2 a.m. and the on-call engineer cannot sign in to see why. Autonomy without a per-change approval gate turns a remediation tool into an unaudited admin with infinite patience. The gate is not a limitation of the AI. It is the feature.

Business Impact Reports: the translation layer

The second gap is communication, and this is the least glamorous, most defensible use of LLMs in security today. Language models are genuinely good at one thing that security tooling has always been bad at: translating a technical state into a narrative a non-technical reader can act on.

Business Impact Reports take the raw scan findings and produce a board-ready document: a plain-language executive summary, what the compliance score means for the business, which business units carry the most risk, a prioritized do-this-first roadmap, and a mapping of findings to GDPR, NIS2, and ISO 27001 obligations. It is generated in any of 24 languages, which matters more than it sounds: a CFO in Munich gets the report in German while the security team works in English, from the same scan data.

Two caveats belong in any honest 101. The report is only as good as the scan underneath it; an LLM narrating bad data produces confident nonsense with page numbers. And AI-generated reporting needs a clear data-handling stance. Aether365's is: your scan data is never used to train or fine-tune any model, AI runs only to generate your report in the moment, and the whole thing stays under human oversight, aligned with the EU AI Act. Whatever tool you pick, demand those answers in writing.

A 101 checklist for any AI security feature

Strip the branding and evaluate any "AI plus security" feature with five questions:

  • Is write access opt-in and separately consented? Read-only by default is table stakes. A separate write-consent path is the real test.
  • Can I approve every change individually? Batch approval of 300 changes is a rubber stamp, not a gate.
  • Is there a verified audit trail? Applied is not the same as verified. You want both, per change.
  • Does the AI make decisions or presentations? AI that drafts fixes and reports for human approval is low risk. AI that acts unattended on identity infrastructure is not.
  • Is my data used for training? If the answer takes more than one sentence, the answer is yes.

AI Pilot and Business Impact Reports are, to me, the honest version of AI in security: the model does the tedious mapping and the translation, humans keep the authority. Detection was never the bottleneck. Fixing and explaining were, and that is exactly where this generation of tooling should aim.

Read this next

For the infrastructure side of this story, why a Microsoft 365 tenant should be treated like any other cloud estate, see Checking Cloud with Cloud: M365 Security Posture Scanning 101 at ercan.cloud. For consulting on AI, cloud, and platform work, or just to say hello, start at ercanermis.com.

References