In my last post I wrote about how AI has changed day-to-day perimeter work: policy cleanup, onboarding new services, all the documentation around a change. This time I want to talk about the part of the job where speed matters most: the moment something looks wrong and you need to know, right now, whether it's real, how far it went, and what to block.
If you read Ken Phelan's recent post, Twenty-Three Hours, you already know the story. We patched our remote-access gateways on a Saturday, and about 23 hours later, the attackers showed up. Ken's point was that the patch wasn't the end of it. When attackers exploit vulnerabilities before the fix even exists (the time-to-exploit trend he covers in his AIMO post, Remember the PMO? Meet the AIMO), every critical patch comes with a homework assignment. Were we hit before we patched? Did anything land? Did anything phone home?
Ken wrote about why that homework has to become routine. This post is about how we got through it fast, from the engineer's chair.
Threat hunting has always been a data problem. The evidence is almost never in one place. It's split across firewall logs, the load balancer or VPN appliance, the endpoint tool, the identity provider, email, and whatever threat intel feed you trust. The hard part isn't knowing what to look for. It's pulling all those sources together fast enough to mitigate the threat.
What MCP Actually Changes
The piece that's made the biggest difference for me lately is the Model Context Protocol, or MCP. In plain terms, MCP is an open standard that lets an AI assistant connect directly to tools and data sources through small connector services, called MCP servers. Instead of copying log exports into a chat window, the assistant can query the systems themselves: the firewall management API, the log server, the ticketing system, documentation, even email and Teams threads where the first report came in.
For example, you ask the AI assistant, "has this IP address touched anything in our environment in the last 30 days?" The AI then runs the log queries, pages through the results, and comes back with an answer and the evidence behind it.
The Homework, Hour by Hour
The morning after the patch, the gateway flagged two exploitation attempts on its login page, a minute apart. Someone was trying to get it to run commands and download a script from an outside server. Both failed; the patch held. But the logs gave us a handful of indicators, a few IP addresses and a domain, and the real question was whether those addresses showed up in our logs before we patched.
The old way would have been: open the log viewer, manually search each IP, export results to a spreadsheet, then figure out which rule let the traffic in. Realistically, a couple of hours before you had a clear picture.
With an AI assistant connected to firewall management and log APIs, the workflow looked like this:
- Check every indicator at once. The domain and IPs were searched across 30 days of firewall logs in one pass, with hits grouped by source, destination, service, rule and time.
- Correlate across sources. The firewall hits were lined up against the appliance's own log timestamps. Two of the attacker addresses showed up connecting to the appliance on HTTPS in the exact minute of the injection attempt, allowed by the inbound web rule, which confirmed the log entry was real traffic, not noise.
- Widen the net. From there it found earlier connections from related addresses in the days before the patch, including the reconnaissance sweep Ken mentions, and a separate address scanning the firewall's own VPN services. Those are the patterns that turn a single alert into a campaign.
- Answer the most important question. Had anything inside reached back out to those addresses? A 30-day outbound check came back clean. Nothing phoned home. Given the clean outbound and gateway-side checks, we closed the incident with no evidence of compromise.
- Go straight to containment. The same session produced block objects and rules, with naming and comments tied to the incident and change ticket, plus the emergency change plan and incident write-up.
Start to finish, we went from "the appliance flagged something" to "confirmed, scoped, and blocking rules staged for review" in well under an hour. And a few hours later, when a new indicator came in from the team, checking it and adding it to the block list took minutes, not another round of manual searching.
Correlation Is the Real Win
Speed is nice, but the real value is in correlation. Individually, none of these data points are conclusive. An IP hitting your VPN on 443 is normal. A command-injection string in an appliance log could be a scanner. Put them next to each other on a timeline with the rule that allowed the traffic and the absence of any outbound callback, and you have a decision you can defend.
AI is superior at that assembly work:
- Joining events from different systems on time, IP and user, even when each system formats them differently.
- Converting everything into one time zone so the timeline actually lines up (sounds small; it isn't).
- Spotting the "also saw this" patterns: related subnets, earlier reconnaissance, the same source hitting multiple services.
- Summarizing it into something a manager or a client can read in two minutes.
Guardrails: How We Keep This Safe
Giving AI access to production security tools warrants caution, so the approach must be specific:
- Read-only by default. Hunting and log queries run with read-only API accounts. The assistant can look, not change.
- A human decides and pushes the button. When a block is needed, the AI can stage and publish objects and rules for review, but installing policy on the gateways stays a manual step after an engineer has verified the rule.
- Change control still applies, even in an emergency. Every change carries the ticket number, the incident date and a clear name, so the audit trail tells the story on its own.
- Secrets stay out of the conversation. API keys live in protected storage, not in notes, prompts or documents.
- Know the limits. Log platforms have query timeouts and retention windows. When a search can't cover the full range, say so plainly rather than treating "no results" as "no activity."
Where This Is Going
The tools are moving fast. Security vendors are starting to publish their own MCP servers, which means the list of things an AI assistant can query directly keeps growing: firewalls, EDR, SIEM, identity, cloud. The teams that wire those sources together, with the right guardrails, will be able to answer, "are we affected?" in minutes instead of hours.
None of this replaces an experienced analyst. Knowing which indicator matters, when a pattern looks wrong, and what the business can tolerate still requires judgment. But when the searching, correlating and paperwork happen at machine speed, the analyst gets to spend their time on the decisions.
That's the practical side of Ken's argument. If every critical patch really is a possible breach, the "were we hit before?" check can't be a two-day project that only happens after something scary. With retained logs, connected tools, and AI doing the heavy lifting, it becomes a routine you can run every time. And a routine you've run a dozen times is exactly what you want on the day it counts.