Security guide · Updated August 21, 2026
Secure agent-to-agent communication at the receiving boundary.
Transport encryption protects a channel. The receiving company still needs to identify the calling workload, verify current delegated authority, bind proof to the request, and control execution.
Model the failures that change the receiver's decision.
Impersonation
A caller presents a shared or stolen credential and claims to be a different agent or company.
Replay
A previously valid message or proof is submitted again before it expires or after the first action succeeds.
Request substitution
Valid proof for one method, body, amount, resource, or recipient is attached to different business content.
Confused deputy
A trusted receiver is induced to use its own authority for an action the calling agent was never permitted to request.
Stale authority
The agent, credential, delegation, or company relationship is revoked after proof was issued but before use.
Ambiguous retry
A timeout causes the caller to create new proof and the receiver performs the same real-world action twice.
Give each layer one clear job.
- Transport: use authenticated HTTPS between known service endpoints and validate the expected hostname and certificate.
- Workload authentication: identify the exact agent principal rather than relying on an IP address, user agent, or shared team credential.
- Delegation and authorization: check who granted authority, which recipient and action it covers, and whether it is live now.
- Request integrity: bind proof to a receiver-controlled challenge and the exact bytes or stable representation that the application will process.
- Execution: enforce application policy, idempotency, reconciliation, limits, and audit logging after verification succeeds.
Let the receiver control fresh context.
The receiving service should choose the recipient, requested operation, digest, and fresh nonce or challenge. It should reject proof with a wrong audience, expired time window, missing permission, unknown issuer, reused state, or changed request content.
Consume single-use proof atomically. Keep the same business idempotency key across safe retries, and reconcile the original attempt after an ambiguous response before issuing new proof.
Interoperability is not the same as business authority.
Agent-to-agent and agent-to-tool protocols can standardize discovery, messages, tasks, or context exchange. They do not automatically prove that one company currently permits its agent to ask another company for an exact business action.
Use the protocol’s authentication hooks where they fit, then add the identity, delegation, recipient, action, freshness, and revocation evidence your receiver needs. Avoid claiming conformance to a standard until the implementation has passed the relevant interoperability or conformance checks.
Totem supplies bounded proof, not the business action.
Totem lets a receiver challenge a registered external agent for a signed, request-bound presentation. Verification checks identity, recipient, scope, limits, expiry, relationship, request digest, and current revocation state.
The receiver then applies its own policy and executes through its own system. Read the protocol reference for the handshake and AI agent security for the product’s limits.
TotemLayer
Verify the agent before your systems act.
See how Totem binds identity and current authority to one exact cross-company request.