The Five Questions
- What data does the detection learn from, and where does its baseline of “normal” come from?
- What does it detect that a static rule could not? Name one pattern, specifically.
- How was the detection validated, against what data, and who ran the test?
- Where does a detection go when it fires, and what can the platform do about it?
- What is the false-positive rate at the operating threshold, how is it measured, and which way is it trending?
Every AAA (authentication, authorization, and accounting) vendor now describes some part of its product as AI. Some of those products learn from your authentication traffic and find things a rule could not. Some are a threshold engine with a new label on the datasheet. From the outside, the two are hard to tell apart, because both come with the same slide and the same list of threats detected.
This article is for the evaluator who has to tell them apart. It sets out what anomaly detection on RADIUS (Remote Authentication Dial-In User Service), Diameter, and TACACS+ (Terminal Access Controller Access-Control System Plus) traffic does when it is real, and the questions a rebranded rule engine cannot answer well. It then covers the evidence to ask for, and the one metric that says more than any feature list. Alepo sells an AI layer for its AAA Server, so we have an interest here. The framework is written so that you can apply it to us as strictly as to anyone else.
Evaluating AI anomaly detection for authentication traffic means asking what specific patterns the system learns from, requesting real detection examples rather than a feature list, and checking whether false-positive rates improve over time. It does not mean accepting “AI-powered” as a claim on its own.
What real AI anomaly detection actually does
A rule says: reject more than ten failures from one source in a minute. A model says: this pattern of failures does not look like this network at 2 a.m. on a Tuesday. One is a threshold someone chose; the other is a comparison against a baseline built from the operator’s own traffic, and that difference is what you are paying for.
The raw material is already in the authentication path. A RADIUS Access-Request, as defined in RFC 2865, carries the network access server (NAS) identifier and port, the calling station identity, the requested service type, and vendor-specific attributes that describe the access line or Wi-Fi controller. Diameter exchanges on the 3GPP (3rd Generation Partnership Project) S6b and SWx interfaces carry AVPs (attribute-value pairs) identifying the visited network and access type. RADIUS accounting records (RFC 2866) carry session duration, byte counts, and termination cause. TACACS+ carries the command each administrator was authorized to run. Real anomaly detection builds a baseline from those fields, per subscriber, per NAS, per realm (the authentication domain a request belongs to), and per time of day, and then scores each new event against it.
That baseline is what lets a model catch a distributed credential-stuffing run that stays under every per-account lockout, a subscriber authenticating from a NAS they have never touched, or an administrator whose TACACS+ command history suddenly changes shape. A static system can only catch what someone anticipated and wrote down. The throttling of failed attempts that NIST SP 800-63B, the National Institute of Standards and Technology’s Digital Identity Guidelines, requires of a verifier checking passwords and other secrets is a sound control, and every AAA server should have it. It is also a rule, and if a vendor’s “AI” turns out to be a set of rules like that one, the product may be fine, but the word is doing no work.
Questions that separate capability from marketing
The mistake most evaluators make is asking whether a platform has AI anomaly detection, because every vendor will say yes. The useful questions are the ones a marketing team cannot answer without an engineer in the room, and there are five of them.
Start with what the detection learns from and where the baseline comes from. A real answer names the fields, the aggregation levels, and the learning period, and explains what happens during the first weeks on a new network when the baseline is still forming. A vague answer talks about “network telemetry” and “behavioral signals” and moves on.
The second question is what the system detects that a rule could not, and it needs one specific pattern in reply. A real answer describes something with a shape, such as failures spread thinly across many accounts in alphabetical order, or a first-attempt success on an account dormant for months. If the examples all reduce to “too many X in Y seconds,” you are looking at thresholds.
Then validation. Against what data, labeled how, by whom, and with what result. A vendor who has done this work will tell you about held-out data (traffic the model was not trained on), replayed incidents, or a pilot on an operator’s network, and will be candid about what the model missed. A vendor who has not will describe the model architecture instead.
Ask where a detection goes when it fires and what the platform can do about it. Detection that ends in a dashboard nobody watches at night is a report. Detection that raises a SIEM (security information and event management) alert with the correlated NAS and account context attached, or applies a rate limit or a Change of Authorization (CoA) on the affected session, is a control. The architectural case for detection built into the AAA layer rests on this distinction, so ask whether the detection runs on the platform making the authentication decision or on a copy of its logs.
The last question is the false-positive rate at the operating threshold: how it is measured, and which way it is trending. That one figure says more than any feature list, and it gets its own section below. A question that sits behind it, what the operator has to do to keep the detection accurate as the network changes, decides whether you are buying a model or a maintenance contract for a rulebook, and comes first.
Asking for real detection examples, not feature lists
Feature lists are cheap to write and impossible to falsify. “Brute-force detection” on a slide could mean a threshold or a model, and the slide will never tell you which, so stop reading and ask for evidence, ideally on your own traffic.
Ask the vendor to replay a distributed credential-stuffing run against a test realm: leaked username and password pairs, one or two attempts per account, a few thousand accounts, at a rate that stays under any per-account lockout. Watch two things: whether the system scores the burst while it is building or only after a count is exceeded, and what the alert carries when it fires: a raw log line, or the source, NAS, realm, and per-account spread already correlated. Then ask for the control case: replay a re-authentication storm after a broadband network gateway restart, which looks a great deal like an attack to a threshold, and see whether the system tells the two apart. Our article on credential-stuffing defense for broadband AAA walks through why that second case matters as much as the first.
If a vendor will only show a recorded demo, treat that as an answer in itself. The table below puts the same test into RFP (request for proposal) scoring language.
AI anomaly detection evaluation criteria: what a real answer sounds like
| Evaluation criterion | What a real capability answer sounds like | What a marketing-only answer sounds like |
| What it learns from | “RADIUS request attributes, accounting records, and session state, baselined per subscriber, NAS, and realm over a stated learning period on your own traffic.” | “Advanced network telemetry and behavioral signals.” |
| Evidence of detection | A live or replayed incident on a test realm, showing the score building, the alert contents, and a look-alike benign event correctly left alone. | A features slide, a list of threat categories, and a recorded video. |
| False-positive handling | “Of the alerts raised at the current threshold, this share turned out to be real, measured on labeled traffic over a rolling window; here is the trend, and here is how an analyst’s correction feeds back in.” | “Low false positives thanks to AI.” No number, no denominator, no method. |
Does detection improve over time?
Authentication traffic changes. A new NAS vendor arrives in the access network, CPE (customer premises equipment) firmware updates change how often devices re-authenticate, a Wi-Fi offload service adds a traffic pattern that did not exist last quarter. A system that learned “normal” once and froze will alert on all of it until the operator’s team stops reading the alerts, which is where the difference between a model and a rulebook shows up in the operating budget.
An adaptive system relearns its baseline on a defined cadence and can explain that cadence to you. It handles the new NAS vendor by learning that vendor’s request pattern, not by waiting for someone to add an exception. It should also tell you what it does about drift, the slow shift in normal traffic that makes last year’s baseline wrong without any single event to point at.
Some ongoing calibration is normal and healthy. An analyst confirming or dismissing an alert, and the system learning from that judgment, is how these tools get better. The warning sign is a system that needs its rules rewritten every time the network changes: every rewrite is an engineer’s afternoon and a window during which the detection is wrong. When you ask how the platform handles a new access type, listen for whether the answer contains the word “configure” or the word “learn.”
False-positive rate as a real capability signal
If you can only check one thing, check this. Every vendor claims a high detection rate. Far fewer will put a false-positive figure in writing, with the denominator and measurement method attached, because that figure is expensive to earn and easy to check. A team that has one will show it without being asked twice.
The reason it matters is arithmetic. Fraudulent authentications are a tiny fraction of the total, so a detector that fires on even a small share of legitimate traffic buries the real detections under benign ones. Each false alarm also has a cost: a locked-out subscriber, a support call, an analyst’s hour, or a rate limit applied to a NAS that was only restarting.
The denominator is where vendors hide. A “false-positive rate” measured against all legitimate authentications can look tiny while the alert queue is still mostly noise. Ask instead for the figure the analyst lives with: of the alerts raised at the operating threshold (the score above which the system alerts), what share turned out to be real? Ask for the labeled data behind it, the time window, and the trend. A share of real alerts that is rising as the system learns the network is the strongest single piece of evidence you will get.
This is the point at which we should say how we would answer. The Alepo AI Agent for AAA is a real-time AI layer built into Alepo AAA Server, not a separate product to integrate. It runs on top of the AAA infrastructure and turns the platform’s own RADIUS, Diameter, and TACACS+ telemetry into a security and operational control plane. It performs anomaly detection on unauthorized access, brute-force and credential-stuffing detection, privilege-escalation and policy-violation detection, and DDoS (distributed denial of service) prediction, and it can trigger SIEM and firewall actions directly.
Those are our claims, and by the standard of this article they are the kind of feature list you should not accept on its own. So put the five questions to us, and ask us to run the replay on a test realm, show the alert contents, and show the benign case left alone. The cloud-native AAA architecture guide describes where the detection layer sits in a containerized deployment. Alepo AAA Server runs N+1 and N+N redundancy with real-time database replication, is engineered for 99.999% availability, and is rated at 36,000+ transactions per second (AAA Server datasheet).
Evaluating AI claims with confidence
The word “AI” on an AAA datasheet tells you almost nothing. Whether the product learns from your traffic or applies someone else’s thresholds is a question you have to ask, and a vendor’s willingness to answer with evidence instead of adjectives is itself a signal. Five questions, one replayed incident with its benign twin, and one false-positive figure with its denominator will separate the two kinds of product in an afternoon.
Put the criteria into your RFP alongside the ones you already score: protocol coverage, architecture and deployment model, high-availability design, and the identity-change monitoring that a SIM swap fraud prevention playbook depends on. Then hold every vendor to the same test, including us.
Bring the evaluation criteria from this article and a scenario from your own network. We will replay it against a test realm and show you what the Alepo AI Agent for AAA learns from, what the alert carries when it fires, and how it handles the benign look-alike.
Frequently asked questions
Q1. What should I look for in AI anomaly detection for authentication traffic?
Three things: what data the system learns from and how it builds its baseline of normal behavior, whether the vendor can show a real detection on replayed or live traffic instead of describing features, and whether the false-positive rate is measured, disclosed, and improving over time.
Q2. How do I evaluate a vendor’s AI fraud detection claims?
Ask for concrete examples of detected fraud on a test realm, including a benign look-alike event the system correctly ignored. A description of features or model architecture does not count; a replayed incident with the alert contents visible does.
Q3. What is the difference between real AI capability and marketing language?
Real capability learns a baseline from the operator’s own RADIUS, Diameter, and TACACS+ traffic and adapts as that traffic changes. Marketing-only systems often describe static, rule-based thresholds as AI. The tell is whether the vendor can name a pattern the system detects that no rule could have expressed.
Q4. What questions should I ask about AI anomaly detection in an AAA platform?
What it learns from and where the baseline comes from; what it detects that a rule could not; how it was validated and against what data; where a detection goes when it fires and what the platform can do about it; and how the false-positive rate is measured and improved.
Q5. How does machine learning apply to authentication anomaly detection?
It builds a model of normal authentication behavior per subscriber, NAS, realm, and time of day, then scores each new event against it. That lets it flag patterns a static rule would miss, such as failures spread thinly across many accounts, or patterns that shift over time as the network changes.
Q6. What proof should a vendor provide for their AI detection claims?
Real, specific detection examples on replayed or live traffic, the alert contents at the moment of detection, and false-positive data with the denominator and measurement window attached, ideally as the share of raised alerts that turned out to be real. A features slide does not qualify.
Q7. Does AI anomaly detection require ongoing tuning?
Some ongoing calibration is normal and healthy, such as analysts confirming or dismissing alerts and the system learning from those judgments. A system that needs its rules rewritten every time the network changes has not learned anything, whatever the datasheet calls it.
