Identity for agentic payments: principals, agents, and counterparties

Start with roles

One transaction, several identities

Agentic payments involve more identities than an ordinary browser checkout. The principal is the person or organization whose money and objective are at stake. The agent is the software instance selecting or preparing the economic action. An operator may host that agent, a merchant accepts the order, an issuer or wallet controls the payment capability, and a rail identifies the accounts that ultimately send and receive value. Treating any one of these identities as a substitute for the others creates an accountability gap.

A useful identity model records both the asserted identity and the method used to establish it. A user session may authenticate the principal, a signed HTTP request may recognize an agent, an API credential may identify an operator, and a token or wallet address may identify a payment instrument. These facts are related, but none independently proves that the exact purchase was allowed. Authorization must bind the authenticated principal and recognized agent to a specific mandate and transaction envelope.

Authentication and agent recognition do not grant spending authority

NIST digital identity guidance separates proofing, authentication, federation, and lifecycle controls because each answers a different trust question. The same separation matters for agents. A valid signature can establish that a request came from a holder of a particular key. Agent-recognition systems can help merchants distinguish declared automation from unknown bots. Neither fact shows that the principal approved the seller, amount, item, timing, or terms in the request.

Production acceptance therefore uses two gates. The identity gate checks the actor, key status, issuer, request integrity, freshness, and replay protection. The authority gate checks a mandate or policy decision bound to the order. Visa's Trusted Agent Protocol and HTTP Message Signatures illustrate recognition and signed-message mechanisms; Google's AP2 work emphasizes mandate evidence. They can complement one another, but their responsibilities should remain explicit in code, logs, and operator runbooks.

• Reject signatures from unknown, expired, rotated, or revoked keys before evaluating business policy.
• Bind the authenticated principal session to mandate issuance rather than trusting an agent-supplied user identifier.
• Treat merchant and destination identity as policy inputs, not display-only receipt fields.
• Preserve the verification method and key identifier so an auditor can reproduce the identity decision.
• Require new authorization when identity context changes in a way that changes economic risk.

Use stable identifiers across trust boundaries

Display names, model names, and wallet labels are not durable identifiers. The evidence chain needs opaque, stable identifiers for principal, agent instance, operator tenant, mandate, order, policy decision, credential, payment, and merchant. Those identifiers should remain joinable after a model version changes, a key rotates, a payment processor retries, or a merchant replaces a checkout session. Human-readable labels may accompany them, but should never be the join key.

Identifiers also need scope. An agent identifier issued by one operator may have no meaning to another. A merchant account identifier may be processor-specific. A wallet address identifies a cryptographic account, not necessarily the legal or operational actor controlling it. Store issuer and namespace with every identifier, normalize only where a trusted mapping exists, and retain the evidence that justified a mapping. False identity merges are harder to detect than missing links because they create a plausible but incorrect transaction story.

Identity is useful only when the system can state who issued the identifier, what it identifies, and which verification made it trustworthy for this transaction.

Design identity lifecycle controls before launch

Identity controls must cover enrollment, normal use, rotation, compromise, suspension, and retirement. Register agent keys through an authenticated operator workflow, separate production and test identities, and make key status available to every verifier. Revocation has to propagate quickly enough to stop new economic actions, while historical receipts continue resolving the key that was valid when an earlier request was accepted. Deleting that history can make legitimate transactions impossible to explain.

Operational reviews should sample the complete chain rather than checking authentication in isolation. For a chosen payment, an operator should be able to start from the principal, identify the acting agent and deployment, reproduce signature verification, locate the applicable mandate, identify the merchant and payment destination, and explain any identity mapping. If a link is based only on mutable application state or an unverified claim copied from the request, it is not yet reliable evidence.

• Inventory identity issuers and document the assurance expected from each one.
• Keep authentication secrets and signing keys outside the language-model context and tool arguments.
• Log verification outcomes and references, not raw credentials or unnecessary personal data.
• Test key rotation, stale metadata, tenant deletion, account recovery, and compromised-agent containment.
• Define who can correct a mistaken identity mapping and how the correction is attached to prior records.