This isn't really the way HIBP is used. While you can query the HIBP endpoint, the hashes are also available as (large) torrent downloads too. For many use-cases this means as the HIBP operator you won't see those requests since other service providers are likely using a local cache and not taxing Troy's infrastructure. Even when you are directly querying, the request is very likely proxied by the service operator so you won't be able to derive IPs specifically, just someone using Okta tried the password `obscure` (but not that they set their password to this - whomever they were, note I'm not saying Okta directly queries - just an example). Further, security recommendations (eg OWASP) require that companies test potential passwords against known leaks and discourage or prevent users from using frequently found values (typically 100+ uses or leaks.. note this either means one user has unluckily been leaked 100 times, or 100 people have used the same password) - this again encourages both proxied and possibly cached lookups (vs trusting client side code which could be disabled). Note that the expected use case is at password creation or password change, the new candidate is tested - not upon every login.

Ok so many use cases are removed - maybe your locally running password manager allows you to test a potential new password against leaks. Now we have a rare example of what you're hypothesizing, at this point you're trying to tie an IPv4 address to an identity. Many networks have either shared IPv4 addresses (NAT/GNAT in major metros, corporations, public Wifi), or dynamic IPv4 addresses (change daily/weekly/monthly). It's pretty hard (though not impossible) to link an IP to a person.. and vice versa, between 3g, 4g, 5g, wifi, work, home, complementary, wired and wireless connections a single person may appear across several addresses.

Finally the idea of accounts - knowing a specific IP just tested the password `password` and Aretha Franklin is most likely at that IP.. well, which of the hundreds of services might she be potentially considering the new password for? (again - testing, not setting the password to). If you could narrow it to one service, or brute force all of them, and assume the user ignores the dire warnings, you still need to know their user credential (be it email - of which they may have many, username - of which they may have many, or service-generated username which you'd need insider knowledge to obtain)

If you're worried about trust of your sensitive password, your password manager and the service you're using it on (if you reuse passwords) need far more.