There are two types of outgoing connection that seem to be a bit conflated here:
- RStudio Connect products connecting to third party services (i.e. from Connect, on the "server side")
- The user's browser connecting to third party services (i.e. when the user loads the visualization from their desktop)
The former is usually solved with a firewall that prevents Connect talking to outside services. In this type of a setup, package management typically becomes a problem and RStudio Package Manager fits well as a solution.
The latter is much trickier, because the user probably has access to the internet (i.e. if you visit google.com or rstudio.com in your browser, you are sending your public IP address to those websites already). You can put the user behind a firewall that prevents them from accessing the internet, but that isn't as common as the above.
It sounds like the latter is your concern. Do users have access to the internet? Is it a problem if the user goes to rstudio.com and gives their public IP address away anyways? Or is it just a problem if your content calls out to rstudio.com (again, from their desktop, not the Connect server) without their knowledge?
EDIT: Also, if your policy is against sending IP addresses to a third party, what is meant by "sending?" You are not "sending an IP address" here. You are asking the user's browser to load content from a third party... the user's computer is making a request from that third party, which includes their public IP address. If that policy is as strict as it sounds, it seems like the user should not have access to the internet... but that's just my read 
I.e. contrast this with me figuring out all of the (private) IP addresses on my network and then sending a list of them to my buddy. Private IP address != Public IP address.