You got it.

The speaksfor relationship is used to allow a user that has
cpu'ld (or ssh'd or telnet'd...) into a cpu server to access
resources off of that cpu server.  Assume you've telnet'd in
but the file server is on another machine.  In order to have
any files at all to continue, your process (via the factotum
on the cpu server) must authenticate to the file server.
However the only keys in that factotum are those of the cpu
server's owner.  Therefore, that owner must be able to
'speak for' you to the file server.  It does that by getting
a ticket from the auth server, encrypted in the file server
owner's key, that identifies the caller as you.

Keeping people out of a machine is another problem altogether.
In our world, having a key in a host's domain is equivalent to
having access to the host.  The way we lock people out of a
host is to not give them a key into its domain.  We run a
number of authentication domains at the Labs for that reason.

This was a lack of forsight on my part.  Putting a system in
a separate auth domain can be a pain for all the users involved.
Some flavor of ACL would be nicer; i.e. the ability to say, user
Alice can only do the following things on host X.  We already
have something like that in the form of /lib/ndb/consoledb.
Perhaps we could do something similar on a per service basis,
i.e., a servicesdb that each service (or listen itself) can
consult to determine yay or nay for the service.  For example,
you could make /lib/ndb/common:

tcp=cpu port=17013 uid=!presotto uid=*

That way, stand alone servers could control who cold use
its services.

I'm not sold yet on the form it should take, but I think it is
necessary.