1. Challenge
The receiver authenticates and asks Totem for a five-minute challenge bound to the presenter, action, recipient, and request digest.
AI agent authentication
Totem gives each workload a scoped machine credential for the role it performs. A receiver creates the challenge, the named presenter authenticates, and the resulting proof is bound to that challenge and recipient.
Presenters and receivers have different jobs, so they should not share a key. A presenting workload needs permission to create a presentation. A receiving workload needs permission to create and consume challenges. Totem supports separate agent-bound API keys for those scopes.
Raw keys belong in each company’s secret manager and travel only in an authorization header over HTTPS. They should never appear in a URL, command argument, log field, or tracing label.
The receiver authenticates and asks Totem for a five-minute challenge bound to the presenter, action, recipient, and request digest.
The named presenter authenticates with its separate key and returns a signed presentation that expires within one minute.
The receiver authenticates again, submits the presentation once, and supplies its locally tracked request context.
Totem validates the proof and rechecks current identity, relationship, credential, scope, and revocation state.
Authentication proves control of an accepted credential. Authorization determines whether that authenticated agent may perform the requested action for this recipient and request. Totem evaluates both, but the result keeps the two questions separate.
A request fails closed when authentication material is malformed, expired, revoked, bound to another agent, or unavailable. A valid key also fails when its scope does not allow the requested protocol operation. See the authorization controls for the business-policy checks that follow.
TotemLayer
See how Totem binds identity and current authority to one exact cross-company request.