Signature and proof
The presentation signature, expiry, nonce, audience, challenge, and request bindings must validate.
AI agent identity and authority verification
A Totem verification result covers one presenting agent, one receiving organization, one action, and one request digest. The decision records why the proof passed or failed without turning verification into a general trust score.
The receiving workload hashes the exact bytes it expects to process and creates a challenge for the named presenter and action. Totem does not choose a JSON canonicalization scheme. The business protocol must preserve a stable byte representation between challenge creation and execution.
The presenter returns a signed presentation through the companies’ authenticated business channel. The receiver then consumes that presentation with its own scoped key. A challenge can be consumed once.
The presentation signature, expiry, nonce, audience, challenge, and request bindings must validate.
Both organizations and both agents must remain active, and the keys must still belong to the expected workloads.
The relationship, credential, action scope, recipient, time bounds, and optional request limits must still agree.
Totem locks the relevant records, consumes the challenge once, and appends the audit event in the same decision.
A receiver should act only after it receives HTTP 200, verified: true, an APPROVED result, the expected challenge identifier, and a request digest that matches a fresh local hash. Unknown response codes, malformed JSON, timeouts, network errors, and server errors are operational failures.
An approval does not establish that the request is safe, factually correct, legally binding, or within every local policy. The receiver still owns those checks. Review the security boundary before integrating the result into an irreversible action.
TotemLayer
See how Totem binds identity and current authority to one exact cross-company request.