Agents are already transacting
Agents acting on behalf of humans are already booking, buying, negotiating, and coordinating. They read calendars, write responses, place orders, request introductions, and increasingly talk to other agents rather than to human counterparties.
The infrastructure they are doing this on was not designed for agents. It was designed for human-operated clients with OAuth tokens. The mismatch produces the failure modes everyone now complains about: agents getting lost in confirmation loops, agents being scammed by other agents, agents taking actions the principal would never have approved.
All of these failure modes trace back to a missing identity layer.
What client auth cannot answer
Client-side authentication was designed to answer one question: does this application have permission to call this API on behalf of this user.
That question is useful. It is also insufficient for agent-to-agent commerce. The additional questions an agent needs answered at runtime include:
- Who is the principal behind this agent, right now, verified independently of the agent's own claim.
- What consent scope did the principal actually grant, with what expiration, for what counterparties.
- What cohort context is the agent operating inside of. Is the counterparty a stranger, a second-degree connection from a cohort the principal trusts, or an agent of a known peer.
- Can the principal revoke this action after the fact in a way that propagates across every downstream system, not just this one platform.
OAuth answers roughly zero of these. API keys answer fewer. Agent-to-agent commerce without a layer that answers them produces the failure modes we already see.
Principal verification
A principal is the human, organization, or entity the agent ultimately represents. Agents lie about their principal, accidentally or on purpose, constantly. An agent claiming to act for a specific CEO is trivial to construct and, today, nontrivial to verify.
An identity layer for agents needs to make principal verification cheap and machine-native. Not a manual confirmation dance. A runtime check an agent performs before it transacts.
Rhiz Protocol's approach is cohort rooted DIDs anchored in the event log. An agent can request a principal proof from a counterparty agent, verify it against the protocol, and decide whether to proceed. The verification is not a trust network. It is a verifiable claim.
Consent scope
Consent in most agent stacks today is binary. The user clicked accept on a terms page. Every transaction downstream is treated as consented.
For real agent-to-agent commerce, consent needs scope, expiration, and auditability. An agent acting under a principal's consent to book travel does not have consent to forward messages. An agent whose consent expires at the end of a 30 day window cannot keep operating after the window.
The Rhiz Protocol event log records consent as first-class events. An agent can ask the log what the current consent scope is, see exactly what was granted, for what counterparties, under what conditions, and refuse to act outside those bounds. This is not a nice-to-have. It is the difference between agents that behave predictably and agents that drift.
Cohort context
Reach-shaped identity has no way to express cohort context. A follow is a follow. A contact is a contact. An agent reading a contact list sees a flat set of names.
Cohort rooted identity gives agents the graph structure they need. An agent evaluating whether to accept an introduction from another agent can ask: which cohort was this relationship formed in, under what terms, how recent, with what signal history. These are things reach-based identity cannot answer.
Concretely, an agent that knows the human it represents is in Root Alpha can preferentially trust counterparty agents whose principals are also in Root Alpha, because the cohort context carries meaning the flat graph cannot.
Revocability
A principal must be able to revoke consent, cut off access, and unwind an agent's authority without chasing down every platform the agent touched. Client-level revocation does not compose across platforms.
Graph-native revocation does. If consent lives as events in a protocol log, revocation is also an event. Every downstream system that reads the log sees the revocation at the next read. The principal does not have to chase it.
This is the same reason event sourcing is non-negotiable in a trust protocol. The log is the source of truth. Revocation propagates from the log, not from each application's local state.
What this gives agent commerce
An identity layer that answers principal, scope, context, and revocation lets agent-to-agent commerce happen without the failure modes we currently see.
- Agents can verify counterparties cheaply.
- Agents cannot drift outside consented scope without leaving evidence.
- Agents can preferentially trust cohort-rooted relationships.
- Principals can revoke cleanly across every surface an agent operates on.
Without this layer, every platform builds its own partial answer. The result is a fragmented experience where agents behave differently on each surface, and the principals they represent cannot reason about what their agents are actually doing.
Where Rhiz Protocol fits
Rhiz Protocol exposes the primitives directly: cohort rooted DIDs, consent events, markdown-first profiles, graph-native revocation, event-sourced state. Any sovereign brand building an agent-era product can read those primitives and rely on them, rather than reinventing them.
The Rhiz Collective is the first consumer product built on the primitives. Partners building on the protocol layer get the identity layer as a dependency, not something they have to invent.
Where to go next
- Read the agent-era trust infrastructure hub.
- Read the protocol design hub for the first principles.
- Partner on Rhiz Protocol if you are building an agent-era product.
Agent commerce is happening whether the identity layer is ready or not. The job is to make sure it is ready.