Buyer Policy

This section is advisory.

The Bilateral Counterpart

Levels of Trust describes what a service publishes about the terms it offers. This page describes what an agent's principal declares about the terms it is willing to accept. Together they define the bilateral handshake: the service publishes terms; the buyer's policy decides whether those terms are acceptable.

A buyer policy is a declarative description of the constraints under which an agent may transact, accept terms, or sign. It exists outside the cryptographic structure of the standard — the standard does not require any particular policy or any particular policy language. But a deployment that uses Level 3 (signed acceptance) without a buyer policy has handed the service unilateral control over what the buyer commits to. A policy is what makes the bilateral framing operational on the buyer side.

---

Policy Primitives

A buyer policy typically declares some combination of the following:

• Required level — the minimum trust level (1, 2, 3, or 4) the buyer requires from a service before transacting. A buyer requiring a minimum of Level 2 will not transact with services that publish only Level 1 terms.
• Acceptable jurisdictions — the legal frameworks the buyer's principal is willing to transact under. Terms specifying a jurisdiction outside this set are rejected.
• Acceptable dispute resolution methods — the institutional arbitration bodies, mediation services, or recourse mechanisms the buyer will accept (for example, AAA Commercial Arbitration Rules, ICC, JAMS, named online dispute resolution providers). Terms specifying a method outside this set are rejected or escalated.
• Commitment caps — maximum monetary value, contract duration, recurring obligation, or other quantitative limit on what the agent may bind the principal to.
• Signing thresholds — the commitment level above which Level 3 signed acceptance requires human review before the agent's key produces a signature.
• Required dispute resolution — for high-value or high-trust contexts, a policy may require that any service the buyer transacts with publish a Level 4 disputeResolution clause from the buyer's accepted set.
• Identity requirements — the identity attestations the buyer requires of the counterparty (for example, verified business identity or regulatory registration).
• Format requirements — the formats the buyer's parser supports. A buyer with a JSON-only parser may decline to transact with services that publish only PDF terms.

The policy's purpose is to encode the principal's authorization scope. An agent operating under a policy commits the principal only to terms the policy permits.

---

Policy Evaluation

Policy is evaluated client-side, at proposal time (see Transaction-Time Verification), before the agent commits to a transaction:

1. The agent fetches the service's legal-context.json.
2. The agent fetches and verifies the terms document (Level 2+; the operational flow is detailed in Transaction-Time Verification).
3. The agent's policy engine evaluates the terms — and the surrounding legal-context.json metadata (jurisdiction, dispute resolution, format, identity attestations) — against the declared policy.
4. If the policy permits, the agent proceeds; if Level 3 acceptance is required and the commitment falls below the signing threshold, the agent signs.
5. If the policy rejects, the agent declines the transaction.
6. If the policy escalates (commitment above signing threshold, missing required field, novel jurisdiction or counterparty), the agent surfaces the proposed transaction to a human or supervisor agent for review.

Policy evaluation runs before any signing key is invoked. A correctly-implemented policy engine is a defense against prompt-injection attacks targeting the signing path (see Security Considerations): the engine evaluates structured fields (disputeResolution.jurisdiction, atrHash, monetary amounts) drawn from the verified legal-context.json and the proposal, not from the natural-language body of the terms document. Policy decisions are made on the structured, integrity-protected channel.

---

Human-in-the-Loop Escalation

A buyer policy SHOULD specify when a human is required in the authorization chain. The threshold is a deployment decision, but reasonable defaults include:

• Any commitment above a configured monetary cap.
• Any acceptance of terms in a previously unseen jurisdiction.
• Any acceptance of dispute resolution by a previously unseen body.
• Any first-time transaction with a counterparty.
• Any transaction marked anomalous by the agent on other grounds.

When the policy escalates, the agent's signing path halts until the human, or a supervisor agent with greater authority, approves. The standard does not specify the escalation channel — email, push notification, integrated UI, or supervisor mandate signing — only that the policy engine MUST be able to halt the transaction before signing.

---

Policy Discovery

A buyer policy is, in general, private to the buyer's principal. The standard does not require buyers to publish their policies, and most deployments will not.

In bilateral protocols where both sides expose capabilities or credentials — for example, agent-to-agent or agent-to-service handshakes that surface acceptance criteria before the transaction — the buyer MAY expose a subset of its policy, typically the minimum required level and the acceptable jurisdictions, so the counterparty can pre-filter incompatible offers. The mechanism for that exposure is protocol-specific and out of scope for this standard.