What an AI-assisted audit found on a 75-person network in one week
Patching that looked fine but wasn’t. A domain controller nobody could find. A firewall generating six hundred failed logins an hour. None of it was hidden; nobody had had time to look. Here’s what pairing an AI assistant with a remote monitoring platform turned up, how fast it got fixed, and the guardrails that made it safe.
The setup
The company runs about 75 people across production, warehouse and office, on a Windows domain with a handful of servers on a few virtualization hosts, and a cloud-managed firewall. IT is one person with another full-time job. Like most companies that size, it had a remote monitoring and management (RMM) platform sending alert emails that mostly got skimmed.
We connected an AI assistant to three things:
- The RMM platform’s API, read-only: the device inventory, agent status, patch state and vulnerability data.
- Remote PowerShell from one administrator workstation, with a domain admin credential stored encrypted on that machine, so it could query every server and PC directly.
- A person, who approved every change before it was made.
The assistant’s job was the part people skip because it’s tedious: query every machine, compare them against each other, read the logs, and come back with findings and a proposed fix for each.
What it found
Patching was configured, and not working
Updates were driven by Group Policy. On paper, every PC was set to install automatically. In practice, 20 PCs were sitting on Windows versions that no longer receive security fixes, some untouched for over a year, and the policy settings fought each other over restart deadlines. The assistant pulled the build, last update and pending-reboot state from every machine in one sweep and sorted them by risk.
Fix: patching moved to the RMM platform, with a weekly after-hours window for PCs and a separate weekend window for servers. The old Group Policy settings were backed up, then stripped so the two systems couldn’t fight. On the first scheduled run, eleven PCs moved to the current Windows release overnight, and every restart happened after hours.
A domain controller pointed at a server that wasn’t a DNS server
One of the two domain controllers was configured to look up DNS on a server that had stopped being a DNS server years earlier. As a result, every four hours it tried to register itself as a domain controller, and failed. Workstations didn’t know it existed, so every login went to the other controller. Its clock wasn’t syncing with anything, and because Windows couldn’t identify its network, it had applied the strictest firewall profile and was blocking parts of replication.
Nothing was down, so nobody noticed. If the other controller had failed, the company would have found out the hard way. Fix: two DNS settings and two service restarts on a Sunday night, verified with the standard health checks and a test from a workstation.
A firewall hammering the directory
The firewall’s directory login was pointed at a retired server with an old service account, producing roughly 600 failed logins an hour on a domain controller. That’s noise that buries a real attack. Fix: one setting in the firewall dashboard.
A service crashing every six seconds
After an antivirus change, a leftover security sensor component began crashing and restarting every few seconds: more than 27,000 times, and 14,000 error entries a day in one server’s log. Fix: disable the orphaned component, which had nothing left to do.
What nobody was monitoring, and what nobody was using
- A network scan found machines the RMM platform didn’t know about. Twelve got agents, including servers and conference room PCs.
- Directory cleanup: stale administrator accounts, one with domain admin rights and unused since 2018, plus more than a dozen computer accounts for machines long gone.
- A file server nobody used. Before shutting it down, the assistant checked for open sessions, recent file changes, print jobs and licensing roles, and found which PC still had drives mapped to it.
- A server paging itself to a crawl on 4 GB of memory while running a database for software the company had stopped using.
The AI was fastest at the part people skip: checking every machine instead of the three that complained.
The guardrails
Speed is the easy part to sell. What makes it usable on a production network is the discipline around it:
- Read first. Every finding started as a read-only sweep. Nothing changed until the evidence was on the table.
- A person approves every change. The assistant proposes; the administrator decides. Anything irreversible waits.
- Back up before editing. Group Policy objects were exported before they were touched. Old DNS settings were recorded before they were changed.
- Verify after. A change isn’t done when the command succeeds. It’s done when the health check that was failing passes.
- Write it down. Every change went into a running change log with what was changed, why, and how to undo it.
The human in the loop isn’t a formality. Twice, the assistant drew a confident conclusion about how people sign in and why logins were failing, and the administrator, who knows the building, corrected it. The data was right both times; the interpretation needed someone who knew how the company actually works.
What it means for a small company
None of these problems needed a specialist to fix. They needed someone to look at every machine, read the logs, and connect a symptom on one server to a setting on another. That’s exactly the work an IT person with a second job never gets to, and exactly the work an AI assistant does well when it’s given access and supervision.
The result was a week of evenings, not a quarter-long project. The network is patched on a schedule, every device is monitored, and the alerts that do arrive are worth reading.
Related: the new hire got a text from “the owner”, and integration cause vs. symptom.