The past 12 months have been a gold rush for AI-powered security tooling. New frameworks, new protocols, new agent architectures — all promising to finally automate the work of detecting and neutralizing malware at scale.
 
Most of them are solving the wrong problem.
 
 

The Seductive Architecture

 
There’s a pattern that’s become almost universal in AI security tooling right now: connect an LLM to a set of tools via an agentic framework, point it at a threat, and let it reason its way to a conclusion. The model calls a tool to fetch file contents, calls another to check a reputation database, calls another to correlate against known signatures, and eventually — after several round trips — renders a verdict.
It’s elegant. It’s demonstrable in a conference talk. And in a production malware detection scenario, it can get you killed.
 
 

The /dev/shm Problem

 
Here’s something every hosting provider’s security team should understand cold: modern WordPress malware doesn’t wait around.
 
A sophisticated dropper hits the filesystem, writes a second-stage payload to memory (/dev/shm is a favorite — it’s a RAM-backed tmpfs, no disk writes, survives many detection sweeps), establishes persistence, and begins exfiltrating credentials or enrolling the server in a botnet. This entire sequence can complete in seconds.
 
If your detection pipeline is busy making round-trip API calls — fetching file contents here, checking a CVE feed there, waiting on an LLM to finish reasoning through three tool responses — the attacker’s second stage is already running before your first stage verdict comes back.
 
Latency isn’t a performance problem in this context. It’s a threat model failure.
 
 

The Right Architecture Is Tiered, Not Flat

 
The teams that are actually staying ahead of this aren’t building monolithic AI agents. They’re building latency-tiered pipelines where each layer has an explicit job:
 
Millisecond tier — Deterministic, no LLM involvement. YARA rules, regex pattern matching, checksum verification against known-clean baselines. This catches the known bad immediately. If you’re not catching the majority of threats here, your signature set needs work before your AI story does.
 
Second tier — Local, fast LLM reasoning for the ambiguous cases. Small models running on-premise, guided by carefully constructed context that encodes expert knowledge about obfuscation patterns, WordPress-specific attack surfaces, and severity heuristics. No network round-trips. This is where “I’ve never seen this exact pattern but something is clearly wrong” gets handled.
 
Third tier — Deep analysis via larger models for novel, complex, or high-confidence threats that warrant the latency trade-off. This is where you pay for reasoning, not reflex.
 
Enrichment tier — This is where agentic tool-calling and MCP-style architectures shine. Cross-referencing threat intelligence feeds, correlating against historical abuse data, triggering remediation workflows, filing structured reports. By the time you reach this layer, the threat has already been neutralized. Now you’re building the case and closing the loop.
 
 

What Changed in the Last Year

 
Twelve months ago, the conversation was mostly about whether LLMs could detect malware at all. That question is largely settled — yes, with the right framing, they add genuine signal, especially on novel obfuscation and logic-level vulnerabilities.
 
The conversation now is about where in the pipeline that signal belongs. And the teams shipping real results have learned, often painfully, that the answer is: not at the front.
 
The frameworks have matured too. MCP in particular has gone from an interesting spec to a genuinely useful tool for the enrichment and action layer — but it’s a coordination protocol, not a detection engine. Treating it like one is an architecture mistake that will cost you.
 
 

The Takeaway for Hosting Providers

If you’re evaluating security tooling for your WordPress fleet, the right question isn’t “does it use AI?” It’s “where does the AI live in the detection chain, and what’s the measured latency at each stage?”
 
Any vendor who can’t answer that second question with real numbers — and who can’t explain why their architecture wouldn’t lose to a /dev/shm persistence trick — is selling you a demo, not a defense.
The threat actors are not waiting on your tool calls to finish.