Technical guide · Updated August 21, 2026
AI agent authentication and authorization solve different failures.
An API can authenticate the right agent and still permit the wrong action. Secure agent workflows prove the workload first, then evaluate its current authority for the resource, recipient, and request.
Keep the three questions separate.
Identity: which principal is this?
An agent identity is the durable record for a workload: its identifier, controlling organization, active state, verification material, and owner or sponsor where applicable. Identity gives policy a stable subject.
Authentication: can the caller prove it controls that identity?
Authentication validates a secret, signed assertion, certificate, workload token, or other proof. It should also check audience, issuer, expiry, key status, and replay controls. A display name or agent card is discovery data, not authentication.
Authorization: may this authenticated principal do this now?
Authorization evaluates action, resource, recipient, delegation, relationship, limits, and current state. The same agent may have permission to read one dataset and no authority to change it. A valid credential can also lose effect after revocation.
A cross-company request needs both checks.
Suppose an operations agent from Company A asks Company B to update a vendor record. Company B first authenticates the workload that presented the request. It then checks whether Company A has an active relationship, whether this agent may request vendor.record.update, whether the credential names Company B as recipient, and whether the proof covers the exact proposed update.
Reusing a shared API key can answer only part of that sequence. The key may identify an integration account while leaving the actual agent, delegation, action, and request ambiguous.
Authentication failure
The key is invalid, the signature is wrong, the proof expired, or the caller cannot prove control of the named agent identity.
Authorization failure
The caller is valid, but the action, recipient, relationship, amount, resource, or current policy does not permit this request.
Request-binding failure
The identity and permission look valid, but the proof covers different bytes or has already been consumed.
Application-policy failure
Identity and authority pass, but the receiver rejects the action under its own business, safety, or legal rules.
Design the decision from the receiver outward.
- Give the agent a dedicated machine identity instead of borrowing a human session.
- Use short-lived authentication material with a narrow audience and key lifecycle.
- Model the action and resource the receiver will enforce.
- Carry the user or organization delegation only when the policy needs it.
- Bind high-impact proof to a request identifier, nonce, digest, or equivalent context.
- Recheck revocation and relationship state near the action.
- Return structured failures and treat unavailable policy state as denial.
- Keep the downstream business gate in the receiving service.
How Totem applies the separation.
Totem uses separate agent-bound keys to authenticate presenting and receiving workloads. The receiver creates a single-use challenge for a presenter, action, and request digest. The presenter returns a short-lived signed presentation. At consumption, Totem rechecks identity, recipient, relationship, scope, limits, key state, credential state, and revocation.
The result gives Company B evidence for its local decision. It does not execute the update. See the Totem protocol for the complete request flow and failure handling.
TotemLayer
Verify the agent before your systems act.
See how Totem binds identity and current authority to one exact cross-company request.