Before Money Moves: Identity, Intent, and Delegated Authority
For an agentic payment, the most consequential decisions often happen before a transaction is signed. This chapter examines the pre-payment trust layer: how a system identifies the counterparty, binds an agent to a principal and a particular purpose, and limits what the agent may do. The reader should come away able to distinguish a reachable service from an attributable one, a technical capability from actual authority, and a single permitted transaction from a behaviorally safe spending pattern.
The distinction matters because an agent does not receive a neatly packaged instruction in the same way a human cashier does. A principal may express a goal, a budget, and a few constraints. The agent then interprets that request, searches for a service, compares options, and decomposes the work into calls to tools or other agents. Each step can add information, but each can also introduce a new counterparty, a new interpretation, or a new opportunity for manipulation. The infrastructure must preserve enough meaning for the eventual payment to remain attributable to the original purpose.
Discovery is not identity
Discovery answers a practical question: where might the agent obtain the service it needs? A system can discover a service through a structured capability description, a registry, or evidence from previous interactions. These approaches are useful because an agent cannot negotiate with a counterparty it cannot locate. But they establish different kinds of knowledge, and none should be mistaken for proof that the selected service is safe or institutionally admissible.
Descriptor-based discovery starts with a description of what a service claims to do. The description may include supported actions, invocation formats, pricing, or payment requirements. It is efficient for machine coordination: an agent can compare declared capabilities rather than asking a person to interpret every provider page. Its weakness is that the description is an exposed claim. A counterfeit endpoint, a deceptive registry entry, a spoofed agent card, or a typosquatted domain can present the right vocabulary while pointing to the wrong service.
Identity-augmented discovery adds information about the relationship around the service. The record may connect an agent to an operator, a wallet, a principal, a delegation, a credential, or a history of activity. This makes the candidate easier to attribute and can support checks that a bare capability description cannot. It still does not prove that the service will perform as promised. An identified provider can be unreliable, compromised, or unsuitable for a particular jurisdiction or mandate.
Behavior-derived discovery ranks candidates using signals from prior interactions. Payments, service traces, or feedback can act as evidence about past behavior, especially when a new request is too specific for a simple capability match. But behavior signals introduce their own incentives. Feedback can be manufactured, identities can be multiplied, and reputation can become a target for collusion. A history of activity is evidence to weigh, not a substitute for a current authorization and outcome check.
The difference between these approaches becomes concrete when an agent chooses between two providers that both advertise the same service. A descriptor can show that both accept the required request format. An identity record can show who operates them and which wallet or endpoint is associated with each. A behavior signal can suggest that one has performed reliably in the past. Yet the payment system may still need to check whether the provider is approved for this principal, jurisdiction, asset, or type of data. Discovery is about resolving a candidate; admissibility is a separate decision.
That separation also protects against a subtle failure. If an agent forms a payment intent from a false description, later layers may work exactly as designed. The authorization service can check the amount. The wallet can enforce a spending cap. The settlement rail can confirm the recipient. The accounting system can preserve the transaction. All those local checks can pass while the payment is bound to the wrong service. Downstream correctness cannot repair an upstream failure to identify the economic object.
A serious identity record therefore needs more than a name or address. The research on agentic finance describes a useful bundle: an operator or owner, a service endpoint, the model or software version, the wallet authority, the tasks the agent is permitted to perform, and evidence about its behavior. The purpose is not to claim that a registry makes an agent trustworthy. The purpose is to make a claim inspectable and to give later authorization and accounting something more specific than “the endpoint responded.”
TessPay's proposed architecture illustrates one way to make that bundle durable. It separates an off-chain registry containing an agent manifest from an on-chain registry that anchors identity, ownership, and a cryptographic commitment to the manifest. It also proposes a naming service for stable, human-readable agent domains. In that design, discovery can resolve a declared capability to an identity and ownership record before orchestration assigns the task. These are design mechanisms in a proposal, not an established universal standard. They reduce ambiguity only if the records are maintained, the ownership claims are meaningful, and the verification rules check more than registration status.
Authentication is narrower still. A signature can prove control of a key. A credential can prove that an endpoint presents a recognized token. Neither fact necessarily establishes which software instance acted, which legal principal authorized it, whether its capability description is current, or whether the action is allowed in the present context. Identity is a relationship among actor, operator, principal, capability, and evidence. Authentication is one input to that relationship.
The relationships in the diagram matter more than the labels. A principal approves a mandate; the mandate scopes a policy; the agent identity declares capabilities and selects a counterparty; the policy constrains the payment; the resulting action produces evidence that points back to the mandate. No single object answers every question. Safe delegation depends on the links between them.
Turn intent into authority without making it permanent
Once a candidate counterparty is identified, the system must decide what the agent is allowed to do. A natural-language request is a starting point, not a complete spending policy. It may express a goal but omit a recipient, a time window, acceptable substitutes, evidence requirements, or a rule for what to do when information is ambiguous. If the agent converts the request directly into a wallet signature, interpretation has silently become unlimited authority.
Intent binding is the mechanism between the open-ended request and the concrete transaction. One simple form places payment terms in the interaction itself: a service responds with the asset, amount, recipient, and conditions it requires, and the client returns the corresponding payment. This can make a machine-to-machine exchange efficient, but it may bind the payment only to the immediate request. It does not necessarily bind the result to a particular session, principal, or service outcome.
A stronger form carries context and provenance. The payment is linked to the user or institution, the particular agent instance, the session, the task, and the constraints that give the action meaning. That linkage is important when an agent decomposes one goal into several calls. It lets the system ask whether a later payment belongs to the approved workflow rather than treating each call as a fresh and unrelated authorization.
TessPay proposes three named mandates for this purpose. An Intent Mandate captures the user's high-level request. A Cart Mandate records the concrete items or services and their pricing after negotiation. A Payment Mandate locks in the financial terms and authorization scope. The names belong to TessPay's design, but the underlying separation is broadly useful: preserve the purpose, record what was selected, and then authorize the money movement. In the proposal, the mandates are retained as audit records and linked to workflow and escrow identifiers so that later proof and settlement can refer to the same obligation.
The value of this separation is visible when the agent encounters a substitute. A user may authorize a service within a budget but not authorize any provider, any asset, or any quality level. The intent can describe the purpose; the concrete service choice can make the trade-off visible; the payment terms can define the amount, recipient, timing, and acceptable scope. If those layers are collapsed, the agent's interpretation disappears into the signature. If they remain linked, a reviewer can see where the decision entered the workflow and what was actually approved.
Authority then has to be enforced somewhere. The SoK on blockchain agent payments organizes the options in two useful dimensions. The first is the carrier of authorization. Contract-mediated delegation controls which functions an agent can invoke. Allowance- or approval-mediated spending controls which assets an approved spender can transfer and within what limits. Wallet-mediated programmable authorization, including account-abstraction designs, places validation logic inside a smart-account layer that can inspect signatures, policies, and context before an operation executes.
The second dimension is policy expressiveness. Access-level rules say which operations or contract functions are available. Transaction-level rules constrain amount, asset, recipient, or other parameters. Contextual and stateful rules can incorporate time, cumulative spending, interaction history, or a delegation scope. The progression is not a ranking in which the most expressive policy is always best. Richer rules can capture more of the principal's purpose, but they also require more state, more reliable inputs, and more careful operations. A policy that cannot be observed or updated safely may create a different failure surface.
This is why capability and authority must remain separate. An agent may be technically capable of querying a sanctions service, routing a trade, or signing a transaction. Capability describes what the system can do. Authority describes what the system is permitted to do for this principal, in this workflow, at this time. A capability manifest can help discovery; it should not be treated as a grant of permission.
TessPay's proposed Agentic JWT, or A-JWT, shows how a design might carry that permission into execution. The proposal describes a token issued by an authorization service after user intent has been captured and scoped to a workflow step. It also binds an integrity hash of the agent's defining characteristics, such as its system prompt and tool configuration, and uses proof-of-possession keys to limit replay. In the intended architecture, the service agent can operate only within the scope represented by the upstream mandates and A-JWT. This is a proposal-specific mechanism. Its value depends on whether the identity snapshot, scope, revocation, and execution evidence are checked consistently rather than simply attached as metadata.
A bounded wallet should enforce the controls that must survive a badly behaved coordinator. Spending caps, asset restrictions, approved counterparties, time windows, session-key limits, and emergency revocation are candidates for this layer. Richer decisions—whether a counterparty is appropriate, whether a source is credible, whether a goal has changed meaning, or whether a policy exception deserves escalation—may require an off-chain rules engine and an accountable human or institutional owner. The split is practical: hard constraints should be difficult to bypass, while semantic judgments need room for context and review.
Even a careful policy can fail over time. Imagine an agent with a per-transaction limit and an approved recipient. It might repeat an action after an unclear response, fragment a larger purchase into many permitted transfers, or continue making routine payments after the principal's circumstances change. Each transaction can remain locally admissible while the sequence exceeds the purpose of the delegation. A second agent might divide activity across identities, making each account look compliant while the composed workflow is not.
This is the difference between transaction-level validity and behavioral correctness. A rule checks the action presented to it. Behavioral control asks whether the pattern of actions remains consistent with the mandate. The latter requires history, state, anomaly signals, and a response when the pattern changes. Monitoring is not just a dashboard; it must be connected to the ability to tighten permissions, pause execution, revoke a session, or require human approval.
Model and tool changes make the problem more persistent. An agent's wallet policy may remain unchanged while a model update changes how it interprets a request. A tool may change its output format or behavior while the agent's mandate remains the same. A new counterparty may satisfy a static allowlist but introduce a different risk. That is why the broader governance framework treats provenance and lifecycle management as part of authority: the system should know which version acted, which tools it used, and how permission can be withdrawn.
The pre-payment trust layer is therefore a chain, not a credential. Discovery needs attributable identity; identity needs a meaningful operator and principal; intent needs durable scope; authority needs enforcement close to the wallet; and behavior needs monitoring beyond one transaction. These links make an agent's permission narrower and more inspectable without requiring a person to approve every low-value action manually.
But they also expose the next boundary. Before execution, the system may know who the agent is and what the agent is allowed to do. That still does not prove that the service will be delivered or that payment should be released. The decisive question is how these pre-money commitments connect to the architecture that holds keys, observes execution, and decides whether a financial obligation has actually been fulfilled.