Least-privilege keys
Presenter and receiver workloads use separate agent-bound API keys with only the protocol scopes they need.
AI agent security
Totem puts identity and current authority in the receiving company's request path. It narrows the proof to a presenter, recipient, action, and request digest, then records the verification outcome.
Presenter and receiver workloads use separate agent-bound API keys with only the protocol scopes they need.
A challenge expires after five minutes and the signed presentation after no more than one minute.
The receiver supplies a SHA-256 digest of the bytes it will process and checks that digest again before execution.
Agent, credential, API-key, and company-relationship revocation affect current verification rather than waiting for an old token to expire.
Totem rejects a request when signature, identity, recipient, relationship, action, scope, limits, expiry, request digest, or revocation state does not match. It also treats malformed input and unavailable authority state as failures rather than approvals.
A receiver should not create a fresh challenge after an ambiguous response until it reconciles the original request. It should retain the same idempotency key only for the exact same challenge input and respect any retry interval returned by the service.
Totem does not inspect whether a business request is wise, lawful, or factually correct. It does not make the downstream action part of the verification transaction. The receiver needs its own authorization policy, execution idempotency, reconciliation, monitoring, and incident response.
Totem is a production-beta service. The current repository documents application-managed signing keys, process-local limits for most HTTP and API traffic, and point-in-time DNS control checks. It does not claim an independent security certification. The integration protocol describes the controls that callers must implement.
TotemLayer
See how Totem binds identity and current authority to one exact cross-company request.