Trust at Machine Speed: Identity, Receipts, and the Audit Layer Agent Commerce Needs

Most demos of agentic AI work because the failure modes that matter live outside the demo's frame. The agent looks competent because the demo is structured to let it look competent, a single well-formed task, a sandboxed environment, a willing human in the loop, no consequence to a wrong answer. The chasm between this demo and a system you would let cancel a subscription, dispute a charge, or bind you to a contract is enormous, and almost all of it is in the trust layer.

Trust at machine speed is not a feature. It is the infrastructure that determines whether an agent can be deployed against real-world consequence at all. This paper walks through what the trust layer must contain, why each component is load-bearing, and where the engineering effort is most often underbuilt. We write from the perspective of a team that ships agents into production, not from the perspective of researchers describing what would be ideal in theory.

The four primitives

A trust-layer architecture for agent-to-agent commerce has, in our framing, four primitives. None of them is optional. Skipping any one of them produces a system that demos well and breaks in production.

Identity. Each agent must be cryptographically identifiable, both to its principal (the human or organization on whose behalf it acts) and to other agents it transacts with. The shorthand the industry has converged on is "Know Your Agent," KYA, structurally analogous to KYC in the financial industry. KYA answers two questions: which agent is this, and which entity is it authorized to represent. Without an answer to both, no counterparty can responsibly accept a binding action from the agent.

Authority. Identity says who the agent is. Authority says what the agent is allowed to do. Bounded authority, the explicit declaration of what the agent can commit on behalf of its principal, is what allows the principal to delegate confidently. A consumer advocate may have authority to dispute charges up to a dollar threshold and below a confidence threshold, but require human confirmation above either. A brand agent may have authority to issue refunds within a discount ceiling but require manager approval above it. Authority must be machine-readable, enforceable at the protocol level, and inspectable by both sides of the conversation.

Receipts. Every transaction concluded between two agents must produce a signed, immutable receipt that both parties can later present as evidence. The receipt is what makes the transaction actually a transaction rather than just a conversation. It records what was agreed, by whom, under what authority, on what date, with what consideration, and is verifiable by either party against the cryptographic identities established in primitive one. Receipts are the durable artifact that survives the conversation; they are also what regulators, auditors, and dispute-resolution processes operate against.

Watchers. The hardest of the four to get right. A watcher is a separate model: usually a smaller, faster classifier, whose job is to catch the proposed action before it happens and confirm whether it is binding. If the action is binding (cancellation, contract change, payment commitment, plan switch), the watcher requires explicit principal confirmation before the agent can proceed. If the action is not binding (information lookup, draft message, status check), the watcher passes it through. The watcher is what prevents the agent from confidently taking actions that no human authorized. It is the brake.

Why each primitive is load-bearing

Identity without authority is meaningless: a counterparty can verify who is on the other end of the conversation but cannot verify what that party is allowed to commit. Authority without identity is impersonation: anyone could claim to act on anyone else's behalf with no way to verify the claim. Receipts without identity and authority are unsigned: there is no way to enforce them later. Watchers without the other three are an isolated safety mechanism with no integration into the transaction record.

Each primitive depends on the others. The trust layer is one architecture, not four independent features. Teams that ship some primitives but not others discover their gaps in production, usually after a public incident.

Where the engineering effort is most often underbuilt

In our experience working with brand-side teams deploying agentic systems, the underbuilt component varies by team but the pattern is consistent: teams overbuild what is technically interesting and underbuild what is operationally necessary.

The most common gap is watchers. Watcher classifiers are unglamorous engineering. They require a continuously updated taxonomy of binding actions, a small fast model running on every proposed action, a clean interrupt path back to the principal, and integration with the agent's tool-use layer. None of this is novel research. All of it is necessary. Teams that focus on the foundation model and treat the watcher as a downstream concern ship agents that confidently issue refunds, cancellations, and contract changes that no human authorized.

The second most common gap is receipts. Most teams ship logging and call this the receipt layer. Logging is necessary but insufficient. A receipt is an artifact you can hand to a regulator, an auditor, a counterparty, or a court, and have them verify cryptographically that it represents what actually happened. It must be signed, immutable, time-stamped, and parseable by parties who do not trust the original system. Logging is observability for engineers; receipts are evidence for institutions. Teams routinely confuse the two.

The third gap is identity portability. KYA proposals assume that an agent's identity is stable across the platforms it transacts on. In practice, today's agents authenticate through proprietary handshakes specific to each counterparty, which means the same agent has dozens of unrelated identities in different systems. A unified identity standard, analogous to OAuth or DIDs, is the unsolved coordination problem at the bottom of the trust stack. Until it is solved, every agent-to-agent integration is custom work, and the network effects of a marketplace cannot fully compound.

The cancellation problem, in detail

A specific scenario clarifies what the trust layer must handle. Consider an agent acting on a consumer's behalf to cancel a subscription. The cancellation is binding: it terminates a recurring contract, has financial consequences, and may trigger downstream effects (loss of services, loss of grandfathered pricing, eligibility changes for related products).

A demo-quality agent will execute the cancellation when asked. A production-quality agent must do all of the following: classify the action as binding via the watcher; surface the cancellation to the principal for explicit confirmation; verify that the principal's confirmation is fresh and intentional (not a stale instruction reused from a different context); execute the cancellation under bounded authority; obtain a signed receipt from the brand-side agent confirming the cancellation; record the receipt against the principal's account; and surface a notification that the cancellation has been completed and what the consequences are.

Each of these steps is a separate engineering investment. Each can be skipped, and each is sometimes skipped in early implementations. The teams that skip them ship agents whose cancellations produce customer support tickets ("you cancelled my service, but I never authorized that"), regulatory inquiries, and reversed charges. The teams that build all of them ship agents that customers, regulators, and counterparties can responsibly transact with.

The trust stack as moat

A point that is often missed in discussions of agentic AI competition: the trust layer is not just a cost of doing business. It is a moat.

Building all four primitives: identity, authority, receipts, watchers, is genuinely hard. The engineering takes years to mature and requires close coordination with regulators, payment networks, and counterparty platforms. The companies that complete this build will have an advantage that no foundation-model improvement can erase. A more capable model on top of a weak trust layer is not deployable; a less capable model on top of a strong trust layer is. The trust layer determines deployability, which determines revenue, which determines the ability to compound product investment.

Investors evaluating agentic AI companies should ask, specifically, about each of the four primitives. Vendors evaluating partner platforms should require them. Builders inside companies should plan for all four from day one. The temptation to ship the model first and build trust later is the most common path to a public failure that erases the company's credibility before it has the chance to mature.

Closing

Trust at machine speed is the infrastructure that makes agentic commerce possible. Without it, agents are demos. With it, agents are systems that consumers, regulators, and counterparties can responsibly use. The four primitives are not optional, and the engineering effort to build them properly is larger than most teams budget for. The companies that complete this build will define the trust standards for the next decade of customer engagement, and the ones that don't will spend the next two years explaining their incidents.

We expect identity standardization to be the unlock event that makes the next phase of agent-to-agent commerce possible at industry scale. Until that event lands, the per-counterparty integration burden will limit network density. After it, the network compounds quickly. We are watching the standards bodies closely and contributing where we can.