AI Plugin Vulnerabilities
94% Detection Rate. 56 Hours of False Positive Investigation. 23 Missed Anomalies. None of It in the Dashboard.
7 min read · 20 July 2026 · AI governance
A manufacturing company deployed an AI-powered network security monitoring product from a specialised vendor , a system that used machine learning to detect anomalous network traffic and generate security alerts for analyst investigation. The vendor's headline metric was a 94% detection rate across their test dataset. The enterprise had run a proof-of-concept that had caught several simulated attack scenarios and had been satisfied with the product's performance. After production deployment, the system generated seventeen alerts over fourteen days. Three were genuine security incidents , a misconfigured server, a compromised workstation, and a lateral movement attempt. Fourteen were false positives. Investigating all seventeen consumed sixty-two analyst hours. The three real incidents were exactly the type the vendor's training and test dataset had emphasised. What the model had not flagged were twenty-three anomalies that a senior analyst noticed while reviewing a summary traffic report two weeks later , WMI remote execution from unusual sources, legitimate admin tool abuse, and low-and-slow reconnaissance patterns that were individually within normal bounds but collectively indicative of a long-dwell attacker using living-off-the-land techniques. Those techniques had not been in the training dataset. The model's confidence threshold had not flagged them. The dashboard showed 94% detection rate throughout. The twenty-three missed anomalies were invisible in every reported metric.
What are AI Security Plugin Vulnerabilities, Really?
AI plugin vulnerabilities in the context of AI-powered security tools are the structural blind spots and operational limitations of machine learning-based detection systems , not failures in the technology's implementation, but inherent constraints of how supervised machine learning works that create systematic gaps between published detection metrics and real-world security coverage. These gaps arise because ML models perform well on inputs similar to their training data and poorly on inputs outside it, because adversaries specifically adapt to avoid detection patterns, and because false positive rates impose operational costs that reduce the analyst capacity available to compensate for the AI's limitations.
The training distribution gap is the foundational limitation. Every ML-based security product is trained on a dataset of labelled examples , attack patterns classified as malicious, benign activity classified as normal. The model learns to detect patterns similar to what it was trained on and struggles with patterns that are dissimilar. The 94% detection rate in the vendor's test dataset measures performance against test data drawn from the same distribution as the training data. It does not measure performance against techniques that are genuinely novel, that were underrepresented in training, or that were specifically designed to avoid the model's learned detection logic. The headline metric and the real-world coverage gap are both real , they just measure different things.
The living-off-the-land technique blind spot is a specific and well-documented training distribution gap in AI network security products. Living-off-the-land attacks use legitimate administrative tools , WMI, PowerShell, PsExec, certutil, Mshta , to perform malicious operations in ways that are statistically similar to legitimate administrative activity. A model trained to detect malicious network patterns by statistical difference from benign patterns will struggle with LOTL techniques precisely because the individual signals are within the range of legitimate activity. LOTL detection requires correlating multiple individually-within-range signals over time , a task that challenges models trained on individual event classification.
The adversarial adaptation mechanism amplifies the training gap over time. Sophisticated threat actors research the detection tools deployed by their targets and adapt their techniques to avoid them. A model that is known to detect specific network patterns because its vendor has published its detection logic will be evaded by attackers who use alternative patterns. The training data that was current at model development becomes progressively less representative of the techniques sophisticated adversaries are actually using. The detection rate metric, measured against the original test dataset, remains stable while the model's real-world effectiveness against current adversary techniques decreases.
The false positive cost problem is the operational consequence that compounds the detection gap. AI security products that generate significant false positive alert volumes impose investigation burdens on analyst teams , every false positive alert requires analyst time to investigate and close. That time comes from the analyst capacity that would otherwise be used for manual threat hunting, traffic review, and the human-generated analysis that compensates for the AI's blind spots. A model that generates fourteen false positives per seventeen alerts consumes fifty-six analyst hours investigating noise , exactly the hours that might have caught the twenty-three anomalies the model missed.
Why this matters
AI security plugin vulnerabilities matter for TPRM because AI-based security monitoring is increasingly positioned as the primary detection layer , replacing or significantly reducing human analyst review. When vendors deploy AI security products as their primary detection capability, the gaps in those products' coverage become the enterprise's exposure. A vendor whose AI security product has a 94% detection rate and is systematically blind to living-off-the-land techniques has a significant detection gap for the class of attacks that sophisticated supply chain adversaries specifically favour.
The displacement risk is the specific supply chain concern. If the vendor's AI security product replaces analyst capacity rather than supplementing it , if the analyst team that previously reviewed traffic manually has been reduced because the AI handles detection , the net effect of the AI deployment may be reduced security coverage for technique categories the AI does not detect well. The AI has not increased coverage. It has shifted coverage toward the techniques it detects well and away from the techniques it does not.
Where most teams get this wrong
The most consistent failure is accepting the detection rate headline metric without assessing the technique scope of the test that produced it. The metric is accurate for that scope. The scope determines whether the metric is meaningful for the threat landscape the vendor actually faces.
- Detection rate accepted without test dataset scope assessment
- False positive rate not assessed as operational cost , analyst hours required
- Living-off-the-land coverage not specifically evaluated
- Adversarial evasion testing not conducted , does the AI detect attacks designed to avoid it
- Human analyst complement not defined for AI coverage gaps
What good looks like
Mature AI security product evaluations assess three detection categories alongside false positive rates: known attack patterns from the training distribution, novel techniques outside the training distribution, and adversarially designed evasion attempts , establishing real-world coverage beyond the headline metric.
- Three-category assessment , known, novel, and adversarially designed evasion techniques
- LOTL technique coverage explicitly evaluated , WMI, PowerShell, admin tool abuse detection
- False positive rate as operational cost , analyst hours per month at production alert volume
- Human analyst complement specified , what manual analysis compensates for AI gaps
- Adversarial evasion red team , red team with explicit AI evasion objective
Tooling
AI Security Evaluation , MITRE ATLAS adversarial ML, Atomic Red Team for LOTL detection validation
MITRE ATLAS provides a framework for adversarial machine learning threat assessment , including techniques specifically designed to evade AI-based detection. Atomic Red Team provides test implementations of ATT&CK techniques including LOTL patterns that can validate whether a security product detects them. For TPRM practitioners, asking whether the vendor's AI security product has been evaluated against MITRE ATT&CK LOTL techniques using Atomic Red Team tests provides a specific real-world coverage question.
Network Security , Darktrace, Vectra, ExtraHop with explicit LOTL and behavioural anomaly coverage
Network security AI products vary significantly in their coverage of living-off-the-land and low-and-slow reconnaissance techniques. Products that specifically focus on behavioural baselines and correlated multi-signal anomaly detection are better suited to LOTL detection than products optimised for high-volume known-pattern classification. For TPRM practitioners, asking how the vendor's AI network security product specifically detects LOTL techniques , and requesting a demonstration using Atomic Red Team LOTL test cases , provides a concrete coverage evaluation.
Governance challenges
The governance challenge with AI security product limitations is the metric confidence problem. High detection rate metrics create confidence in the AI's coverage that may not be warranted for the specific techniques the enterprise is most concerned about. The governance resolution is technique-specific coverage assessment , evaluating the product's coverage for the specific attack patterns relevant to the enterprise's threat model, not just the aggregate metric.
- Assess technique-specific coverage against the enterprise's threat model
- Evaluate LOTL detection capability explicitly , it is a common sophisticated attacker TTP
- Calculate false positive operational cost , analyst hours at production volumes
- Define human analyst complement , what AI cannot cover, human analysis must
- Conduct adversarial evasion assessment , MITRE ATLAS framework
If you are a small team
For any AI security product evaluation, ask two questions that the vendor demo will not answer. First: is your test dataset's technique coverage public , and does it specifically include living-off-the-land patterns and adversarially designed evasion techniques? Second: at an enterprise of our size and network complexity, what is the expected false positive rate per month , and how many analyst hours does that imply? The first reveals the coverage gap. The second reveals the operational cost. Together they describe the real-world security coverage the product provides.
- Ask whether test dataset includes LOTL and adversarial evasion techniques
- Ask for production false positive rate and implied analyst hours at your scale
- Conduct Atomic Red Team LOTL test during proof of concept
- Define human analyst complement for identified coverage gaps
What to require
Ask directly:
"Does your AI security product's test dataset specifically include living-off-the-land techniques and adversarially designed evasion patterns , and at an enterprise of our scale, what is the expected monthly false positive volume and analyst hours?"
Expect as evidence
- Test dataset technique coverage scope
- LOTL and adversarial evasion coverage confirmation
- Production false positive rate at comparable enterprises
- Human analyst complement guidance
A vendor who confirms 94% detection rate should be asked for the technique scope that produced it. The metric is accurate for the scope. The scope determines what the metric means for real-world coverage.
How to evidence it
- Test dataset scope assessment records
- LOTL technique coverage evaluation
- False positive rate and analyst cost assessment
- Human analyst complement documentation
Key Takeaway
94% detection rate. Seventeen alerts. Three real. Fourteen false positives. Fifty-six analyst hours. Twenty-three missed LOTL anomalies. Not flagged. Not in the dashboard. The detection rate was real for the training distribution. The missed anomalies were real for the techniques outside it. The false positive investigation consumed exactly the analyst hours that manual traffic review would have used to find the missed twenty-three. AI security products do not eliminate the need for human analyst judgment , they redirect it. Test the technique scope. Calculate the false positive cost. Define the human complement. The 94% metric describes the AI's coverage for what it was trained to detect. The three-category assessment describes its coverage for what the adversary is actually using.
Speak to It™
The term you nodded along to, explained in ninety seconds, so you can speak to it professionally. It is how most readers find these articles.
Join the Association