Recipient and relationship
The credential and challenge target the receiving organization, and the company relationship must remain active.
AI agent authorization
Totem combines cross-company identity, a named recipient, action scope, time bounds, request binding, and live revocation checks. The receiver gets evidence for one decision rather than a reusable trust score.
Broad agent roles are difficult to apply across independent companies. The presenter does not control the receiving system, and the receiver should not accept the presenter’s own claim about what it may do. Totem lets the receiver ask for proof tied to its local request.
The credential identifies the agent, issuer, recipient, allowed action, expiry, and any configured amount or currency limit. The challenge adds the request digest and a single-use nonce. Verification requires the credential, challenge, live records, and local context to agree.
The credential and challenge target the receiving organization, and the company relationship must remain active.
The named presenting agent must be active and the credential scope must include the exact requested action.
The signed request digest must match the receiver's fresh local digest, including any configured transaction context.
Totem rechecks keys, agents, credentials, and related authority at the serializable verification decision.
Totem does not release the data, update the record, submit the document, or accept the quote. It returns a structured decision and evidence. The receiving service must require a complete approval, compare the evidence digest with the exact bytes it will process, and apply any additional local policy.
That boundary prevents the presenting agent from turning a successful check into general access. It also leaves each company in control of its own business action. The protocol page explains replay handling, idempotency, and failure states.
TotemLayer
See how Totem binds identity and current authority to one exact cross-company request.