PolicyKit assumes a model where a program is split into two parts. One part, the Mechanism, runs privileged (with no user interface elements) and the other part, the policy agent, runs unprivileged. The two parts of the program are in different processes and communicate through some IPC mechanism such as pipes or the system message bus (D-Bus). In some instances the Mechanism can be considered part of the core OS and the policy agent part of the desktop stack.

A Mechanism should never trust any application that tries to use; it needs to carefully verify all data and requests passed to it from the application. This is the model employed by HAL and NetworkManager:

This model is not by any means restricted to applications using D-Bus; it applies to most other security sensitive applications. For example, the PAM module for checking your password can run unprivileged and uses a simple and easy to audit privileged helper application, /sbin/unix_chkpwd on Red Hat systems, to actually check the password against /etc/shadow. In a similar fashion, all setuid root applications carefully check (or at least should) incoming parameters and the environment in which they are launched.

In general, such an architecture is thought of as secure as long as the Mechanism (and it's dependent libraries) have been verified to be secure.