For example, suppose a C program opens a file for read access by executing the call:
open("filename", O_RDONLY, 0)
The desired file is designated by its name on the filesystem, which is a global namespace shared with other programs, so the program is exercising ambient authority.
When ambient authority is requested, permissions are granted or denied based on one or more global properties of the executing program, such as its identity or its role. In such cases, the management of access control is handled separately from explicit communication to the executing program or process, through means such as access control lists associated with objects or through Role-Based Access Control mechanisms. The executing program has no means to determine for what purpose it was granted a permission. This inevitably leads to such programs being subject to the Confused deputy problem.
The term "ambient authority" is used primarily to contrast with object-capability models or simply capability-based security models, in which executing programs receive permissions as they might receive data, as communicated object references. This allows them to determine where the permissions came from, and thus avoid the Confused deputy problem.
Ambient authority is the dominant form of access control in computer systems today. The user model of access control as used in Unix and in Windows systems is an ambient authority model because programs execute with the authorities of the user that started them. This not only means that executing programs are inevitably given more permissions (see Principle of least privilege) than they need for their task, but that they are unable to determine the source or the number and types of permission that they have. A program executing under an ambient authority access control model has little option but to designate permissions and try to exercise them, hoping for the best. This property requires an excess of permissions to be granted to users or roles, in order for programs to execute without error.