Autonomous Commerce

The Economy pages document the related mechanisms: capability scope, guard decisions, receipt signatures, and budget holds. This page links those mechanisms to the detailed concept pages.

A call is not a transaction

A tool-calling protocol describes how to invoke a function: the wire request and reply shapes. It does not by itself establish identity, authorization, price, or a durable record of what was permitted and charged.

A governed transaction records four facts that survive the call: who acted, whether the actor was authorized, cost, and outcome. Other systems often record these facts separately. Chio records them at the mediation point as a signed receipt.

These records provide non-repudiation. Each mediated action produces a signed, capability-bound receipt. The receipt cryptographically attests that a capability was used to invoke a tool with particular parameters and records the kernel decision. It references the capability ID, allowing the authorization chain to be reconstructed from the token. The framing is in the Trust Model; non-repudiation lets economic systems use a receipt for billing and reconciliation.

The commerce loop

Workload identity authorizes a mandate; the mandate governs execution; execution emits a receipt; the receipt supports settlement and reputation. Each stage consumes the signed output of the prior stage.

Workload identity, mandates, and execution are authorization functions. Settlement, reputation, and underwriting can use the resulting signed receipts for separate purposes. The design does not require a second identity system.

Four statements of identity

The following four claims describe how shipped authorization features can support economic workflows.

Capability tokens are programmable spending authorizations

A capability token says: this subject may invoke these tools, with these parameters, subject to these constraints, until this time, within this budget. It can serve as a spending authorization because it is scoped, time-bounded, delegatable, and revocable. Each ToolGrant can carry max_invocations, max_cost_per_invocation, and max_total_cost in minor-unit integers. The distinction between “you may call settle_invoice up to 50 times” and “you are authorized to spend up to $100” is represented by fields in the grant.

# A delegated capability is a spending authorization that only narrows.
# A supervisor holds a broader grant and delegates a strict subset to a
# sub-agent: settle_invoice on srv-payments, 50 calls, <= $5.00 each,
# <= $100.00 in aggregate, expiring in one hour.
capability:
  schema: chio.capability.v1
  id: 0190a3c2-7f1e-7c44-9b2a-3d5e6f7a8b9c
  issuer: 3b9af0c1e2d4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2b4c6d8e0f2a4b6  # supervisor (delegator)
  subject: 7e1420d8f6a4c2b0e8d6c4a2f0e8d6c4b2a0f8e6d4c2b0a8f6e4d2c0b8a6f4e2  # sub-agent, token-bound
  issued_at: 1752710400
  expires_at: 1752714000
  scope:
    grants:
      - server_id: srv-payments
        tool_name: settle_invoice
        operations: [invoke]
        max_invocations: 50
        max_cost_per_invocation: { units: 500, currency: USD }
        max_total_cost: { units: 10000, currency: USD }
  delegation_chain:
    - capability_id: 018f2b6e-91a3-7d10-88c4-1f2e3d4c5b6a  # supervisor's parent token
      delegator: 3b9af0c1e2d4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2b4c6d8e0f2a4b6
      delegatee: 7e1420d8f6a4c2b0e8d6c4a2f0e8d6c4b2a0f8e6d4c2b0a8f6e4d2c0b8a6f4e2
      attenuations:
        - type: reduce_total_cost
          server_id: srv-payments
          tool_name: settle_invoice
          max_total_cost: { units: 10000, currency: USD }
      timestamp: 1752710400
      signature: a17c9e...   # signed by the delegator over the link
  signature: e5f6a7...       # signed by the issuer over all fields

Delegation is monotonic. The reduce_total_cost attenuation lets the kernel check that the child budget is a subset of the parent. The kernel rejects a hop that widens it. An agent with a $100 ceiling cannot delegate a $200 ceiling, just as an agent granted read_file cannot delegate write access. Budgets travel with the token and narrow through delegation. The grant structure and the subset check are in Capabilities; how the kernel meters and settles against them is in Economics.

Delegation chains are cost-responsibility chains

When one agent delegates to another, the delegation link records who authorized whom, with what attenuations, at what time, signed by the delegator. These fields provide the data needed for cost attribution. When the sub-agent spends under a delegated capability, the receipt carries a delegation_depth and a root_budget_holder: the authority traces back through the chain to the party ultimately on the hook. Chargebacks, cost allocation, and budget reconciliation can use this delegation graph; a separate billing graph is unnecessary.

Where a delegation should not run unsupervised, a grant can require a human signature above a threshold. A RequireApprovalAbove constraint pauses the call and produces a PendingApproval outcome until an authorized approver counter-signs. The signed record includes the cost responsibility and approval. The mechanics are in Human in the Loop.

The receipt log is a billing ledger

Each mediated decision records the capability that authorized the action, the tool that ran, the parameters, the verdict, the timestamp, and the kernel signature. The economic metadata rides alongside it. When a call is priced, its cost is written into the receipt beside the authority and outcome. The log is append-only and content-addressed: the receipt ID is the hash of its canonical body. A mediated receipt can therefore serve as a billing event without transformation.

{
  "id": "7d41c0a83b6e2f19d5c4b8a70e6f9d2c1b0a3e4f5d6c7b8a9e0f1d2c3b4a5e6f",
  "timestamp": 1752710462,
  "capability_id": "0190a3c2-7f1e-7c44-9b2a-3d5e6f7a8b9c",
  "tool_server": "srv-payments",
  "tool_name": "settle_invoice",
  "decision": { "verdict": "allow" },
  "receipt_kind": "mediated_decision",
  "metadata": {
    "financial": {
      "grant_index": 0,
      "cost_charged": 480,
      "currency": "USD",
      "budget_remaining": 9520,
      "budget_total": 10000,
      "delegation_depth": 1,
      "root_budget_holder": "3b9af0c1e2d4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2b4c6d8e0f2a4b6",
      "settlement_status": "pending"
    }
  },
  "kernel_key": "9c7b3f1a2e8d4c6b5a09f8e7d6c5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2",
  "signature": "e5f6a7b8c9d0e1f2..."
}

The guard pipeline is a compliance engine

Spending caps, parameter constraints, egress restrictions, path allowlists, secret detection: these are security controls, and they are also compliance controls. SOC 2, HIPAA, PCI-DSS, and SOX all demand demonstrable access controls backed by audit evidence. The seven-guard default pipeline produces a signed record of the controls evaluated, verdicts reached, and evidence used. The pipeline is fail-closed: if a guard denies, the call denies and the denial is signed. The per-guard reference is in Guards, and the boundary that keeps the guard evidence trustworthy is in the Trust Model.

Provenance extends the same discipline to the model behind the agent. A signed model card binds a set of weights to the capabilities it may exercise and the tools they may not, and the kernel can refuse a call whose model card does not match. Compliance can then cover the agent's actions and the model authorized to perform them. See Model Cards.

Receipts, Reputation, and Underwriting

The four mechanisms make transaction records verifiable. Receipts record successful and denied calls, scope compliance, and budget overruns. Reputation can be computed from this record.

Behavioral metrics can include completion rate, guard decisions, out-of-scope or over-budget denials, and delegation-chain structure. A relying party may use these metrics to adjust expirations, delegation, and cost ceilings. The resulting Agent Passport is a portable signed credential that a relying party can verify without a shared server.

This is where the local concepts hand off to the economic network. Behavioral baselines feed the scores in reputation and travel across organizations as passports. Those scores become actuarial input in underwriting and the liability market, which price credit and cover against an agent’s signed history. The advisory signals that seed the whole chain are documented in Session-Aware Guards.

Where to go next

Read the concept pages for the mechanism behind each claim on this page.

• Architecture: the kernel, the five components, and the life of a call.
• Workload Identity: who is calling, and the attestation tier behind the key.
• Capabilities: token structure, delegation, attenuation, and budgets.
• Guards: the seven-guard default pipeline and how to compose more.
• Receipts: the signed record, its financial metadata, and offline verification.
• Economics: metering, the authorize / capture / release / reconcile budget lifecycle.
• Human in the Loop: approval thresholds and governed transaction intents.
• Model Cards: binding model weights to the capabilities they may exercise.

For the economic network the flywheel opens, start with the Agentic Economy overview: markets, credit facilities, underwriting, settlement rails, and on-chain anchoring, all clearing against the receipts the kernel signs.