AI Phishing Detection Benchmarks: A Practical Framework for Datasets, Metrics, Models, and Real-World Evaluation

Published phishing detectors routinely report accuracy above 99%, yet credential theft and invoice fraud continue to reach employee inboxes at scale. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports in any category. That gap between laboratory performance and live exposure is what AI phishing detection benchmarks exist to close, and what most of them currently fail to close.

The failure is rarely a modeling failure. A curated corpus with balanced classes, recycled phishing kits, and randomly assigned splits rewards a model for recognizing templates it has already seen. Change the base rate, the language, the hosting provider, or the collection month, and the same detector produces alert volumes no security operations team can absorb. This guide covers:

• How AI phishing detection benchmarks define scope, unit of analysis, and label taxonomy before any score is comparable;
• Which datasets support AI phishing detection benchmarks, and what their provenance, class balance, and channel coverage exclude;
• How leakage controls, holdout designs, and scraping audits keep an AI phishing detection benchmark honest;
• Which ranking, thresholded, calibration, and latency metrics an AI phishing detection benchmark must publish together;
• How rule-based systems, classical models, neural networks, embeddings, and large language models compare under matched conditions;
• Where AI phishing detection benchmarks stop measuring protection, and where employee behavior and cybersecurity awareness training take over.

Detection scores collected in a laboratory rarely survive contact with a live inbox. Adaptive Security tests AI-generated phishing against employees and email infrastructure in the same environment.

Book a demo

What Do AI Phishing Detection Benchmarks Actually Measure?

AI phishing detection benchmarks are reproducible evaluations of a model's ability to distinguish phishing intent from benign content under defined data, labels, class priors, timing, and deployment constraints. They describe how a detector performs against one specified test set. They do not describe whether an organization is protected from every phishing attempt reaching production.

Results depend on the unit of analysis, the campaigns included, how uncertain cases are labeled, and whether a human analyst participates in the decision. A precise benchmark vocabulary therefore has to come before any comparison of results. Detection accuracy can describe a URL classifier, an email classifier, a webpage vision model, or an analyst-assistance workflow, and those systems answer materially different security questions.

What Do Benchmark Scope and Unit of Analysis Mean?

Benchmark scope defines the object being evaluated and the boundary around the decision. A URL benchmark scores individual links, while a webpage benchmark evaluates the rendered page, HTML, scripts, forms, branding, redirects, or visual appearance. An email benchmark evaluates a message, often including sender identity, headers, subject, body text, embedded URLs, and attachments, and a multimodal benchmark combines several of those signals at once.

The unit of analysis matters because one campaign can produce several records. A single credential-phishing operation might contain one sender address, three URLs, two redirect chains, and hundreds of near-identical messages. If a benchmark splits those artifacts randomly between training and test sets, the model can encounter campaign fingerprints in both groups, so its score reflects memorization rather than generalization to new phishing intent.

A credible AI phishing detection benchmark separates related campaigns, domains, time periods, or organizations whenever the evaluation claims to measure performance on unseen attempts. It should also identify its sampling frame, because publicly submitted phishing URLs, corporate email telemetry, laboratory-generated messages, and user-reported incidents represent different populations. Class priors deserve equal attention, since a test set with 50% phishing messages is convenient for model development but bears no resemblance to an inbox where benign mail dominates.

Timing creates a further boundary. Random offline testing asks whether the model can classify known examples, time-split testing asks whether it can detect campaigns that appear after the training period, and streaming evaluation adds operational pressure through a fixed latency budget and incomplete threat intelligence. A 2025 evaluation of phishing email detection methods published in Applied Sciences demonstrates why testing frameworks, datasets, and comparative conditions matter more than a single headline score.

Why Are Scores From Different AI Phishing Detection Benchmarks Not Comparable?

Two detectors can both report 97% accuracy while answering unrelated questions, so AI phishing detection benchmarks must be normalized before any ranking is meaningful. Normalization starts with the evidence available at decision time. A model that receives a full message object, sender history, and rendered destination page holds far more information than a model scoring a bare link inside a browser extension.

The second normalization axis is position in the attack path. Blocking a credential harvester before delivery, warning a user at click time, and confirming compromise after credential entry are three separate control points with different tolerances for error and different costs attached to a miss. A score earned at one control point does not transfer to another, even when the underlying corpus is identical.

The third axis is the human role. Fully automated classification, analyst-assisted triage, and user-reported review produce different effective accuracy, because a workflow that surfaces the most dangerous reports first can outperform a higher-scoring model that buries them. Any comparison that omits the human role is measuring model output instead of decision quality.

Score transfer fails in a fourth way that benchmark tables rarely expose. A detector tuned for a consumer browser population inherits that population's brand mix, language distribution, and traffic composition, none of which match a regulated enterprise with concentrated vendor relationships. According to the Anti-Phishing Working Group's Phishing Activity Trends Report, 1st Quarter 2025, nearly one million phishing campaigns were observed in the first quarter of 2025 alone, and no single corpus samples that volume evenly across brands, regions, or delivery channels.

Does a Benchmark Measure Phishing Intent or Merely Suspicious Content?

Phishing intent is an attempt to manipulate a target into taking an action that benefits the cyberattacker, such as disclosing credentials, transferring funds, opening a payload, or revealing sensitive information. Suspicious content is a much broader category. It can include unsolicited marketing, bulk spam, a legitimate account notification, an unfamiliar sender, a malformed attachment, or a message that violates local policy without attempting to deceive the recipient.

That distinction separates phishing from adjacent categories:

• Spam is primarily unwanted or unsolicited communication, and it can be disruptive without seeking credentials, money, or access;
• Malware delivery centers on malicious code or exploit execution, and although a malware-bearing message can also be phishing, the two labels answer different questions;
• Fraud describes deceptive financial or identity-related conduct, some of it conducted through phishing and some through compromised accounts, forged documents, or offline channels;
• Suspicious content is a triage category for uncertainty, signaling that further review is needed before phishing intent has been established.

A benchmark that labels every malicious URL as phishing and every benign message as safe erases these distinctions. It should instead identify the requested action, the target asset, the deception mechanism, and the evidence supporting the label. A message asking an employee to update payroll details differs materially from a promotional email even when both contain a link, and a legitimate password-reset notice can resemble credential phishing at the surface level until authentication evidence resolves it.

Generative AI raises the stakes on intent-centered labeling because grammatical quality no longer functions as a dependable signal. A polished message can be benign, fraudulent, or part of a business email compromise (BEC) attempt. AI phishing detection benchmarks should therefore test whether the detector recognizes the requested behavior and relationship context without rewarding it for catching spelling errors and a narrow list of suspicious phrases.

Why Do Offline Scores Differ From Operational Protection?

Offline scores summarize performance on a fixed dataset. Accuracy measures the share of correct decisions, but it conceals a dangerous imbalance whenever benign samples outnumber phishing samples. Precision measures how many flagged items are actually phishing, recall measures how many phishing items the detector catches, and false-positive rate, false-negative rate, calibration, area under the precision-recall curve, and decision latency supply the remaining context.

Operational protection begins after the score. A detector must receive timely, representative data, classify unfamiliar campaigns, fit inside email, browser, or analyst workflows, and produce an action that reduces exposure. That action might quarantine a message, warn a user, route a report to a security team, or trigger organization-wide remediation.

An AI phishing detection benchmark should therefore disclose thresholds, latency, retraining rules, access to external reputation data, and the cost assigned to missed phishing against unnecessary intervention. Deployment conditions can reverse a leaderboard ranking outright. A detector optimized for recall may catch more campaigns while generating an alert volume analysts cannot review, and a conservative detector may reduce disruption while allowing more dangerous messages through.

Human review improves difficult cases while introducing queue length, expertise variation, and inconsistent labeling, so a fair comparison reports the operating point and the surrounding workflow instead of one maximum score. Phishing detection research on human-in-the-loop evaluation published in 2025 illustrates why analyst participation and model performance should be evaluated together whenever a system is designed for operational use.

Without a recorded operating context, two impressive scores can measure entirely different capabilities. That same vocabulary creates the discipline needed to assess phishing simulations and human responses across attack channels, because machine detection and employee decision-making protect different points along the same attack path.

Measuring a detector without measuring the employees behind it leaves the largest exposure unquantified. Adaptive Security scores both machine detection and human response inside one cybersecurity awareness training platform.

Explore the platform

Which Datasets Are Used in AI Phishing Detection Benchmarks?

AI phishing detection benchmarks compare datasets that differ more in provenance and operating assumptions than in file format. Manually verified URL corpora prioritize label quality, while automated phishing feeds supply scale and freshness alongside unresolved duplicates, takedowns, and ambiguous pages. No corpus represents every phishing channel equally, so a webpage benchmark cannot stand in for email classification, vishing, smishing, or employee exposure.

Two public collections illustrate the trade-off. The LegitPhish dataset description documents a manually assembled URL corpus built for supervised learning, and the PhreshPhish release provides a cleaned webpage corpus with realistic base-rate variants. Selecting between them depends on whether the evaluation needs label traceability, collection recency, or channel breadth.

What Determines Dataset Provenance and Label Quality?

Provenance establishes what an AI phishing detection benchmark actually measures. Manually verified URL corpora begin with threat intelligence feeds, analyst review, or both, while automated collections begin with services that identify suspected malicious infrastructure. A label can mean reported, confirmed, active when observed, or matched to a known campaign, and those states are not interchangeable.

The LegitPhish documentation reports 63,678 phishing URLs and 37,540 legitimate URLs within a listed total of 101,219 entries. Those class counts sum to 101,218, so researchers should preserve the source's reported figures while documenting the one-entry discrepancy without presenting the total as exact. The phishing URLs were drawn from URLHaus and comparable repositories, the legitimate URLs from sources including Wikipedia and Stack Overflow, and the release adds URL-focused features such as length, entropy, token count, subdomain count, HTTPS presence, and suspicious file extensions.

Researchers should inspect the LegitPhish feature inventory and labeling description before treating its labels as ground truth. Manual verification improves traceability. It does not remove sampling bias, source bias, or the inherent limits of URL-only detection.

Automated phishing feeds serve a different purpose. They capture campaign velocity and emerging infrastructure, and they also carry operational noise. A phishing page can disappear before collection, redirect to a legitimate site, present different content by geography or user agent, or display a takedown notice in place of the original page, and a benchmark that keeps the original feed label after the page changes will penalize a model for correctly classifying the content it actually received.

PhreshPhish addresses that problem through browser-based collection, automated filtering, deduplication, and human inspection. According to OpenText's PhreshPhish: A Real-World, High-Quality, Large-Scale Phishing Website Dataset and Benchmark 2025, benign URLs were drawn from anonymized browsing telemetry covering more than six million global Webroot users together with searches for heavily targeted brands, and phishing URLs came from PhishTank, the Anti-Phishing Working Group eCrime eXchange, and Netcraft. That combination produces a stronger real-world webpage suite than a corpus assembled from one blacklist, though it still represents the collection pipeline and the accessible subset of pages instead of every campaign on the internet.

Synthetic, rephrased, and templated samples belong in a separate category. They support controlled experiments because researchers can vary urgency, brand names, spelling, language, or HTML structure while holding other variables constant. They remain weak substitutes for live samples when the goal is deployment realism, since a detector trained mainly on synthetic pages learns a generator's stylistic fingerprints in place of the behavioral and infrastructure signals that distinguish phishing from legitimate content.

How Do Sampling and Class Balance Change AI Phishing Detection Benchmarks?

Class balance changes the meaning of precision, alert volume, and operational usefulness. A balanced corpus makes training and statistical comparison convenient, and it also makes a detector appear more effective than it will be once phishing becomes rare among all pages a user visits. The LegitPhish collection carries a large phishing share, which suits supervised learning and feature comparison while disqualifying it as a standalone estimate of production alert precision.

PhreshPhish presents the opposite interpretive risk if volume is mistaken for representativeness. Its cleaned corpus contains 247,584 phishing samples and 366,201 benign samples, yet a large corpus can still overrepresent particular feeds, campaigns, hosting providers, brands, countries, or collection windows. Scale improves statistical power without guaranteeing coverage.

The same release separates its broad dataset from its benchmark variants, and the separation is the useful part. Rather than shipping one test set, it applies temporal partitioning, similarity-based leakage filtering, difficulty filtering, diversity enhancement, and base-rate adjustment to produce families of benchmarks that stress a detector at different prevalence levels.

The published rates make the pressure explicit. According to OpenText's PhreshPhish: A Real-World, High-Quality, Large-Scale Phishing Website Dataset and Benchmark 2025, the full benchmark carries a 24% phishing base rate while five additional benchmark families use rates of 5%, 1%, 0.5%, 0.1%, and 0.05%, producing 975 benchmark datasets in total.

That design exposes a common weakness in AI phishing detection benchmarks. Accuracy and receiver operating characteristic area under the curve can remain impressive when a test set contains equal numbers of phishing and benign pages, while precision collapses as benign traffic dominates. Security leaders should require average precision, precision at a fixed recall, false-positive rate, alert volume, and confidence calibration across several base rates, because a benchmark reporting only one balanced split answers a narrow research question rather than an operational one.

Sampling design carries the same weight as sample size, because a corpus assembled without regard to campaign boundaries can score a model on material it has effectively already seen.

How Do Dataset Age, Language, Brand, and Attack Vector Affect Coverage?

Coverage determines which signals a model learns and which campaigns remain invisible to an AI phishing detection benchmark. A dataset collected years ago rewards obsolete URL patterns, old HTML conventions, and discontinued hosting behavior, while a very recent feed can overrepresent a short-lived operation. PhreshPhish was collected across 17 months, from July 2024 through December 2025, and its documentation acknowledges that inaccessible, cloaked, or rapidly removed pages remain harder to capture.

Language and script coverage require separate reporting. LegitPhish documentation identifies a concentration on English and Latin-script domains, noting that non-English and region-specific URL patterns receive less representation. A detector evaluated primarily on English pages should not be described as multilingual merely because its model accepts Unicode, and researchers should publish language, country, top-level-domain, and script distributions for both classes.

Brand and industry coverage shape results just as strongly. A corpus dominated by financial institutions tests account-login impersonation well while missing cloud administration, payroll, healthcare portals, shipping providers, education systems, government services, and business-to-business invoice fraud. Brand repetition creates another leakage path, because a model can memorize logos, domain tokens, page titles, or familiar templates whenever the same organization appears in training and testing.

Attack-vector coverage marks the sharpest boundary of all. URL and webpage corpora test a campaign's destination instead of its delivery mechanism, whereas phishing-email corpora measures sender, subject, body, attachment, and link behavior. Benign webpage datasets supply legitimate controls, though Common Crawl-style collections differ considerably from the pages users encounter through email, search, advertising, or mobile applications.

Real-world webpage suites test rendered page content and URL signals, and synthetic or rephrased samples test controlled variation. Neither category evaluates vishing, smishing, QR-code phishing, or deepfake impersonation without separate voice, SMS, image, or video data. Security teams should match each benchmark to the channel they intend to defend without treating webpage performance as evidence of organization-wide human-layer protection.

What Documentation Should Accompany an AI Phishing Detection Benchmark?

Dataset documentation is part of the benchmark instead of administrative paperwork attached to it. Every release should state collection dates, source feeds, crawl methods, rendering environment, geographic vantage points, label definitions, reviewer procedures, deduplication rules, split logic, base rates, and known exclusions.

Without that record, another team cannot determine whether a reported performance gain reflects better modeling or easier data. A defensible documentation package should cover:

• Consent and lawful access: Explain whether telemetry, browsing data, submitted URLs, or page content were collected under user consent, contractual authorization, or a documented public-interest basis;
• Licensing and redistribution: Identify permissions for URLs, HTML, screenshots, logos, text, feed records, and derived features, and separate research access from commercial reuse;
• Takedowns and corrections: Provide a process for removing compromised legitimate sites, honoring legal notices, correcting labels, and versioning affected splits without silently changing published results;
• PII removal: Strip query parameters, session identifiers, names, email addresses, phone numbers, tokens, credentials, and customer-specific paths, then document residual-risk testing after removal;
• Dual-use controls: Assess whether raw HTML, active links, screenshots, phishing kits, or brand-specific samples could help cyberattackers improve evasion, and apply access controls, defanged URLs, delayed release, or feature-only publication where appropriate;
• Reproducibility: Publish hashes, schemas, label taxonomies, collection code where safe, benchmark-generation rules, and fixed evaluation scripts.

The practical standard is a documented combination of complementary datasets with explicit limitations. A credible AI phishing detection benchmark pairs manually verified labels with fresh feed samples, temporal splits with leakage controls, realistic base rates with balanced training data, and webpage evidence with email and multi-channel tests.

No public webpage corpus covers voice, SMS, or QR-code lures, which leaves entire channels untested. Adaptive Security runs phishing simulations across email, voice, and SMS in one program.

Take a self-guided tour

How Should AI Phishing Detection Benchmarks Prevent Leakage and Sampling Bias?

AI phishing detection benchmarks require a leakage-resistant protocol before any model score carries meaning. The sequence is straightforward: normalize and deduplicate records, isolate related pages across training and test sets, evaluate under multiple holdout designs, and audit scraping quality before publishing anything. A reproducible benchmark measures performance under declared conditions, and it does not by itself prove that one model is superior to another.

The stakes are visible in dataset quality audits. According to OpenText's PhreshPhish: A Real-World, High-Quality, Large-Scale Phishing Website Dataset and Benchmark 2025, applying one two-stage cleaning pipeline to two widely used public collections removed 65.5% and 43.8% of their phishing samples as mislabeled or corrupted, against a 0.97% rejection rate on PhreshPhish itself. Scores produced on uncleaned corpora inherit that error rate directly.

1. Remove Duplicates Before Splitting the Data

Random splitting is unsafe whenever records are not independent. The same URL can appear with tracking parameters or different capitalization, and the same domain, impersonated brand, campaign, kit, HTML template, or near-identical landing page can appear on both sides of the split. A detector that recognizes a repeated template is being rewarded for memorization.

Canonicalize URLs for comparison while preserving the original value for auditability. Remove tracking parameters, normalize casing where appropriate, resolve redirects, and record the registrable domain separately from the full URL. Compare page titles, visible text, DOM structure, URL tokens, embedded assets, and brand indicators, then treat a shared campaign or template as a group in place of unrelated observations.

Use locality-sensitive hashing (LSH) to find approximate duplicates at scale. Hash TF-IDF representations of HTML, URL character n-grams, or DOM features, then compare candidates with cosine similarity or another declared distance measure.

LSH is a screening mechanism rather than a final labeling decision, so inspect representative prototypes from the largest similarity groups, remove confirmed scrape failures and duplicate families, and propagate each decision to nearest neighbors. This workflow keeps manual review practical while preventing one mislabeled page from contaminating an entire cluster.

2. Apply Holdout Splits That Match the Deployment Risk

A single random split hides several forms of leakage at once. Build multiple named evaluation sets instead, and publish the grouping key, cutoff date, similarity threshold, and record-removal rule for each one. The PhreshPhish benchmark paper (2025) applies temporal separation followed by similarity filtering, then increases difficulty and diversity without accepting a random test set as realistic by default.

Use at least four complementary splits:

• Temporal holdout: Train on earlier collections and test strictly on later collections, which tests adaptation to new campaigns, infrastructure, and cyberattacker tactics;
• Domain-held-out split: Keep registrable domains or hosting clusters exclusive to one partition, which tests whether the detector generalizes beyond familiar infrastructure;
• Campaign-held-out split: Group records by campaign, kit, feed event, redirect chain, or analyst-defined incident, then hold out entire groups so multiple pages from one operation cannot appear across partitions;
• Brand-held-out split: Reserve selected impersonated brands for testing, which measures whether the model detects phishing behavior without relying on memorized brand-specific artifacts.

Do not collapse these results into one headline score. Report performance by split, class, base rate, and threshold, then state which holdout best represents the intended deployment. A model that leads on a random split while failing on unseen domains has not demonstrated broad phishing detection capability.

3. Treat Scraping Failures as Data-Quality Failures

A retrieved page is not automatically a valid example. Takedowns replace a phishing page with a hosting-provider notice, cloaking serves benign content to a crawler, CAPTCHA blocks collection, geofencing returns region-specific content, JavaScript rendering hides the page body, and HTTP 4xx or 5xx errors produce empty or misleading records. Each of those failures creates mislabeled phishing samples or class-dependent artifacts that inflate scores.

Record response codes, redirect chains, timestamps, user agent and region, rendering status, page title, content length, and capture method. Use a real browser for JavaScript-heavy pages, retry transient HTTP failures, and mark inaccessible pages as unresolved without forcing a binary label. Review samples showing takedown language, CAPTCHA interstitials, access-denied pages, suspended-domain notices, or unexpected redirection to a legitimate brand site, and preserve failed records in a quarantine table so another researcher can reproduce every inclusion and exclusion decision.

4. Run an Audit Before Publishing Benchmark Scores

A benchmark audit belongs in the dataset release rather than an informal final check. Maintain row-level provenance and a versioned data card, then verify each of the following before any score is published.

• Class balance: Report phishing prevalence overall and within every split, domain, brand, and time window, and evaluate realistic base rates separately from convenience-balanced sets;
• Mislabeled records: Sample both classes for human review, prioritizing records with conflicting feed labels, redirects, missing HTML, or strong similarity to the opposite class;
• Outliers: Inspect extreme URL lengths, enormous pages, unusual languages, repeated error pages, and records using rare protocols or encoding;
• Missingness: Quantify missing HTML, screenshots, titles, domains, timestamps, and rendering metadata by class and partition, ensuring that missingness itself does not become a label shortcut;
• Easy examples: Remove or separately report near-duplicate pages, obvious takedown banners, empty responses, and samples that multiple baseline models classify with near certainty for superficial reasons.

Publish the preprocessing code, random seeds, split assignments, similarity thresholds, exclusion counts, and benchmark versions alongside the results. These controls make the outcome reproducible and expose uncertainty honestly. They do not establish model superiority, because superiority requires a prespecified comparison across identical data, metrics, compute constraints, and leakage-resistant holdouts.

Teams extending this protocol to employee-facing phishing simulations should separate scenario templates, campaign waves, and evaluation cohorts before measuring behavioral change. A credible benchmark reports what the model was prevented from seeing, which records were discarded, and how closely the test environment matches deployment.

Recycled templates inflate benchmark results the same way recycled phishing simulation scenarios inflate employee readiness scores. Adaptive Security generates fresh AI-driven lures for every single campaign wave.

Book a demo

Which Metrics Should AI Phishing Detection Benchmarks Report?

AI phishing detection benchmarks should pair threshold-free ranking quality with thresholded operational performance, because no single score describes how a detector behaves in production. ROC-AUC and average precision evaluate performance across decision thresholds, while precision, recall, specificity, and false-positive rate describe one selected operating point. Accuracy looks deceptively strong whenever phishing is rare, so credible benchmarks report ranking, classification, calibration, latency, and uncertainty together.

Threshold-Free Versus Thresholded Metrics in AI Phishing Detection Benchmarks

Threshold-free metrics show how well a model separates phishing from legitimate content before an organization selects an action threshold. ROC-AUC measures the probability that a model ranks a randomly selected phishing item above a randomly selected benign item, plotting the true-positive rate against the false-positive rate at every threshold. It supports broad ranking comparisons while concealing poor performance at the extremely low false-positive rates browsers and enterprise gateways require.

Average precision summarizes the precision-recall curve across recall levels. Precision answers how many flagged items are actually phishing, and recall, also called sensitivity or true-positive rate, measures how much of the phishing population the detector catches. Average precision is often more informative than ROC-AUC when phishing is rare, because it concentrates on positive-class performance and the cost of false alerts.

A benchmark should publish the full precision-recall curve alongside average precision. It should also report precision at 90% recall, written as P@R=0.90, which shows how many flagged items are truly phishing once the detector is configured to catch 90% of known phishing examples. A model with higher average precision and weak P@R=0.90 will disappoint any security team that requires dependable coverage.

Thresholded metrics describe performance at a chosen cutoff:

• Accuracy: Correct predictions divided by all predictions;
• Precision: True positives divided by all positive predictions;
• Recall: True positives divided by all actual phishing items;
• Specificity: True negatives divided by all legitimate items;
• False-positive rate: One minus specificity;
• False-negative rate: One minus recall;
• F1 score: The harmonic mean of precision and recall, calculated as 2 × precision × recall divided by precision plus recall.

These metrics answer different operational questions. A browser warning or blocking system must keep false positives extremely rare, because an incorrect block interrupts legitimate work. An enterprise gateway can set a different threshold when it quarantines messages for review, provided the benchmark reports quarantine volume, analyst workload, and remediation time alongside the error rates.

Consider an illustrative test set of 100,000 messages at a 0.05% phishing base rate, the lowest prevalence published in the PhreshPhish benchmark family. The set contains 50 phishing messages and 99,950 legitimate messages, so a detector with 90% recall catches 45 phishing messages while a 1% false-positive rate flags 999 legitimate ones. Accuracy reaches 98.996% and precision falls to 4.3%, leaving employees and analysts with roughly 22 false alarms for every correctly identified phishing message.

Holding the model constant and changing only the class mixture inverts that picture entirely: at a 5% phishing rate, the same 90% recall and 1% false-positive rate produce 4,500 true positives against 950 false positives, lifting precision to 82.6% without any improvement in the detector. Benchmarks must therefore disclose prevalence, publish confusion matrices, and avoid presenting accuracy as the headline result.

Calibration and Confidence Intervals in AI Phishing Detection Benchmarks

Calibration measures whether a model's confidence scores correspond to observed outcomes. If a detector assigns a probability of 0.8 to 1,000 messages, roughly 800 should be phishing for the model to be well calibrated. A model can rank examples correctly while remaining poorly calibrated, which causes an automated workflow to treat a 0.95 score as more certain than the evidence supports.

Benchmarks should publish reliability diagrams, calibration error, and calibration curves across score bands. They should also distinguish a ranking score from a probability, because a raw neural-network output is not automatically a trustworthy probability. Post-hoc methods such as Platt scaling and isotonic regression belong on data held separate from the training set.

Every headline metric should carry a 95% confidence interval estimating how much the result could vary across comparable samples. Bootstrap resampling fits average precision and F1, while binomial intervals describe recall, specificity, and false-positive rate. At a 0.05% base rate, a small test set can contain too few phishing examples to support a narrow interval, so the number of positive and negative examples belongs beside every result.

Calibration also determines how a detector should act. A browser can apply a high-confidence block threshold and display a warning below it, and an enterprise gateway can quarantine medium-confidence messages for analyst review. A confidence score without calibration, prevalence, and a defined action policy does not demonstrate reliable detection.

Statistical Significance, Repeated Runs, and Uncertainty Reporting

An AI phishing detection benchmark should distinguish a genuine performance improvement from random variation. A 0.3 percentage-point difference in average precision establishes nothing when confidence intervals overlap substantially or the result shifts across samples. Report paired comparisons on the same test items, confidence intervals for the difference, and a statistical test suited to the metric, such as bootstrap comparison or DeLong's test for ROC-AUC.

Models with randomized training, sampling, or prompting require repeated runs. Use fixed data splits for fair comparison, repeat training with multiple random seeds, and report the mean, standard deviation, and range. Benchmark construction should likewise repeat resampling at each base rate without publishing one favorable sample, and stratified bootstrap intervals should preserve phishing prevalence, because randomly removing rare positive examples distorts the result.

Uncertainty extends well beyond model training. Document label disagreements, duplicate pages, temporal drift, leakage controls, language distribution, attack family, and collection date. A detector trained on old URLs can score well against near-duplicates while failing against a current campaign, so temporal holdouts, similarity filtering, and family-level separation test whether the model generalizes beyond memorized templates.

Operational reporting should treat detection latency as a distribution rather than an average. Publish median, 95th-percentile, and worst-case latency from input arrival to verdict, along with feature-fetch and inference time. Browser-based protection is generally expected to return a verdict within a few hundred milliseconds, and enterprise gateways can support slower enrichment while messages remain held before delivery, provided every result is measured on representative production hardware and network paths including timeouts and unavailable reputation services.

What Should a Complete AI Phishing Detection Benchmark Report?

A credible AI phishing detection benchmark publishes the operating context before the score. Reporting only the winning metric gives no basis for a deployment decision, and it prevents another team from reproducing the comparison. At minimum, the report should cover the following five categories.

• Data and prevalence: Collection period, label process, phishing base rate, positive and negative example counts, temporal split, and leakage controls;
• Ranking quality: ROC-AUC, average precision, and the complete precision-recall curve;
• Decision quality: Precision, recall, F1 score, specificity, false-positive rate, false-negative rate, and precision at 90% recall;
• Deployment behavior: Selected threshold, calibration results, median and 95th-percentile detection latency, timeout handling, and browser or gateway assumptions;
• Uncertainty: Confidence intervals, repeated-run results, random seeds, paired significance tests, and subgroup performance.

Use false-positive rate as the primary guardrail for browser blocking, with a strict target set by the organization's tolerance for interrupted legitimate work. For enterprise gateways, pair false-positive rate with quarantine volume, analyst review time, and the cost of missed phishing in place of applying a browser threshold unchanged.

A phishing simulation and detection program should track reporting behavior, response time, and channel-specific outcomes without relying on completion or accuracy alone. These measures turn benchmark performance into evidence that a control works under the conditions employees and analysts actually face.

Precision collapses at real phishing prevalence, which buries analysts under false alarms nobody has time to clear. Adaptive Security triages reported messages automatically and escalates only genuine cyber threats.

Explore the platform

Which Models and Features Perform Best in AI Phishing Detection Benchmarks?

AI phishing detection benchmarks should compare model families against the same data, labels, features, and deployment constraints. Rule-based systems encode known indicators directly, while statistical, neural, embedding, and language models learn patterns from examples or context. Naive Bayes and logistic regression are fast and auditable, whereas Random Forest, gradient methods, neural networks, and BERT-style models capture more complex relationships at greater computational cost.

Zero-shot, few-shot, and quantized local LLMs add contextual reasoning and natural-language explanations without automatically outperforming a tuned classifier on matched test data. The meaningful winner depends on whether the benchmark prioritizes recall, false-positive control, latency, explainability, adversarial resilience, or performance across new datasets. Declaring that priority in advance prevents the comparison from becoming a search for the metric that flatters a preferred model.

How Do Model Families Compare in AI Phishing Detection Benchmarks?

Model-family performance changes sharply with the input representation, so the table below assumes each family is evaluated on the input it was built for. A URL-only classifier, an email-text classifier, and a multimodal webpage detector solve different problems, and their scores cannot be compared as though the families were interchangeable.

For structured URL and webpage data, gradient boosting and Random Forest deserve a serious baseline before any neural model enters the comparison. A 2024 explainable-AI study of phishing URL detection titled Can Features for Phishing URL Detection Be Trusted Across Diverse Datasets? found XGBoost leading its within-dataset comparisons with Random Forest close behind, then observed sharp declines when models trained on one dataset were tested on another. A near-perfect score on a random split can therefore measure memorization of source-specific artifacts in place of durable detection ability.

Embedding models change the terms of the comparison. According to OpenText's PhreshPhish benchmark results, a fine-tuned GTE embedding model reached an average precision of 0.605 at the punishing 0.05% base rate, while a zero-shot large language model on the same benchmark reached 0.100. Fine-tuning on in-domain data mattered far more than model scale.

RNNs process sequences in order, which suits character-level URLs, email wording, and HTML token streams, and CNNs detect local patterns such as suspicious character groups, repeated URL structures, or short textual phrases. ReLU activation keeps positive signals and supports efficient training, though inactive neurons can stop contributing entirely. Leaky ReLU preserves a small negative slope (typically ≈ 0.01), which can improve gradient flow and optimization in some architectures. In a 2025 comparison of recurrent phishing‑email detectors, a bidirectional GRU model optimized with Leaky ReLU achieved a best accuracy of 98.77% (AUC 0.9987) on an 83k‑email corpus; however, that study did not report a same‑architecture standard‑ReLU baseline at 98.75%, and broader 2025 results show only small, context‑dependent margins between activation functions, so no universal activation‑function winner can be claimed.

BERT-style models and embedding models shift the comparison from manually counted indicators toward semantic representation. They can recognize that a request to "verify the payroll account" and one to "confirm direct-deposit details" express the same intent even when the exact tokens differ. That advantage becomes less decisive whenever a benchmark contains only short URLs, weak labels, duplicated domains, or artifacts a tree model can memorize.

Zero-shot and few-shot LLMs are best treated as contextual reviewers rather than automatic replacements for lower-latency classifiers. They can inspect sender claims, page language, requested action, and internal inconsistencies together, and quantized local models reduce data-exposure and infrastructure concerns. A 2025 comparison of quantized LLMs and classical phishing detectors reported that supervised machine-learning and deep-learning models exceeded the tested small LLMs in raw accuracy while the local LLMs supplied useful explanations, which supports routing routine cases through fast classifiers and reserving an LLM for ambiguous or high-impact decisions.

Which URL Features Matter Most in a Matched AI Phishing Detection Benchmark?

URL features remain valuable because they are available before a page fully renders and they support rapid triage. A serious benchmark separates lexical, infrastructure, content, visual, sender, and behavior signals without collapsing them into one feature count. Every feature definition, collection time, missing-value policy, and label source belongs in the release documentation.

The lexical layer can include total length, hostname length, path length, entropy, subdomain count, digit count, special-character count, token count, suspicious lexical tokens, encoded characters, IP-address use, shortened URLs, query-parameter count, redirect count, and unusual top-level domains. Infrastructure fields should add domain age, registration changes, DNS resolution, certificate details, reputation, and hosting relationships. Content fields should cover HTML structure, forms, iframes, external resources, JavaScript events, page text, login prompts, brand terms, and screenshot similarity.

Newly proposed features deserve an explicit ablation rather than quiet inclusion in the baseline. A benchmark adding URL entropy, subdomain depth, query-parameter density, redirect-chain length, domain age, HTML-to-text ratio, external-resource ratio, screenshot similarity, sender-domain alignment, and behavioral escalation should report the baseline score, the score after each feature family, and the score after all additions. That design shows whether the proposed signals add generalizable value or merely fit one collection period.

Sender context and headers often provide stronger evidence than URL spelling alone. The benchmark should capture display-name alignment, reply-to mismatch, authentication results, first-seen sender status, sending infrastructure, message threading, and whether the request matches the recipient's role. Behavior adds another layer through click sequence, credential-entry attempt, time to report, redirect interaction, attachment execution, and warning bypass, all of which must be split by user and campaign to prevent the model from learning the answer through leakage.

Screenshots and rendered HTML introduce visual and structural evidence including logo placement, form geometry, script behavior, and redirects, at the cost of higher operational overhead and capture-time bias. A page that is benign during collection can become malicious later, and a takedown page can make a phishing sample appear harmless, so benchmarks should preserve timestamps and test on later campaigns instead of random records.

How Should Explainability and Feature Importance Be Interpreted?

Explainability makes a detector easier to investigate, and feature importance still does not prove causality. A feature can rank highly because it correlates with a campaign, a label source, a hosting provider, or a collection artifact rather than because cyberattackers consistently use it. Treating an importance ranking as a causal claim is one of the most common misreadings in AI phishing detection benchmarks.

SHAP, permutation importance, coefficients, attention maps, and surrogate models answer different questions. A logistic-regression coefficient indicates how a feature shifts the model's score under the fitted representation, tree-based SHAP values describe a feature's contribution to a particular prediction or aggregate sample, and permutation importance measures how much performance changes when a feature is disrupted. None of these methods proves that changing the feature would change the underlying campaign.

The distinction matters for familiar signals such as URL length, domain age, digits, subdomains, and special characters. Cyberattackers can register short domains, use aged infrastructure, or produce clean-looking URLs, while legitimate services use long paths and dense query parameters. The 2024 cross-dataset explainability analysis found that shared features changed contribution rankings and even contribution direction between datasets, which is a direct argument for external validation.

Explainability should support analyst action without producing reassuring charts. A useful alert states that the sender domain does not align with the visible brand, the URL contains a newly registered domain, the page requests credentials, and the redirect chain obscures the final host. Analysts can verify each of those signals, tune thresholds, and identify false positives from them.

Security leaders should also require calibration, confusion matrices, precision-recall curves, class-specific recall, latency, resource use, and confidence intervals. Pairing those measures with phishing simulations shows whether offline model performance corresponds to safer decisions when employees encounter suspicious requests.

Fair comparison also depends on holding the training procedure constant. Compare ReLU and Leaky ReLU under the same architecture and schedule, tune classical hyperparameters using only the training partition, and record prompt version, temperature, token limits, and quantization format for any language model in the comparison. The defensible conclusion is that no single model family always wins, which is why AI phishing detection benchmarks earn their value by comparing matched inputs, diverse datasets, operational cost, and explanations alongside accuracy.

Feature rankings that reverse between datasets make model selection a guess dressed as evidence. Adaptive Security supplies explainable verdicts with a confidence score and stated reasoning on every detection.

Take a self-guided tour

How Do URL, HTML, Email, and Multimodal Approaches Compare in AI Phishing Detection Benchmarks?

AI phishing detection benchmarks compare models by measuring how much evidence each input modality can observe before it must decide. URL-only models classify quickly because they inspect lexical and domain signals without loading content, at the cost of missing visual impersonation, message context, and post-click behavior. HTML and rendered-page models add structure, scripts, layout, and brand cues, while JavaScript execution, privacy controls, and compute requirements make them harder to deploy at scale.

Email models combine sender identity, headers, body text, links, and attachments into a single verdict, and multimodal models assemble text, layout, visual, structural, and behavioral evidence across channels. Each choice sets a ceiling on what the benchmark can detect, which is why modality belongs in the reported operating context rather than in a footnote.

What Are the Strengths and Blind Spots of Each Detection Modality?

URL-only detection provides the speed baseline. It can inspect domain age, hostname structure, suspicious tokens, redirects, ports, and character patterns before a page loads, which suits browser extensions, secure web layers, and high-volume gateway decisions. Its blind spot is intent hidden outside the address, because a shortened link, QR code, or compromised legitimate domain conceals the real destination and a convincing replica of a trusted login page leaves little evidence in the URL itself.

HTML analysis adds page structure a URL cannot reveal. Forms, external resources, hidden fields, iframes, script behavior, favicon reuse, and links to unrelated domains show how a page collects credentials or redirects visitors. Rendered-page analysis goes further by examining the visible interface, logos, typography, and layout, strengthening detection of brand impersonation at the cost of fetching or executing pages in a controlled environment where JavaScript can still evade static inspection.

Email models observe the entire message transaction rather than only its destination. Sender and reply-to mismatches, authentication results, header anomalies, body language, link relationships, and attachments create a far richer signal set for business email compromise (BEC), credential theft, and invoice fraud. The financial weight sits here: according to the FBI's 2025 Internet Crime Report, cyber-enabled fraud accounted for almost 85% of all losses reported to IC3, totaling $17.7 billion, with business email compromise responsible for $3.046 billion across 24,768 incidents.

Those models retain blind spots when a trusted account is compromised, when a cyberattacker routes the lure through a legitimate cloud service, or when the message contains no link at all. Benchmarks built only from clean phishing emails overstate real-world performance for exactly that reason.

Multimodal models combine evidence without treating one signal as decisive. A message that uses a familiar brand name, a newly registered domain, a cloned page layout, and an urgent request becomes suspicious through the interaction of those signals. A 2025 Frontiers in Communications and Networks study combined SMS, email, and URL inputs with content, JavaScript, structural, and behavioral features, and while its findings establish no universal leaderboard, they show why AI phishing detection benchmarks should report cross-modal performance in place of a single email accuracy score.

Do Models Classify Phishing Directly or Detect Brand Impersonation?

Direct phishing classification asks whether an artifact is malicious. The model labels a URL, email, or page as phishing or legitimate based on learned indicators, which supports fast blocking and triage. Performance drops when cyberattackers imitate normal business workflows or use newly created infrastructure absent from training data.

Brand-impersonation detection asks a narrower and harder question: does an artifact pretend to represent a bank, payroll provider, executive, or internal department? It compares visual identity, language, domain relationships, and transaction context. The distinction matters because a page can be malicious without copying a recognizable brand, and a convincing brand clone can pair a clean URL with polished HTML.

AI phishing detection benchmarks should score both tasks separately. Report precision and recall for generic phishing, then test look-alike domains, cloned login pages, vendor impersonation, and executive requests as a distinct evaluation. That separation reveals whether a model recognizes malicious mechanics, familiar identities, or both, and it prevents a model from appearing strong merely because it memorized brand names and recurring domains.

Where Can Each Detection Approach Run?

Deployment location determines which signals a model can access and how quickly it can act. URL-only models fit browser extensions and lightweight gateway checks, where milliseconds and minimal data access matter most. HTML and rendered-page models fit isolated browsing services, detonation environments, and higher-latency gateway workflows.

Email models run naturally in mail APIs, reporting tools, and analyst workflows, because they inspect the message object without requiring a user to visit the destination. That placement also lets a detection verdict feed cybersecurity awareness training assignment and employee risk scoring directly, which no browser-side URL check can do.

Multimodal models need an orchestration layer that gathers evidence from several places at once, placing fast URL scoring in the browser, email analysis in the mail API, page rendering in an isolated service, and behavioral context in a security information and event management (SIEM) platform. Organizations evaluating phishing simulations across email, voice, and SMS should treat channel coverage as a separate benchmark dimension without assuming an email score transfers to every attack surface.

How Should Benchmarks Test Generalization Beyond Email?

Email results do not automatically predict performance against smishing, vishing, QR-code phishing, or social-media phishing. Smishing tests should preserve message brevity, phone-number reputation, shortened links, and mobile display constraints. Vishing tests should use transcripts that capture urgency, authority, turn-taking, and requests for secrets or payments without reducing calls to text-only email equivalents.

QR-code phishing requires testing the full chain from image decoding through mobile redirection to final page behavior. Social-media phishing should include direct messages, fake profiles, shortened links, comment-based lures, and impersonated executives or brands. Each test should separate in-distribution accuracy from time-based and cross-channel performance, then measure false positives, latency, explanation quality, and infrastructure cost.

The practical benchmark is not the model with the highest laboratory accuracy. It is the model that preserves reliable detection when a cyberattacker changes channels, removes familiar text, routes through a legitimate service, or pairs a convincing page with a believable human request. That standard gives security teams a clearer basis for deciding where automated detection ends and employee training, reporting, and verification must begin.

Channel coverage decides what a detector can see, and most benchmarks stop at email. Adaptive Security extends readiness testing to voice, SMS, QR codes, and deepfake impersonation.

Book a demo

How Reliable Are AI Phishing Detection Benchmark Results in the Real World?

AI phishing detection benchmarks often measure how well a model recognizes a curated dataset rather than how reliably it performs against live campaigns. A detector can post strong accuracy or area-under-the-curve scores while failing once phishing becomes rare, labels turn out to be wrong, templates change, or a cyberattacker introduces an unseen domain.

The operational consequence is severe: security teams either trust a detector that misses new campaigns or raise its threshold until legitimate messages are blocked. Neither outcome is visible from the published score, so recognizing which design choices inflate a result is the prerequisite for reading any benchmark table.

Why Do Benchmark Scores Inflate Model Performance?

Benchmark design determines what a model is rewarded for recognizing. Curated datasets often contain clean, visually obvious phishing pages alongside benign pages selected from convenient sources instead of from the traffic stream a deployed detector will inspect. Balanced classes compound the distortion, because a test set containing 50% phishing gives every positive prediction far more value than an enterprise inbox, browser session, or URL stream where phishing represents a much smaller share of observed events.

Stale samples produce a parallel failure. A detector trained on last year's page layouts, domain patterns, or language cues performs impressively on a static benchmark while missing a current campaign built with a new kit. Mislabeled pages corrupt measurement in a third way, since a scraped phishing page can resolve to a takedown notice, redirect to a legitimate site, or show benign content to a crawler through cloaking, and feed errors can mark a legitimate page malicious.

Metric choice completes the picture. Accuracy rewards the majority class, and ROC-AUC conceals unacceptable false-positive behavior whenever malicious events are rare. Precision at a fixed recall answers the more useful question of how many alerts analysts will investigate once the detector must catch a defined share of campaigns, so it belongs in the report alongside confidence intervals and the absolute number of false positives.

Benchmark designers should publish a data card covering collection dates, label adjudication, duplicate handling, campaign clustering, and source distribution for each class. Operators should treat results lacking those details as exploratory signals rather than evidence that a detector is ready for production.

Zero-Day and Adversarial Robustness in AI Phishing Detection Benchmarks

Zero-day robustness tests whether a model recognizes an attack family it has not effectively memorized. A random holdout is insufficient, because a new URL can still carry the same HTML, brand assets, hosting pattern, or kit represented in training. A credible test holds out entire domains, brands, campaigns, kits, and collection periods, then evaluates the model on samples sharing none of those identifiers.

Cyberattackers also change the content detectors rely on. They rotate domains, alter page structures, use JavaScript to render content after loading, hide text in images, and vary redirects by browser, geography, or user agent. A benchmark containing only static HTML rewards models for seeing the page exactly as the crawler saw it, so designers should include rendered pages, URLs, screenshots, redirects, and relevant metadata whenever the production detector uses those signals, and should document what the model cannot access.

AI-generated and LLM-rephrased phishing creates a further generalization test. Generative systems rewrite a lure in fluent language, localize it for a specific recipient, and preserve its social-engineering objective while removing the spelling errors older filters associate with fraud. According to Sumsub's 2025–2026 Identity Fraud Report, sophisticated fraud surged 180% year over year including deepfakes, synthetics, and telemetry tampering, which means a detector evaluated only on human-written messages risks measuring writing-style recognition instead of phishing judgment.

Benchmark maintainers should therefore add independently generated and human-reviewed variants, including prompt-injection attempts, paraphrases, multilingual messages, and synthetic variations that preserve campaign intent without duplicating the original wording. Multilingual coverage requires more than translating an English test set, because cyberattackers mix languages, scripts, transliteration, local payment terms, and culturally specific urgency cues.

Non-Latin scripts expose tokenization weaknesses while brand names and URLs remain familiar across languages. Designers should therefore report performance by language, script, region, and code-switching pattern, and operators should route low-confidence samples to human review in place of treating a high aggregate score as universal coverage.

How Do Human Review and Head-to-Head Evidence Improve Confidence?

Human review establishes whether a benchmark label represents the decision a security team actually needs to make. Automated feeds provide scale without reliably resolving cloaked pages, compromised legitimate domains, parked domains, borderline marketing messages, or campaign relationships. A review protocol should use at least two trained adjudicators for difficult samples, record disagreements, preserve the evidence available at collection time, and separate label validation from model tuning.

Head-to-head testing should use the same frozen sample, input fields, latency budget, and decision threshold for every detector. Reporting only each model's preferred metric prevents meaningful comparison. A stronger design reports fixed-recall precision, false positives per 10,000 benign events, detection latency, abstention rate, and performance by domain, campaign, language, and attack type.

Benchmark designers should preregister the split and evaluation protocol before tuning models against the test set. Operators should request an untouched evaluation set or conduct a blind pilot using their own historical traffic, because a detector that wins on a public benchmark can still lose inside an organization whose brands, languages, suppliers, and normal communication patterns differ from the benchmark population.

How Should Benchmarks Handle Temporal Refresh and Post-Deployment Campaigns?

Temporal refresh turns an AI phishing detection benchmark from a one-time leaderboard into an operational measurement. Phishing kits, brand targets, delivery channels, and legitimate web designs change continuously, so a fixed dataset gradually becomes a record of past cyberattacker behavior. Versioned releases are the counterweight: the PhreshPhish v1.0.1 release of February 2026 added roughly 200,000 samples collected between March and December 2025 and downsampled earlier records to improve temporal consistency.

Benchmark maintainers should release new, time-stamped campaigns without exposing them during model development. Each refresh should include unseen domains, new kits, changed brand targets, industry-specific lures, multilingual content, and AI-rephrased variants. Earlier versions should remain available so researchers can distinguish genuine improvement from performance changes caused by a different sample mix.

Operators need the same discipline after deployment. Monitor precision at the selected recall target, false-positive volume, analyst overrides, alert concentration by domain and campaign, language distribution, confidence scores, and the rate of samples routed to review. Track performance separately for email, URLs, webpages, QR codes, vishing transcripts, and smishing content whenever the detector supports multiple channels, since a sudden rise in low-confidence decisions or analyst reversals is an early signal of concept drift.

Use post-deployment campaigns as a controlled feedback loop rather than a reason to retrain on every alert. Preserve a quarantine set of newly observed campaigns, validate labels, cluster related operations, and evaluate the updated model against both the fresh set and a stable regression set. Security teams can then determine whether a gain reflects broader generalization or simple memorization of the latest kit, and a phishing simulation program can add behavioral evidence by testing whether employees recognize unfamiliar lures.

Without realistic priors, fixed-recall reporting, campaign holdouts, human-validated labels, adversarial coverage, and deployment-time monitoring, a benchmark answers only whether a model can classify yesterday's curated examples. With those controls, it begins to answer the question security leaders actually face, which is whether the detector will remain useful when the next campaign looks different.

Yesterday's curated corpus cannot anticipate the lure that lands tomorrow morning. Adaptive Security refreshes detection and employee readiness against AI-generated cyber threats as they emerge in the wild.

Explore the platform

How Do LLM Detectors Compare With Traditional Machine Learning in AI Phishing Detection Benchmarks?

AI phishing detection benchmarks show that large language model (LLM) detectors trade raw efficiency for contextual interpretation, while conventional machine learning systems remain faster and easier to measure at scale. Traditional systems classify predictable signals with high accuracy and recall, whereas LLMs interpret intent, relationships, and unusual language across an entire message. The practical choice is rarely either-or, because organizations need fast screening for volume alongside contextual analysis for ambiguous cases.

Traditional models deliver lower latency, smaller memory requirements, and more stable outputs, which suits screening inbound email at scale. LLMs supply richer explanations and stronger resistance to some adversarial rephrasing, offset by prompt sensitivity, invalid responses, privacy exposure, and inference cost. A hybrid architecture assigns each model the workload it can handle reliably.

How Do API-Hosted and Local Open-Weight Deployments Compare?

Deployment changes the risk calculation as much as model quality does. An API-hosted LLM removes local VRAM requirements and simplifies model updates, and it also moves email content outside the organization's processing boundary while adding network latency, provider dependency, retention questions, and usage cost. A local open-weight model keeps sensitive messages inside the organization, provided the team can operate the model, secure its runtime, monitor quality drift, and provision hardware for peak volume.

Benchmark evidence supports smaller quantized models only for carefully scoped use. The 2025 comparison of quantized LLMs and classical phishing detectors found that a 14-billion-parameter reasoning-oriented model reached 79% accuracy using roughly 15 GB of VRAM, while a similarly tested 32-billion-parameter standard model reached 81% accuracy and required about 34 GB. A 7-billion-parameter reasoning model reached 72% accuracy on roughly 5 GB, which makes constrained-hardware deployment viable for triage or analyst assistance instead of automatic acceptance of every email verdict.

Model labels alone settle nothing, as the same study demonstrated. Reasoning-oriented models outperformed similarly sized standard models while generating more tokens and taking substantially longer to complete, and quantization lowered memory demand without making any LLM competitive with lightweight classifiers on latency, energy, or throughput. Across the full comparison, classical machine-learning models ran roughly 1.38 million times faster at inference than the tested LLMs, which is the single strongest argument for reserving language models for the hardest decisions.

A complete benchmark should therefore measure accuracy, recall, F1 score, time to first token, total inference time, VRAM, power consumption, and carbon cost together. Reporting accuracy alone hides the operating expense that determines whether a deployment is sustainable.

Are LLM Explanations Faithful, and Can Confidence Be Manipulated?

Explanations improve analyst review only when they reflect the signals that produced the classification. An LLM can identify a mismatched domain, unusual payment request, or urgent credential prompt in plain language, and fluent reasoning still does not prove causal faithfulness. A detector can produce a convincing explanation after reaching the wrong label, omit the decisive signal, or express high confidence because the prompt demands certainty.

Invalid outputs must count as incorrect. If a model returns a paragraph without the required label, invents a third class, truncates before its decision, or violates the output schema, the result is operationally unusable regardless of whether a human can infer the intended answer. In the same 2025 benchmark, counting invalid responses as errors reduced the 32-billion-parameter model's reported accuracy from 81% to 71%, which shows how evaluations that discard failures inflate apparent reliability.

Prompt design creates another attack surface. A cyberattacker can place text inside an email or webpage HTML instructing the detector to ignore its instructions and classify the message as safe.

That is indirect prompt injection rather than evidence about the message's legitimacy, and OWASP's 2025 prompt-injection guidance identifies external webpages and files as untrusted inputs capable of altering model behavior. Detectors should isolate message content from system instructions, validate structured outputs in code, and route high-impact decisions through deterministic controls.

Does Adversarial Rephrasing Change the Comparison?

Adversarial rephrasing exposes the difference between pattern recognition and contextual reasoning. Traditional models often depend on token frequencies, URL features, headers, or learned phrasing, so a cyberattacker can preserve malicious intent while changing surface language. LLM detectors generally retain more context under paraphrasing without becoming automatically reliable under adversarial input.

The 2025 quantized-model benchmark produced mixed results that resist a simple ranking. Zero-shot rephrasing reduced accuracy by about 5.3 percentage points for Naive Bayes and 3.2 points for GPT-4, while few-shot rephrasing produced steeper declines across several conventional models alongside a 4.24-point decline for GPT-4. Those figures describe one dataset and experimental setup instead of a universal ordering.

A credible AI phishing detection benchmark should test original, translated, obfuscated, HTML-injected, and LLM-rephrased messages under identical labels while reporting recall separately from accuracy. Aggregating adversarial and clean samples into one score hides precisely the degradation that matters operationally.

Why Are Cascade Architectures More Practical Than Standalone LLM Detectors?

Cascade architectures put the least expensive control first and reserve contextual analysis for messages that need it. A TF-IDF classifier, URL reputation check, header analyzer, or compact neural model can screen routine traffic in milliseconds. The LLM then reviews borderline cases, explains conflicting signals, and presents a structured assessment to an analyst in place of deciding alone.

This design reduces API calls, latency, VRAM use, energy consumption, and privacy exposure while preserving a path for difficult spear phishing and business email compromise (BEC). Organizations evaluating phishing detection and response workflows should require abstention thresholds, calibrated confidence, schema validation, adversarial test sets, and human approval for wire transfers, credential resets, and other high-impact actions.

The strongest benchmark result is not the highest isolated accuracy. It is the architecture that maintains recall, valid outputs, explainable evidence, and controlled operating cost when cyberattackers change both the message and the instructions surrounding it.

Routing every message through a language model burns budget without improving recall on routine traffic. Adaptive Security layers machine learning and LLM reasoning so expensive analysis reaches only ambiguous cases.

Take a self-guided tour

How Should AI Phishing Detection Benchmarks Be Validated in Production?

AI phishing detection benchmarks become useful only when they survive live traffic, analyst workflows, and operational constraints. The transition from offline accuracy to production runs through staged deployment, beginning with replayed traffic and shadow mode before any automated action is enabled. Browser and email screening then connect to SIEM, SOAR, endpoint telemetry, and analyst review, so detection quality can be measured alongside workload, latency, cost, privacy, and remediation outcomes.

Speed is the constraint that makes staging urgent. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds. Every threshold in the pipeline therefore needs a defined fallback, human escalation path, rollback trigger, and post-deployment testing plan before launch.

1. Start With Offline Evaluation and Shadow Deployment

Production integration begins with a fixed evaluation set reflecting the channels, languages, file types, attack themes, and business roles the model will encounter. Separate development, validation, and holdout data by campaign without randomly splitting near-identical messages, since random splits make a model appear stronger when it has memorized campaign artifacts. Record precision, recall, false-positive rate, false-negative rate, calibration, inference time, and cost per 1,000 analyzed items before connecting the model to live workflows.

Run the detector in shadow mode after offline testing. The model scores browser requests, inbound messages, attachments, or reported phish without blocking, quarantining, warning users, or opening tickets. Comparing its decisions against analyst verdicts and existing controls across a defined observation window reveals whether a strong offline score survives real traffic, including newsletters, vendor notifications, internal announcements, multilingual content, and novel spear phishing.

NIST's 2026 report on monitoring deployed AI systems emphasizes that operational monitoring remains difficult after deployment. Approval should therefore depend on documented live evidence in place of benchmark accuracy. Set a go-live gate covering acceptable alert volume, analyst workload, triage time, user disruption, and remediation quality.

2. Connect Screening to Security Operations

Production screening belongs at the points where a decision changes risk. Browser controls can inspect suspicious destinations, downloads, credential prompts, and newly registered domains, while email screening can score sender identity, message content, links, attachments, and business context before routing a verdict to the mail workflow. Neither path should operate as an isolated dashboard.

Send normalized events to the SIEM with the model version, timestamp, source channel, verdict, confidence, features used, and action taken. Use SOAR playbooks for bounded actions such as opening a case, requesting analyst review, quarantining a message, revoking a session, or notifying an employee. Endpoint telemetry adds context about a clicked link, downloaded file, browser process, or credential activity, and analyst review remains the authority for ambiguous cases and high-impact actions.

Measure operational outcomes instead of alert volume alone:

• Alert volume and analyst workload: Track alerts per 1,000 analyzed items, queue growth, review minutes, escalation rate, and the share closed as benign;
• Triage performance: Measure median and 95th-percentile triage time, time to containment, false-negative discoveries, and agreement between the model and analysts;
• User and financial impact: Record warning interruptions, blocked legitimate work, support tickets, compute cost per 1,000 items, inference time, and energy consumed per 1,000 inferences;
• Remediation outcomes: Track messages removed, credentials reset, sessions revoked, users notified, repeat exposure, and confirmed incidents avoided or contained.

Connect these measures to phishing response and phish triage workflows so the organization can determine whether detection reduces exposure or simply transfers work from users to analysts.

3. Set Thresholds, Fallbacks, and Human Escalation Before Launch

Threshold selection is a business decision that no default model setting can make. A low threshold catches more suspicious items while increasing false positives, analyst queues, and user interruptions, and a high threshold reduces disruption while allowing more missed campaigns. Select separate thresholds for low-impact warnings, analyst review, automated quarantine, and irreversible remediation, applying different tolerance levels to finance, privileged accounts, executives, and ordinary traffic.

Every decision needs a fallback. If the model times out, loses access to a regional processing service, encounters an unsupported file type, or returns low confidence, route the item to the existing control or a human queue and never treat missing inference as a safe verdict. For high-risk requests, require human approval and an independent verification channel before wire transfers, credential resets, access changes, or sensitive data disclosure.

Log the input class, model and policy versions, confidence score, decision, override, analyst rationale, downstream action, and rollback event. Keep logs sufficient for incident review while minimizing message content and personal data. Define rollback triggers in advance, including a sudden false-positive spike, a material increase in missed confirmed phish, excessive queue growth, unacceptable inference latency, or a privacy control failure.

4. Govern Privacy, Retention, and Regional Processing

Privacy controls belong in the data path before production traffic arrives. Minimize collection to the fields required for detection, redact unnecessary message content, separate employee identity from model evaluation where possible, and restrict access to raw content. Set retention periods by data type, covering message bodies, URLs, analyst notes, telemetry, and audit logs.

Document where inference occurs, whether data crosses borders, which subprocessors receive content, and how deletion or correction requests propagate through caches, logs, and evaluation stores. Notify users when monitoring changes materially, explain what the system does and does not decide, and provide a route for reporting false positives or challenging an automated action. These controls protect trust while giving employees a defined role in correcting model errors.

5. Test Continuously Against Campaigns Discovered After Launch

Post-deployment testing must draw on campaigns discovered after launch, so preserve representative samples of confirmed malicious, benign, borderline, and analyst-overridden events and replay them against each model update. Add adversarial tests for obfuscated links, compromised suppliers, QR codes, multilingual lures, AI-generated messages, and multi-channel sequences.

Review performance weekly during rollout and at a defined cadence afterward, investigating drift by channel, region, department, language, and attack type. Retrain or recalibrate only after documenting the failure mode, changing the holdout set, and repeating the full release gate, which turns AI phishing detection benchmarks into a living operational control instead of a launch artifact.

Shadow deployment exposes the alert volume a benchmark score conceals before users ever feel it. Adaptive Security integrates detection with SIEM, triage, and risk scoring from the first day.

Book a demo

What Should a Minimum Reproducible AI Phishing Detection Benchmark Protocol Report?

A minimum reproducible protocol makes an AI phishing detection benchmark auditable by another team. That team should be able to reconstruct the evaluation and determine whether the result reflects real protection or a convenient test set. Every study should therefore document its data, preprocessing, model configuration, decision thresholds, uncertainty, operating cost, and failure cases.

Omissions belong in the audit record alongside the results themselves, because an impressive score without provenance cannot support a fair vendor comparison. The three components below cover the minimum a published benchmark owes its readers.

1. Publish a Required Benchmark Card

Start with a one-page benchmark card that lets reviewers understand the evaluation before reading the methodology. Name every dataset and version, provide its license and access location, identify the collection sources, and state the collection start and end dates. Report phishing and benign sample counts after every filtering stage, along with the label authority, annotation rules, adjudication process, and any unresolved or ambiguous labels.

The card must disclose class priors for the source data and every evaluation split. A balanced test set can demonstrate discrimination without predicting alert volume in production, and the gap between the two is where most published claims fail. Random splitting, similarity leakage, and unrealistic class proportions all inflate reported performance in ways a reader cannot detect from the score alone.

Document PII handling before release. State whether URLs, message bodies, screenshots, credentials, names, phone numbers, tracking parameters, and customer identifiers were removed, masked, hashed, or retained under controlled access. Explain deduplication at the URL, domain, message, campaign, template, screenshot, and near-duplicate embedding levels, and record excluded samples in a flow diagram with counts and reasons covering scrape failures, takedowns, redirects, malformed HTML, uncertain labels, policy violations, and post-review removals.

The card should also specify the split design. Identify whether the study uses random, domain-held-out, campaign-held-out, organization-held-out, or temporal splits, and confirm that related samples cannot cross partitions. For phishing, a future-only test set combined with campaign-level separation provides a far stronger check than a random split, because cloned kits, repeated domains, and near-identical messages otherwise appear on both sides.

2. Use a Required Result Table

Report results in a table that separates model quality from deployment practicality. Include the sample count and class prior for each split, then report precision, recall, F1, false-positive rate, false negatives, area under the precision-recall curve, and precision at fixed recall. Include threshold values and confusion matrices at operational points without presenting one default threshold as universal.

Threshold choice alone can move a headline number substantially. Published baseline results for the PhreshPhish benchmark suite show a fine-tuned GTE model reaching 99.6% precision at 80.3% recall on the full benchmark once the decision threshold was raised to 0.7, a trade-off invisible in any single-figure summary. The fields below define what a comparison must disclose for such numbers to be interpretable.

Compare systems on identical inputs, preprocessing, hardware boundaries, and decision rules. If an API model changes during testing, freeze the evaluation window and record the provider version. If a vendor supplies only a score, request the threshold mapping and calibration method without treating an undocumented score as a probability.

Link benchmark outputs and reproducible scripts from the paper, or provide controlled access for sensitive samples. For internal evaluations, an AI phishing simulation program can supply behavioral scenarios, though its generated samples should remain a separately identified test condition instead of an undisclosed substitute for real-world data.

3. Add a Robustness and Drift Appendix

The appendix should test whether the result survives conditions that break phishing detectors in production. Re-run the evaluation across collection periods, languages, industries, message channels, URL shorteners, HTML obfuscation, image-only content, redirects, newly registered domains, and previously unseen campaigns, then show how quickly accuracy and calibration degrade as the test set moves forward in time.

Include calibration curves, reliability diagrams, expected calibration error, and the method used to select confidence thresholds. Error analysis must inspect representative false positives and false negatives, explain the missed signal, and identify whether the cause was label noise, preprocessing loss, prompt ambiguity, model refusal, distribution shift, or an operational threshold.

Finally, report a drift-monitoring plan defining the signals that trigger re-evaluation, such as changing class priors, rising false positives, new attack channels, or a sustained confidence shift. A benchmark becomes a dependable decision instrument only when researchers publish the headline score together with the conditions under which that score stops applying.

Undocumented benchmark scores make vendor comparison an exercise in trust rather than evidence. Adaptive Security reports detection outcomes, employee behavior, and cyber risk movement in auditable dashboards.

Explore the platform

How Do AI Phishing Detection Benchmarks Fit Into Human Risk Management?

AI phishing detection benchmarks measure whether a model recognizes patterns in a defined technical dataset. They do not establish that an organization is safe from social engineering. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element, which places employee decision-making inside the same risk picture as detector accuracy.

The practical consequence is direct. Security leaders who track detector accuracy alone learn nothing about whether employees report suspicious messages, resist manipulation across channels, or retain safer behavior over time.

How Should Detection Be Paired With Multi-Channel Phishing Simulations?

AI phishing detection benchmarks measure machine performance against labeled inputs, while human risk management measures what happens when an employee receives a credible request under realistic pressure. Both matter, because automated detection does not replace employees, cybersecurity awareness training, or existing security controls.

A benchmark typically reports precision, recall, false-positive rate, and false-negative rate. Those metrics show whether a model identifies known malicious patterns without overwhelming analysts. They say nothing about whether a finance employee verifies an urgent payment request, whether an executive recognizes a cloned voice, or whether a staff member reports a suspicious text before entering credentials.

Controlled phishing simulations close that measurement gap. A mature cybersecurity awareness training program tests email phishing alongside spear phishing, vishing, smishing, deepfake impersonation, and AI-generated lures, using scenarios drawn from the organization's actual exposure such as vendor invoices, password resets, executive requests, cloud-document shares, and messages built from open-source intelligence (OSINT). Each exercise should record whether a person clicked, reported the attempt, used the approved verification path, and recovered after feedback.

That distinction sharpens as cyberattackers generate polished content at scale. A static test set cannot represent every campaign employees will encounter, so technical benchmarks need refreshing against new styles while phishing simulations test whether people apply judgment when a message does not match a familiar template.

How Can AI Phishing Detection Benchmark Results Become Board-Ready?

Benchmark scores become useful to directors once security teams translate model performance into business exposure. A board does not need a precision-recall curve. It needs to know which channels remain exposed, which business processes are most vulnerable, how quickly employees report suspicious activity, and whether risk declines after targeted intervention.

Board attention is already available where resilience is strong. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of highly resilient organizations indicate that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues.

A practical reporting model connects technical and human measures across four dimensions:

• Detection coverage: Recall, precision, false positives, and false negatives by attack type, language, and channel;
• Employee behavior: Reporting rate, time to report, click or submission rate, verification behavior, and response to repeat phishing simulations;
• Exposure: Comparative risk across finance, executives, administrators, remote teams, and employees with high public information exposure;
• Program effectiveness: Cybersecurity awareness training completion, retention checks, repeat failure patterns, analyst review volume, and behavior change over time.

This framing prevents a strong detector score from concealing a weak reporting culture, and it prevents high training completion from being mistaken for reduced risk. Completion proves that an employee opened or finished assigned material, whereas retention and phishing simulation behavior show whether that employee can recognize and report a cyberattack arriving through a realistic channel.

The board-ready outcome is a trend showing that false positives declined, reported phishing increased, time to report shortened, and repeat failures fell, alongside an honest account of where technical coverage remains incomplete. A human risk management program turns those signals into a continuous view of exposure.

Why Are Human Review and Targeted Education Complementary Controls?

Human review remains necessary because benchmark datasets cannot capture every organizational context, business process, or social cue. A detector can flag a suspicious message, and an analyst still has to determine whether the request matches a legitimate supplier relationship, a current transaction, or an approved executive workflow.

Targeted education turns that limitation into an action plan. If finance employees repeatedly hesitate during invoice fraud phishing simulations, cybersecurity awareness training should rehearse payment verification and out-of-band confirmation; if administrators struggle with credential-reset messages, education should focus on identity checks and privileged-account pressure; and if executives face deepfake or vishing attempts, practice should center on controlled call-back procedures.

The gap is widest around AI tools themselves. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 52% of employed participants reported they have not received any training on the security or privacy risks of AI tools, despite 65% now using AI and 43% admitting to sharing sensitive work information with AI tools.

Employees do not replace automated detection, and automated detection does not replace trained employees. The strongest human-layer program uses each control to test the other: detectors identify technical signals, analysts interpret context, phishing simulations expose behavioral gaps, and targeted education builds the judgment required for the next attempt. That combined record gives security leaders a more accurate basis for evaluating AI phishing detection benchmarks and deciding which datasets, channels, and behaviors deserve deeper testing.

Benchmark accuracy says nothing about whether employees report the message that slipped through. Adaptive Security connects detection outcomes to individual risk scores and targeted cybersecurity awareness training.

Take a self-guided tour

Closing the Gap Between AI Phishing Detection Benchmarks and Human-Layer Protection

Security teams need proof that a detector holds up against current lures and that employees behave safely when one gets through. Adaptive Security's Cloud Email Security applies dual machine-learning and LLM detection to every inbound message, scoring sender reputation, authentication, company context, behavioral anomaly, semantic intent, and attachment behavior, then returning a confidence score with the reasoning behind each verdict. Integration runs through API without MX record changes, so evaluation against live mail begins without rerouting production traffic.

Detections then stop being isolated events. Every confirmed cyberattack is remediated across all affected inboxes, feeds the targeted employee's risk score, and triggers relevant cybersecurity awareness training, while reported messages flow into phish triage and back into detection tuning. Phishing simulations extend the same measurement across email, voice, SMS, and OSINT-built spear phishing, closing the channel gap that AI phishing detection benchmarks leave unmeasured.

Governance and compliance close the loop for organizations answering to auditors and boards. AI Governance surfaces shadow AI use, personal-account data exposure, and policy violations that no email detector observes, and Compliance Training maps required policy attestation to the same risk profile that detection and phishing simulation results populate. Reporting presents detection coverage, employee behavior, and risk movement in one view instead of three disconnected consoles.

Consolidating detection, triage, phishing simulations, and governance removes the blind spots that separate tools quietly create. Adaptive Security delivers all four with unified reporting on human and machine exposure.

Book a demo

Frequently Asked Questions About AI Phishing Detection Benchmarks

What Are the Most Important AI Phishing Detection Benchmark Datasets?

The most important datasets are those with verified labels, documented collection dates, realistic class priors, and leakage-resistant splits. PhreshPhish is valuable for webpage detection because it combines large-scale phishing and benign samples, manually verified subsets, benchmark variants, and real-world collection constraints documented in the PhreshPhish benchmark suite. LegitPhish adds a manually verified URL corpus, while email datasets test sender, header, body, attachment, and link signals. No dataset represents every campaign, so compare provenance, language, brands, industries, takedowns, duplicate removal, and temporal coverage before selecting a corpus. A defensible benchmark combines multiple sources with held-out campaigns and domains.

How Accurate Are AI Phishing Detection Models in Real-World Conditions?

AI phishing detection models are less reliable in real-world conditions than balanced laboratory scores suggest. Performance drops once evaluation uses current campaigns, unseen domains, realistic phishing base rates, multilingual content, dynamic webpages, and campaign-held-out splits. Randomly dividing near-duplicate URLs or templates between training and test data inflates accuracy without measuring generalization, which is the problem the PhreshPhish benchmark research addresses through realistic webpage data, benchmark variants, and leakage controls. Judge a model with precision at fixed recall, false positives per 1,000 items, calibration, latency, and analyst workload, then monitor drift after deployment because new kits, brands, and lures change the detection problem.

What Is a Good Precision for Phishing Detection at 90% Recall?

A good precision at 90% recall is the highest achievable precision under the organization's actual phishing base rate and review capacity, since no universal percentage applies. At a 1% phishing rate, a detector with 90% recall and 99% specificity produces roughly 47% precision. At a 0.05% phishing rate with the same recall and specificity, precision falls to approximately 4%, meaning analysts review more than twenty false alarms for every genuine detection. Report precision at 90% recall across realistic priors with confidence intervals and a false-positive budget, and set thresholds separately for automated blocking, warning, and analyst review.

Can AI Phishing Detection Benchmarks Measure Zero-Day Cyberattacks?

AI phishing detection benchmarks can measure performance on zero-day and previously unseen campaigns, though only by simulating future conditions with strict data separation. Use temporal splits in which test samples appear after training data, domain-held-out and campaign-held-out sets, unseen brands, and adversarially rephrased or newly rendered pages. A random test split is not zero-day evidence and should never be labeled as such. Report detection latency, coverage, confidence, and failure modes for samples the model has never encountered, then refresh the test set continuously with newly observed campaigns while preserving an untouched evaluation stream.

Should AI Phishing Detection Replace Traditional Email Filters and Human Review?

AI phishing detection should complement traditional email filters and human review without replacing either. Filters remove known malicious patterns and enforce policy, AI evaluates contextual, lexical, visual, and behavioral signals that rules miss, and human reviewers handle ambiguous cases, business context, and novel social-engineering tactics. The National Institute of Standards and Technology guidance on phishing recommends using email filters as part of a broader phishing defense instead of a standalone control. Measure the combined system through missed cyber threats, false positives, escalation time, user disruption, and reporting behavior, because a benchmark becomes operationally useful when it connects detector performance to human-layer risk.

Curated accuracy hides missed campaigns, false-positive load, and the human-layer exposure that surfaces in live inboxes. Adaptive Security audits detection and employee readiness against the same cyber threats.

Explore the platform