Technical guide · Updated August 21, 2026
Design AI agent credentials for one bounded job.
A credential should identify a dedicated agent principal and constrain where, when, and how that principal may use it. Issuance is only the start of the lifecycle.
Put the decision-relevant claims in context.
Subject
Identify one agent principal, not a shared team account or an unnamed automation pool.
Issuer and controller
Record who issued the credential and which organization controls the agent lifecycle without implying legal-company verification.
Audience and recipient
Name the intended service or receiving organization so valid proof cannot be moved to a different target.
Scope and action
Use machine-readable permissions narrow enough for the receiver to compare with the exact requested operation.
Include an issue time, expiry, stable credential identifier, and key identifier when the format supports them. Treat descriptive claims as evidence for policy, not as approval by themselves.
A valid bearer credential is still replayable.
Possession of a reusable token may be enough to impersonate the agent until expiry. A short lifetime limits the window but does not bind the token to one method, target, body, or transaction. Sensitive requests need proof that covers the receiver’s fresh context.
Bind proof to an audience, receiver-created nonce or challenge, exact action, and request digest. The receiver should consume single-use state atomically and compare the request again immediately before the downstream action.
Protect raw material and reduce its reach.
- Keep raw credentials in a secret manager available only to the agent workload.
- Separate development, test, and production principals and audiences.
- Never place credentials in URLs, logs, traces, analytics events, or support tickets.
- Give presenter and receiver workloads different keys and scopes.
- Store ordinary API keys as one-way digests on the server.
- Encrypt recoverable private signing material with authenticated encryption.
Plan rotation and revocation before issuance.
Every credential needs an owner, creation record, last-used signal, expiry, rotation path, and revocation path. Rotation should allow a short overlap only when the protocol needs it. Revocation should invalidate a compromised key, an agent, or a company relationship without waiting for every issued proof to age out.
Monitor failed verification by reason, unexpected audiences, repeated nonces, old key identifiers, and use after revocation. Do not record the credential or signed proof in the monitoring event.
Totem narrows credentials at presentation time.
Totem uses agent-bound API keys for protocol authentication and short-lived, recipient-bound credentials for authority. A receiver-created challenge ties the signed presentation to the presenter, recipient, action, and exact request digest.
Verification also checks current credential, agent, relationship, and revocation state. See AI agent authorization for the decision boundary and the Totem protocol for the wire flow.
TotemLayer
Verify the agent before your systems act.
See how Totem binds identity and current authority to one exact cross-company request.