A natural (predominant?) growth mode for a system is incremental automation of manual operations. Suppose that we have a centralized authentication server (AS) that has the function of authenticating things (usually persons) outside some perimeter to application code within the perimeter. How does this plan meet to demands of the above incremental development?
We will suppose that AS is securely connected to the portals of the perimeter and controls those portals to identify the agent at the portal. We further assume that the AS can convey its assurance to points within the perimeter so that, for instance, an application could gain access to a circuit knowing that it is an authenticated, possible private connection the agent as identified by a securely delivered datum.
Incremental automation, as described above, occurs at the portals, where the manual operations of the persons occur. After such a module has been added the semantics of the AS has changed. The circuit is no longer to the agent but to the new module. This does not mean that the new configuration is insecure, but merely that the original security argument is no longer valid.
Suppose that application X has a secure circuit to person Z and that the system is to be improved by adding code, Y, that intermediates between X and Z. More precisely, instances of X will, after the installation of the new code, acquire a circuit to Y which, in turn, gains a circuit to Z.
The above picture is still fuzzy for we have ignored the question of the authority that this software upgrade required. In typical Unix systems the most commonly expected answer would be that someone with root privileges makes the changes and that is all that is necessary. Capability systems aspire to imposing security principles to the installation, as well as the operation of evolving software configurations.
To sharpen the last point, there seems to be two interesting answers to the question of installation authority: