Whose IP address is your scanner using?

If a hosted scanner sends probes from its own infrastructure, then every customer shares one reputation, and the first person to get that address blocked breaks the product for everyone else. We audited our own platform against that rule and found a component breaking it. This is the rule, the audit, and what we changed.

Here is a question worth asking any hosted security scanner before you rely on it. When it sends a request to your target, whose address does that request come from?

If the answer is "the vendor's", you have taken on a dependency you probably did not price in. Every customer of that vendor is sharing one reputation with you, and reputation is the thing that decides whether your traffic arrives.

Why shared egress fails

Scanning traffic gets addresses blocked. Not because scanning is wrong, but because the volume and shape of it look exactly like the thing edge providers exist to stop. A vendor sending every customer's probes from one pool is accumulating that risk in a single place.

When it goes wrong it goes wrong for everyone at once. One customer runs something aggressive, or tests a target whose provider blocklists broadly, and the address ends up on a list. Now every other customer's scans fail, against targets they have permission to test, for a reason none of them caused and none of them can fix. The failure is also quiet: findings do not appear, and a scan that finds nothing looks the same as a target that has nothing wrong with it.

There is a second reason, and for bug bounty work it is the more important one. Your permission to test a target is yours. Traffic arriving from a third party's infrastructure is harder for the target to attribute to you, harder for you to prove was yours, and in some programmes is a scope violation on its face.

The rule we hold ourselves to

Any request that actually reaches a customer's target must originate from that customer's own egress, never from shared infrastructure we own.

The blast radius of anything going wrong should be one customer. Ours.

Structurally this falls out of how the platform is built. The engines that do the scanning run on your node, on hardware you control, and they exit through your network. What we host is a control plane: it hands out work, collects results, and stores them. It has no reason to touch your target and it does not.

That separation is easy to state and easy to violate by accident, because a control plane accumulates helpful features and some of them want to make a request. So on 8 August 2026 we audited it properly rather than assuming.

What you actually do with that control

Owning your egress is not about being sneaky, and three ordinary engagement situations turn on it.

Clients regularly require testing to come from an address they have allow-listed, so their own team can tell your authorized traffic apart from a real attack. If your scan slips out of the wrong interface, you are outside the agreement no matter how careful the rest of the work was. Separately, a real attacker is not sitting on your office connection, so testing from egress that resembles the threat you are simulating gives the defender a truer picture. And if your own address gets flagged mid-engagement, your results stop being about the target and start being about your address.

Each node can route out through layered proxy chains and isolated tunnels, so the scan leaves from where you chose rather than from whatever interface the box happened to have. Bind that to the workflow and every machine presents the same source, which is what makes 'we tested only from the agreed address' a sentence you can defend afterwards.

What the audit found

The engine path was clean. Probes originate on the customer's node, and the channel between node and control plane carries job control rather than probe traffic, so nothing reaches a target from our side of it.

One component was breaking the rule, and it was the one we had built for convenience.

The authentication broker

Testing an authenticated application means getting a session. For credentials that need an interactive login, such as OAuth or single sign-on, we ran a headless browser that performs the login and hands back the token. It was hosted by us. Which means it opened your target's login page from our address.

Lower risk than scanning, since it is one login against an account you own, and still a violation. It is our infrastructure touching your target, and the rule does not have a size exemption.

The fix routes the broker's browser out through the requesting node's own egress, so a brokered login now leaves from the same address the rest of your testing does. There is also a switch to disable control-plane brokering entirely, for anyone who wants the guarantee enforced rather than configured.

The same audit found the broker would follow a user-supplied URL anywhere, including to internal addresses and cloud metadata endpoints, which made a hosted browser inside our network into a request-forgery proxy. That is written up with the rest of our own findings in four bugs we found in ourselves.

A decision the audit changed

The plan for solving edge challenges had been to reuse that same hosted browser. The audit killed it. Solving challenges is aggressive, scanner-shaped traffic, and doing it from our addresses would have been the worst possible version of the thing we had just decided not to do.

It moves to the node instead: the browser runs on your machine, obtains clearance from your address, and hands the result to the client that will use it, also from your address. The feature waits until that exists rather than shipping the easy version.

The shared name we still have

One residual, stated plainly. Out-of-band confirmation needs a listener your target can reach, and every workspace gets a managed one by default on a shared domain. That is not an address that can get blocked, but it is a shared string that appears in payloads and can be pattern-matched.

You can self-host your own listener, and for bug bounty work you should. The scan wizard now says so when the shared one is selected, rather than leaving it as something you would only discover by reading the payloads.

What to ask a vendor

• Which addresses do probes leave from, and are they shared with other customers? If the answer is a pool, ask what happens when the pool is blocked.
• Does anything other than the scanner touch my target? Login helpers, screenshot services, link checkers and preview fetchers are all easy to forget and all reach the target.
• Can I bring my own egress? If not, your testing runs at the reputation of the vendor's worst-behaved customer.
• What appears in out-of-band payloads? A shared callback domain is a shared detection signature even when addresses are isolated.

We wrote this partly as an argument and partly as a disclosure, because the honest version of the argument includes the part where we audited ourselves and found a component doing the thing we tell people not to do.

Run the engines on your own hardware, from your own address, with the results in one place. Scan from your own address