To refocus the discussion on OAuth (no superprotect and copyright issues here please :), the field with legal relevance is the privacy policy of the application (and maybe its terms of service if we add such a thing in the future). Any time you use, say, CropTool, the tool operator has access to checkuser-type information. The tool operator publishes a privacy policy (which is legally binding for them), and the OAuth admins approve or reject the tool based on that policy (for example if it contains that the operator can pass private data to any third party, that tool application is going to get rejected). If the tool operator can change the privacy policy without any oversight, that can be problematic. On the other hand, if they can't change it at all, that's also problematic, and we probably won't have the resources to build some kind of complicated change review system anytime soon.
As for attack vectors, some of the information (such as the application's icon and short description) is presented on the authorization dialog and users will have to decide based on that dialog whether they trust that application to, say, delete pages in their name. An attacker could create an innocent description, get the tool approved, and then change the description to pretend it is some other, widely trusted tool, and trick users into authorizing it.