The Three-Party Web
Published March 17, 2026, by Frans
Every relationship on the internet is adding a third participant.
Since its inception, the web has been a two-party system: a user and a service. The user navigates to a website. The website serves content. The user takes an action. The website processes it. Every protocol, every legal framework, every business model is built on this bilateral relationship.
The agent internet introduces a third party. The relationship becomes: user → agent → service. This isn't a minor topological change. It restructures trust, liability, identity, and consent, the foundational primitives of every online interaction.
The Two-Party Model
In the traditional web:
User ←→ Service
The user authenticates directly. The service knows who they're dealing with. Terms of service are between two parties. Liability is straightforward: the user clicked "buy," the service charged the card. If something goes wrong, there are two seats at the table.
Trust is bilateral. The user trusts the service to deliver what it promised. The service trusts the user to pay. This simplicity is why the two-party web scaled to billions of transactions.
The Three-Party Model
In the agent internet:
User ←→ Agent ←→ Service
Now there can be three entities, and every aspect of the relationship needs renegotiation.
Trust Becomes Tripartite
Each party must trust the other two:
| Trust Relationship | Question |
|---|---|
| User → Agent | "Will this agent faithfully represent my intent and not act beyond what I authorized?" |
| User → Service | "Will this service deliver what the agent negotiated on my behalf?" |
| Agent → Service | "Will this service respond reliably to structured requests?" |
| Service → Agent | "Is this agent actually authorized to act for a real user? Is it going to abuse my platform?" |
| Service → User | "Is there a real, accountable human behind this agent?" |
| Agent → User | "Will the user provide clear intent and approve actions when needed?" |
Six trust relationships instead of two. Each one needs to be established, maintained, and enforced.
Identity Becomes Layered
On the two-party web, identity is simple: the user logs in. Cookie, session token, OAuth. The mechanisms vary, but the concept is uniform. One entity authenticates to another.
On the three-party web, identity has layers:
- User identity — The human who delegated the task. They have accounts, credentials, payment methods.
- Agent identity — The software acting on the user's behalf. It needs to prove it's authorized by the user without possessing the user's credentials.
- Session identity — The specific interaction context. Multiple agents may act for the same user simultaneously, each needing isolated state.
The critical design question: how does an agent authenticate to a service on behalf of a user without the user handing their credentials to the agent?
The answer is the runtime layer. The user authenticates once in the runtime. Agents send instructions to the runtime, which executes them. The agent never sees the user's password, OAuth token, or session cookie.
This is fundamentally different from giving an agent your API key. The agent does not have your credentials. It has access to an environment that does.
But runtime-managed credentials only solve half the problem. The service still needs to answer: is this agent actually authorized by a real user? I propose the mechanism for this is an attestation: a cryptographic proof, issued by the runtime, that vouches for an agent's authorization. An attestation is scoped (specific permissions), time-bound (expires), and verifiable (the service can check it without trusting the agent directly).
This raises a second-order question: who vouches for the runtime? If any software can claim to be a runtime and issue attestations, the system collapses. The answer is the Open Agent Trust Registry — a federated, cryptographically-signed public registry of trusted runtimes, analogous to how browsers maintain a list of trusted Certificate Authorities for HTTPS. Services verify attestations against the registry. Runtimes earn inclusion through demonstrated compliance with security and supervision standards. The registry is open source.
Critically, the registry must be federated, not centralized. Multiple runtimes should compete on quality, privacy, and features — just as multiple Certificate Authorities compete in the TLS ecosystem. A single gatekeeper for agent identity would concentrate too much power. The architecture should enable competition among identity providers while maintaining a shared trust anchor that any service provider can verify against. This is explored in depth in Identity and the Agent Internet.
Consent Becomes Continuous
On the two-party web, consent is mostly front-loaded. You agree to terms of service when you sign up. You click "buy" once per purchase. Consent is event-driven: a single moment of agreement.
On the three-party web, consent must be continuous because the agent acts over time, across services, in ways the user may not have explicitly anticipated.
Consider: you tell your agent "find me the best deal on a 4K monitor." The agent searches five retailers, compares prices, checks reviews, finds a coupon code, adds the item to a cart, and presents you with the option to purchase. At which point did you consent to each of those steps?
The framework that works is supervision tiers:
| Action Type | Consent Model |
|---|---|
| Read (search, browse, extract) | Implicit — delegating the task implies permission to look |
| Write (submit forms, send messages) | Explicit — the user reviews and approves before execution |
| Financial (purchases, transfers) | Confirmed — requires active user confirmation with full context |
| Sensitive (medical, legal, personal) | Gated — may require re-authentication or additional verification |
This isn't a one-time checkbox. It's an ongoing supervision contract between the user and the runtime, enforced continuously throughout the task.
Liability Becomes Distributed
When something goes wrong in a two-party transaction, liability is relatively clear. The user disputes a charge. The service issues a refund. Existing legal frameworks handle this.
When an agent is in the middle, it gets complicated:
Scenario: An agent, acting on a user's instruction to "buy the cheapest flight to Tokyo," purchases a non-refundable ticket with a 14-hour layover. The user is unhappy.
Who is liable?
- The user gave a vague instruction
- The agent interpreted "cheapest" literally without considering layover duration
- The service sold a valid ticket at the requested price
- The runtime routed the request and facilitated the transaction
There's no clean answer because the existing legal framework assumes two parties. The three-party web needs new frameworks for:
- Agent disclosure — Services need to know when they're interacting with an agent vs. a human
- Intent fidelity — Was the agent's action a faithful interpretation of the user's intent?
- Supervision compliance — Did the runtime enforce appropriate oversight?
- Recourse paths — When something goes wrong, what's the dispute resolution process?
These aren't theoretical concerns. They will be tested in court. The frameworks established at this stage will shape those outcomes.
Design Principles for the Three-Party Web
Given these new dynamics, I propose six principles for systems operating in the three-party web. Notably, these are principles and runtimes, agent creators, and services may make independent decisions.
1. Credential Isolation
The agent never holds user credentials. The runtime manages authentication in a secure, user-controlled environment. The agent sends intent; the runtime executes in authenticated context. When a service needs proof of authorization, the runtime issues a scoped attestation — the agent never touches the underlying credentials.
2. Continuous Supervision
Consent is not a one-time event. The runtime enforces ongoing supervision, with escalation tiers based on action sensitivity. Users can tighten or relax supervision per service, per agent, or per action type.
3. Transparent Attribution
Every action is attributable. The audit trail records which user delegated, which agent acted, which service was involved, what the outcome was, and what supervision policy was applied. This creates the evidentiary record needed for dispute resolution.
4. Agent Disclosure
Services have the right to know they're interacting with an agent. The runtime identifies itself through cryptographic attestations that services can verify against the Open Agent Trust Registry. This gives services verifiable proof of agent authorization — not just a self-reported claim.
5. User Sovereignty
The user retains ultimate authority. They can override any routing decision, block any service, revoke any agent's access, and review any action, past or pending. The agent is a delegate, not a decision-maker.
6. Graceful Degradation
The three-party model must coexist with the two-party model. Not every service will support agent interaction. Not every user will use agents. The system must work across the spectrum from fully human to fully delegated, without requiring universal adoption to be useful.
The Relationship Map
The four layers interact top-down through the runtime:
| Layer | Role | Examples |
|---|---|---|
| User | Delegates intent, reviews and approves | The human who initiated the task |
| Runtime | Trust broker, credential vault, supervision, capability routing | The agent internet infrastructure layer |
| Agents | Execute subtasks within the runtime's supervision | Research agent, comparison agent, execution agent |
| Service Providers | Fulfill capabilities, deliver outcomes | Retailers, airlines, banks, SaaS platforms |
The runtime sits at the center. It's the trust broker, the credential vault, the supervision guardrail on behalf of the user, and the capability router. It's the only entity that has relationships with all three parties.
This is why the runtime layer is the most critical piece of infrastructure in the agent internet. Not the LLMs (they're interchangeable). Not the agents (they're plentiful). Not the services (they already exist). The runtime, the layer that makes the three-party relationship actually work.
Implications
The three-party web changes how we think about:
- Terms of Service — Need to account for agent intermediaries
- Rate Limiting — Agent traffic patterns differ fundamentally from human patterns
- Fraud Detection — Bot detection must distinguish malicious bots from authorized agents
- Accessibility — Structured capability declarations are the ultimate accessibility layer
- Competition — Service providers compete on capability quality, not just UX design
- Privacy — The runtime sees everything the agent does; its data handling is critical
Each of these is explored in more depth in subsequent papers — see From SEO to AEO on discovery, Supervision as a Service on oversight, and The Agency Problem on failure modes. The point of this paper is the frame: the web went from two parties to three, and everything downstream of that topology change needs to be rethought.