How does a scanner stay gentle on a target protected by a WAF, a web application firewall that filters traffic before it reaches the app, partway through an authorized test? Vexta routes every outbound request through one centralized HTTP client that applies adaptive rate limiting, randomized timing, and scope enforcement before a request ever leaves the machine. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and because every request in a scan passes through that same client, the whole engagement behaves consistently instead of each module hammering the target its own way.
The problem: a scan that overwhelms the target
A scan that fires requests as fast as the network allows tends to trip the target it is supposed to be testing carefully. A WAF rate-limits the source IP, a load balancer starts dropping connections, or a target's own monitoring flags the burst and someone on the client side starts asking questions before the engagement is even finished. None of that produces better findings. It just produces a shorter scan and a client that is now watching the wrong thing.
It also wastes the authorized window a program or engagement actually gives a hunter. If a rules-of-engagement document allows testing for a set period and half of it gets burned re-establishing access after getting rate-limited out, that is time that should have gone toward finding and confirming real issues.
Slowing everything down uniformly is not really a fix either, it just trades one problem for a slower version of the same problem. What actually helps is giving every request a single path through the tool that can apply rate limits, spacing, and scope rules consistently, no matter which module, crawler, or vulnerability check happens to be firing it.
What does Vexta's HTTP client actually control?
Every request Vexta sends, whether it comes from recon, the scripting engine, or a vulnerability check, goes through one centralized HTTP client rather than each component opening its own connections. That client handles TLS policy, so connection behavior is consistent across the scan, and supports routing through an HTTP or SOCKS5 proxy when a test needs to go through a specific network path.
On top of that it applies adaptive rate limiting, so request pacing adjusts to how the target is responding rather than firing at a fixed rate regardless of conditions, and it adds jitter, small randomized delays, to request timing so traffic does not arrive in the kind of perfectly even bursts that behavioral detection looks for. Requests are also decorated consistently with a User-Agent, headers, and cookies, and a shared cookie jar keeps session state coherent across requests, which matters for anything that needs to stay authenticated through a longer sequence of calls.
How does scope enforcement work?
The same HTTP client enforces a blacklist at the point where a request would actually go out, not just at the point where a target list is entered at the start of a scan. That is the layer that keeps an authorized test inside the boundaries a program or a signed engagement actually defines, catching a request to an out-of-scope host before it leaves the machine rather than relying on every module to check scope on its own.
Keep-alive behavior is controlled centrally too, so connections are reused where that makes sense for a target's own performance rather than opening and closing a fresh connection per request, which is itself one more thing that can make a scan look and feel less abrupt to whatever is monitoring the other end.
Because scope enforcement sits inside the shared HTTP client rather than inside each individual module, a new check added to Vexta inherits the same boundary automatically. There is no separate scope list to remember to wire into every new detector.
Why every exchange gets logged
An audit hook on the HTTP client automatically records every exchange to the active scan's audit archive. That means the full request and response history for a scan is captured as it happens, not reconstructed afterward from partial logs, which matters when a client asks exactly what was sent to their environment and when.
For a hunter, that combination, adaptive pacing plus scope enforcement plus a complete record of every exchange, is what makes it practical to run a scan against a real production target without babysitting it, and hand over a defensible account of exactly what happened if anyone asks. Behavior at the edges, like proxy support, can vary by license; see plans on the pricing page for specifics.
Key takeaways
What Vexta's HTTP client does for every request in a scan:
- Every outbound request, from recon, scripts, and vulnerability checks alike, passes through one centralized HTTP client rather than each module making its own connections.
- Adaptive rate limiting adjusts request pacing to the target's responses instead of firing at a fixed rate.
- Jitter adds randomized timing to requests so the scan spreads its load instead of hammering the target in bursts.
- Scope enforcement blocks out-of-scope requests at the point they would leave the machine, keeping a scan inside an engagement's defined boundaries.
- An audit hook automatically logs every exchange to the scan's audit archive as it happens.
Frequently asked questions
How does Vexta keep an authorized scan gentle on the target?
Does Vexta enforce scan scope automatically?
Can Vexta route scan traffic through a proxy?
Does Vexta log every request it sends?
What is jitter and why does Vexta use it?
Run a scan that stays gentle on the target
See how Vexta's adaptive rate limiting and scope enforcement keep an authorized test gentle on the target and inside scope.