Scoped workload keys
Presenter and receiver credentials are agent-bound, stored as digests, and limited to the protocol roles they need.
Totem security
How Totem protects identity and authorization data.
Totem is designed to fail closed at the cross-company verification boundary. This page states the implemented controls, the receiver's responsibilities, and the current production-beta limits.
The receiver controls the final action.
Totem verifies credential identity and narrow authority at a point in time. It does not execute the receiving company’s business action or decide whether that action is wise, lawful, or correct. The receiver must compare the verified request with its own policy and use idempotent downstream execution.
Implemented application controls.
Bound signed proof
Presentations carry a short lifetime and bind the presenter, recipient, challenge, action, limits, and request digest.
Live invalidation
Verification evaluates current agent, credential, relationship, and revocation state instead of trusting signature validity alone.
Protected application data
Sensitive signing material uses authenticated encryption, ordinary API keys are hashed, and production startup validates required secrets and profiles.
Fail-closed decisions
Malformed, expired, mismatched, replayed, revoked, unavailable, and unknown authorization outcomes do not become approvals.
Auditable reason codes
Verification records a bounded outcome and machine-readable reason while avoiding raw credentials and signed proof in normal logs.
Current production-beta limits are explicit.
- Application-managed signing keys are not hardware-backed in the current design.
- Most HTTP and API rate limits are process-local rather than globally coordinated.
- Organization domain control is a point-in-time DNS check, not legal-company or KYB proof.
- Totem does not claim an independent security certification on this page.
- Identity and authorization controls do not prevent every model, prompt, runtime, or supply-chain risk.
Integration teams should review the protocol requirements, use their own execution idempotency and reconciliation, and test failure behavior before a production rollout.
Report security issues privately.
Do not open a public issue for a suspected vulnerability. Use the repository’s private security advisory form with a concise impact statement, affected component, reproduction steps, proof of concept, and suggested mitigation when available. Do not include live user data, production secrets, or destructive testing results.
Totem’s disclosure policy does not authorize denial of service, social engineering, data extraction, or testing against accounts and organizations you do not control.
TotemLayer
Verify the agent before your systems act.
See how Totem binds identity and current authority to one exact cross-company request.