There is also a subtlety about whether machines can even tell whether they are "on" a specific network or not. The layering model in the IP protocol stack has mostly made it so that network access and identity is either unauthenticated, or not transparent to higher layers (like the browser).
For a corporate application you might want to be able to say either
- be more trusting when I'm on this particular WPA2 wireless LAN or this particular VPN, compared to other times
- never connect to the Internet at all, except via this particular WPA2 wireless LAN or this particular VPN
(I think Microsoft Internet Explorer even has a setting that trusts LAN machines more for some purposes than non-LAN machines, although I don't remember exactly how that works.)
But this is hard to guarantee in IP not just because we don't necessarily have the right APIs for it in our software stacks, but also because an attacker might be able to attack the routing on a LAN in order to hijack another machine's connections, or might be able to proxy whatever kind of authentication is happening in order to make it appear that a network connection should be treated as a trusted one when it's not. In the corporate network case, the simplest version of this attack would be if the attacker controls one legitimate client machine on a LAN and wants to use that access to attack another legitimate client machine's access to server resources.
Basically, I don't think the IP networking technology has a good way to connote "this network is trusted", so trust relationships have to be conveyed typically at the application layer. Which is more work for a network administrator, to be sure.