Behavioral Anomaly Detection: How Vexta Flags a Response That Doesn't Fit

Anomaly detection in web application testing means comparing each response against how that specific endpoint normally behaves, so a probe that suddenly takes far longer or comes back a different size stands out even before anyone knows why. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and it builds a running behavioral baseline for every endpoint it touches during a scan, then flags any response that lands far outside that baseline as worth a closer look.

How does Vexta build a baseline for each endpoint?

Every request the scanner makes, not just dedicated probes, feeds a per-endpoint running statistical tracker covering three signals: response latency, response body size and the distribution of status codes that endpoint returns. The tracker updates incrementally as requests come in, so the baseline reflects the endpoint's real behavior across the scan rather than a single snapshot.

Because the tracker sits at the transport level, it sees the full traffic a scan generates against a target, which means the baseline for a busy endpoint gets more data and a tighter picture, while a rarely-hit endpoint's baseline stays looser until more requests land on it.

This is a meaningful difference from running a single scan and eyeballing one response. A hunter looking at one request and response in isolation has no way to know whether a 400 millisecond response time is normal for that endpoint or a warning sign. A running baseline built from everything the scan has already sent gives that single data point context it would not otherwise have.

What counts as an anomaly?

Vexta uses 3-sigma outlier detection: a response that falls more than three standard deviations from an endpoint's established baseline gets flagged. The documentation's own example captures the idea well: an endpoint that normally returns 200 in 45 milliseconds, plus or minus 5, suddenly returns a 1,200 millisecond response. Nothing about that response's status code looks wrong, but the timing says something changed, and that is worth investigating.

That is the value a purely signature-based check cannot offer. A detector looking for a specific SQL injection string in a response body has nothing to match here. A statistical baseline catches the anomaly anyway, because it is comparing behavior against itself rather than against a fixed pattern.

What happens once Vexta flags an anomaly?

Anomalies feed directly into Vexta's AI-driven discovery loop. A timing spike or a body-size jump becomes an input the loop can reason about: is this the kind of delay a blind time-based injection would produce, or a backend struggling under a specific input value? The anomaly does not become a Finding on its own, but it gives the discovery loop a concrete, specific reason to generate a targeted follow-up probe rather than guessing blind.

Can I see the baseline data myself?

Yes. A snapshot endpoint, GET /api/v1/anomaly/baselines, returns the current per-endpoint baseline data directly, so a hunter who wants to sanity-check what Vexta considers normal for a given endpoint, or pull the numbers into their own notes, does not have to take the anomaly flag on faith. That transparency also matters when a finding built on an anomaly ends up in a report: being able to show the actual baseline numbers next to the outlier response makes the case concrete instead of asking a client or a triager to trust a black-box flag.

Why this matters alongside signature-based detection

Vexta already covers 25 or more vulnerability classes with dedicated detectors and ships 10,000 or more CVE templates, so most known bug patterns are already being checked for directly. Behavioral anomaly detection is a different layer on top of that: it catches the response that does not match any known pattern but still does not look right, which is exactly the category of bug that only shows up as a side effect, a timing change, a size change, a status code that appears where it never has before.

For a hunter working a target that has already been scanned by conventional tools, that layer is often where the remaining findings are. Everything a signature can catch has usually already been caught; what is left tends to be the behavior nobody wrote a rule for.

This is also why the anomaly layer is described as feeding the discovery loop rather than reporting on its own. A timing spike by itself is evidence something changed, not proof of what changed it. Routing that evidence into a reasoning step, instead of surfacing every 3-sigma blip as a raw alert, keeps a hunter from drowning in outliers that turn out to be a slow database query on an otherwise unremarkable endpoint.

Key takeaways

The essentials on how Vexta's anomaly detection works: