Jof, your right. Doing something like this is not in vShield as a called out feature, but I think there is a way that this can be done.
Basically here is what you would need to do (I say think about because I haven't actually tested this, but I don't see any reason why this shouldn't work). Instead of using the groupings you get in vCenter like Resource Pools and vApps, you would need to use the Security Groups feature from within the vShield Manager to create your groups by adding specific vNICs from VMs to these specific groups.
Then you would need a default deny all rule, which is common practice anyway. You would then need to create allow rules to and from these specific Security groups that were created. So now if a vSphere admin adds a vNIC to a VM it would not be able to communicate until the vShield Administrator actually added that vNIC to one of the security groups in vShield Manager because it would not match any of the allow rules and would hit on the default deny rule.
Now if the vSphere Admin was also the vShield Administrator, they could go into the VSM and add that NIC to one of the security groups we have or even create their own rule, but at this point it wouldn't be a mistake. It would absolutely be on purpose. But again, this is where separation of duties comes into play and determining who is best to manage vSphere and who is best for vShield.
Also, another way to help prevent this is through the use of RBACs in vCenter or something like a Hytrust. But the option with vShield App (it would have to be App and not Zones because of the logical grouping requirement) is another layer of defense for this.
I hope this helps. Let me know if you test this out. I may just try to test it myself if I get some time.
