I will describe here a program that has been contemplated since the beginning of Keykos but only roughly designed.

The secretary is a program that remembers actions of a person, or perhaps a program, so as to understand the ramifications of, and the state of the system due to the person’s acts.

The secretary is unsuitable for most programs for programs usually invoke too many keys. Also the secretary is largely unneeded for programs because programs are generally predictable, or at least can be built to remember what they have done.

The secretary may alleviate some of the misgivings that people have about the state in which they have left their computer world. In Unix you can look at the files that control initiation of the world upon boot strap. You can also examine file permissions that you control. For a Keykos system that goes for years without big-bang, what is the analog? Such worries are mentioned here.

The secretary observes what its user does with keys. It is in league with the command system. It is much more than a transcript of commands issued by the user, but that is where it starts. Its main value is to interpret those commands to tell, for instance, the provenance and history of a key.

In short the secretary is able to make and explain certain elementary deductions about the security state of the system reasoning from the remembered acts of the user.

The Secretary is loyal to the user at least in regard to answering historical questions; it may however be unwilling to delete the record. This record could be used to debug a person’s errors and misunderstandings. If the user were a program, the secretary could be used to understand the use of a program of the keys that it wields. The secretary might know a few things about a few common objects such as space banks, meters and factories. For instance the secretary might know what information has been revealed to a discreet object as that is relevant to control of the spread of information.

The secretary would recount the history of keys using the names of the keys when the actions were taken. The secretary understands operations to rename keys however and the focus is on the key — not on what it is called.

There may be a related and more elaborate scheme to keep user actions tentative, but we do not pursue that here.

The security administrator badly needs a secretary for he will need to take unusual actions to solve novel security problems as they arise. If this were not so a program could take his place.

Being involved with the command system, the secretary may help to retain the ability to revoke delivered authority.

The secretary is in a position to help establish that although the user had the ability to convey authority, he did not indeed do so. This is akin to the rubric where you convey to me the authority to do something while I retain the option of either doing it, or manifesting that I have not done it and perhaps manifestly rescinding my own right to do it.

Marc Stiegler describes and demonstrates here a different class of ‘secretary’ that supports a hierarchy of authorities and provides certain classes of review and revocation functions. It is more and less than what I suggest above. It is also more concrete. My secretary described above is general. Marc’s system convinces me that some sorts of application areas will need specific tools rather than the yet amorphous secretary that I describe above. Marc’s system is less general, and that will be appropriate in broad areas.