How AI agents should authenticate to APIs.

A shared integration key makes attribution and revocation coarse. A borrowed human token hides whether a person or autonomous workload made the call. Register each production agent as a separate machine principal and record the organization or user that controls its lifecycle.

Give separate credentials to separate runtime roles. An agent that presents proof should not automatically receive the receiver’s verification capability. Development, test, and production agents should also use different credentials and audiences.

Credential type does not settle authorization. The API still needs to evaluate the action, resource, delegation, recipient, and current policy after authenticating the caller.

• Store raw keys in a secret manager available only to the agent workload.
• Send credentials in an authorization header over HTTPS.
• Exclude keys and signed proof from URLs, command arguments, logs, traces, and metrics.
• Use short lifetimes where automated renewal is reliable.
• Rotate after suspected exposure and revoke access that is no longer needed.
• Log a credential identifier or prefix rather than the credential itself.

A server should store ordinary long-lived API keys as one-way digests. Recoverable signing keys require authenticated encryption and tighter operational controls.

A valid bearer token can be replayed until it expires. High-impact agent calls benefit from a nonce, audience, narrow expiry, request digest, and single-use state. The receiver should create or validate that context rather than accepting a request identifier chosen only by the presenter.

Hash the exact bytes the application will process. If middleware parses and reserializes a request, define a stable representation before hashing. Compare the digest again near the downstream action so a successful proof cannot be applied to changed content.

Reject missing credentials, wrong audiences, unknown issuers, invalid signatures, expired tokens, insufficient scopes, revoked principals, reused proof, and mismatched request context with machine-readable reason codes. Rate-limit on a trusted server-derived client identity.

Timeouts, malformed responses, unavailable policy stores, and new unknown reason codes must not become approvals. Keep retries idempotent and reconcile the original request before generating new proof.

Totem authenticates the presenter and receiver with separate scoped keys, then binds a short-lived presentation to a receiver-created challenge, recipient, action, and exact request digest. The receiving service consumes that proof once and enforces the result.

This flow complements the authenticated business channel that carries the challenge and presentation. Read the protocol reference for endpoints, lifetimes, idempotency, and failure codes.