NFS as a technology is only supposed to be used between systems controlled by the same domain administrator. E.g. university lab computers mounting user home directories from said university's disk servers. Mounting an NFS share (or setting policy allowing an NFS share to be mounted) is an implicit grant of trust—in both directions.
I say "in both directions" because, even more crazily, unless the NFS server is just for anonymous guest access, it's trusting the client connecting to it to assert which users the client is operating on behalf of. Anyone who can connect to an NFS server as a non-"nobody" user, can create or modify files as if they were root or whichever other UID they like. (Basically, the only authorization ACLs the NFS server tracks are for the client device. Users don't log into NFS servers; devices do.)
NFS really only works securely, in use-cases where both sides of the NFS connection are managed devices that don't let anyone except the domain administrator (including people with physical access to the hardware!) become root on them. (Or, I guess, when you're just standing up a read-only disk server to serve a rootfs to a bunch of thin clients. "PXE boot to NFS" is a pretty cool setup, though one that's been mostly superceded by streaming big initramfs images to client memory on boot.)
The reason for the NFS automounter in macOS, is that macOS actually used to use NFS to implement Portable Home Directories (Apple's answer to Windows' Roaming User Profiles.) This feature would only even kick in if the user profile with the NFS path as its homedir, came from your network OpenDirectory domain. (I believe the NFS server and the OpenDirectory server had to both share the same Kerberos auth realm, too.) So, in other words, your device would have to be a fully "managed" one—one of the very devices mentioned above, that doesn't even let its physical possessor become root on it—before the OS would ever deign to provide the NFS automounter anything to chew on.
The automounter itself was never really secured, though; all the security was in the glue determining what the automounter could "see." (You can't really secure the automounter itself without breaking the semantics of "transparent access to NFS shares of your domain." And if you're not locked into legacy 1970s-timesharing-BSD-cluster network semantics, then you may as well just drop NFS and use a better technology like SMB.)
I say "in both directions" because, even more crazily, unless the NFS server is just for anonymous guest access, it's trusting the client connecting to it to assert which users the client is operating on behalf of. Anyone who can connect to an NFS server as a non-"nobody" user, can create or modify files as if they were root or whichever other UID they like. (Basically, the only authorization ACLs the NFS server tracks are for the client device. Users don't log into NFS servers; devices do.)
NFS really only works securely, in use-cases where both sides of the NFS connection are managed devices that don't let anyone except the domain administrator (including people with physical access to the hardware!) become root on them. (Or, I guess, when you're just standing up a read-only disk server to serve a rootfs to a bunch of thin clients. "PXE boot to NFS" is a pretty cool setup, though one that's been mostly superceded by streaming big initramfs images to client memory on boot.)
The reason for the NFS automounter in macOS, is that macOS actually used to use NFS to implement Portable Home Directories (Apple's answer to Windows' Roaming User Profiles.) This feature would only even kick in if the user profile with the NFS path as its homedir, came from your network OpenDirectory domain. (I believe the NFS server and the OpenDirectory server had to both share the same Kerberos auth realm, too.) So, in other words, your device would have to be a fully "managed" one—one of the very devices mentioned above, that doesn't even let its physical possessor become root on it—before the OS would ever deign to provide the NFS automounter anything to chew on.
The automounter itself was never really secured, though; all the security was in the glue determining what the automounter could "see." (You can't really secure the automounter itself without breaking the semantics of "transparent access to NFS shares of your domain." And if you're not locked into legacy 1970s-timesharing-BSD-cluster network semantics, then you may as well just drop NFS and use a better technology like SMB.)