Credentials are not "for" a host, a process or an object. They only describe the user (the principal in fact); they can be expressed at any host/process/object.
The granularity of how contexts are created between clients and targets depends on the security characteristics of the underlying operating system. In UNIX/NT type systems the context is established between the client's process and the target's process, rather than between hosts or objects. This is because the context contains secret keys and all objects (ie. application code) in a process have equal access to these keys, so there is no extra security gained by forming multiple contexts for objects in the same process - though it would do no harm. Processes are partitioned from each other by the OS, so there is some protection to be gained by forming different contexts for objects running in different processes. Similarly for different hosts.
If you wanted to share contexts more widely than between processes, you would have to jump through hoops to make the OS do that in a secure manner. Processes are the natural level of protection granularity - though some operating systems make take this to the thread level.
[ed: About necessity of establishing a new context:] If the 2nd object is co-located with the first in the same process, then the context can be re-used. If the objects are running in different processes, a new context must be established because the 2nd target has no idea what the session key(s) are that were established between the client and target A - it also did not directly authenticate the client itself, so it would have to trust the other process before it shared the context. That might not be a trust we can assume.