Portable Reputation

This page explains the cross-operator track record carried in an Agent Passport (see Passports for the credential schema). Native and imported reputation remain separate. The default attenuation factor for an imported reputation input is 0.50, and inputs older than 30 days expire. For the concept-level explanation of agent-held reputation, see Reputation & Passports.

This page is the behavioral half of an agent's portable record: reputation scorecards. The financial counterpart travels the same way. Portable, per-issuer financial credentials (credit standing, exposure, settlement reliability, premium and loss history) ride alongside the passport, cross organizations, and stay asserted at the receiving boundary no matter how many signatures verify. See Portable Financial Credentials for that family.

The Agent Owns the Keys

Reputation in Chio is not a transferable token. It is a score that an organization computes from signed receipts associated with a subject keypair. Three properties follow.

• Identity is the keypair. A did:chio:<public-key> identifier encodes the public key directly. Any verifier that learns the DID can verify signatures by that key without contacting an identity provider.
• Receipts name the subject. Every receipt records the subject public key. The set of receipts mentioning a given key is the agent's observable history.
• Reputation is a projection. A score is something each org computes from the receipts it has admitted, weighted by its own policy. There is no authoritative number stamped onto the agent.

Agent Passport contents

The agent presents an Agent Passport with the subject's receipt roots, the issuing operator's attestation of reputation signals, and optional enterprise identity provenance. See Passports for the full schema.

An Agent Passport projection contains:

An Agent Passport can carry credentials issued by multiple orgs. The bounded CrossIssuerPortfolio profile embeds an AgentPassport per entry, each tagged Native, Imported, or Migrated, so a verifier can verify each entry independently. It also includes a migrations ledger of signed CrossIssuerMigration records — from_issuer, to_issuer, from_subject, to_subject, and prior_passport_ids — that preserves subject-identity continuity when an agent moves across issuers. The profile preserves evidence; it does not create a new trust root.

Per-Org Scoring

Each org scores the agent against its own observed receipts. The receipts an org actually saw at runtime are stored locally; receipts from other orgs come in as imported evidence shares (see Bilateral Receipts). The scoring inputs are kept distinct.

• Native reputation: computed from receipts the local kernel signed. These are first-hand observations: dispatched calls, denials, budget draws, and settlement outcomes.
• Imported reputation: computed from receipts and reputation summaries received in signed evidence shares from a federation peer, weighted by the bilateral policy and remains separate from native reputation.

Comparison tools show both values with their provenance. An operator deciding whether to grant a capability can inspect the local and imported signals separately. The kernel does not use one combined value for runtime enforcement.

$ chio --json --receipt-db receipts.sqlite3 reputation compare \
    --subject-public-key 80f2b577472e6662f46ac2e029f4b2d1300f889bc767b3de1f7b63a4c562fd8f \
    --passport ./agent-passport.json

# --subject-public-key is a bare-hex Ed25519 key; no ed25519: prefix.
# Output (abbreviated). The local scorecard, imported trust, and shared
# evidence stay in separate blocks; nothing is blended into one number.
# {
#   "subjectKey": "80f2b577472e...",
#   "passportSubject": "did:chio:80f2b577...",
#   "subjectMatches": true,
#   "local": {
#     "effectiveScore": 0.81,
#     "scorecard": {
#       "boundary_pressure": { "deny_ratio": { "state": "known", "value": 0.01 }, "receipts_observed": 1240 },
#       "reliability": { "score": { "state": "known", "value": 0.98 }, "completion_rate": { "state": "known", "value": 0.98 } },
#       "history_depth": { "receipt_count": 1240, "span_days": 47 },
#       "composite_score": { "state": "known", "value": 0.81 }
#     }
#   },
#   "credentialDrifts": [
#     { "index": 0, "issuer": "did:chio:a1b2...",
#       "metrics": { "compositeScore": { "portable": 0.87, "local": 0.81, "localMinusPortable": -0.06 } } }
#   ],
#   "sharedEvidence": {
#     "summary": { "matchingShares": 1, "remoteToolReceipts": 5800, "distinctRemoteSubjects": 1 }
#   },
#   "importedTrust": {
#     "signalCount": 1,
#     "acceptedCount": 1,
#     "signals": [
#       { "provenance": { "shareId": "imp-2026-04-15-001", "partner": "org-a" },
#         "accepted": true, "attenuatedCompositeScore": 0.44 }
#     ]
#   }
# }

Imported Evidence Is Attenuated

Imported federation shares remain distinct from local observations. Each share includes provenance and is subject to the default controls.

• Provenance fields: share_id, issuer, partner, signer_public_key, imported_at, exported_at. Persisted in federated_evidence_shares.
• Policy echo: the bilateral FederationImportControl in effect at import time is recorded alongside the share so an auditor can see which guardrails were applied.
• Conservative defaults: proofless shares are rejected; shares whose age past exported_at exceeds max_signal_age_days (default 30 days) expire; accepted shares contribute an attenuatedCompositeScore instead of a native confidence number.
• No ambient runtime admission: imported evidence informs visibility and reputation views; it does not widen runtime authority. The default FederationImportControl sets prohibit_ambient_runtime_admission = true.

Receipt Merkle Proofs

A passport bundles receipt-log Merkle roots, not the receipts themselves. The verifier checks an inclusion proof against a trusted root without replaying the receipt log. This has two consequences.

• Bounded import cost: a passport is small even when the agent has thousands of receipts on file. The verifier pulls only the proofs it needs.
• Tamper evidence: an inclusion proof against a signed root is binary. Either the receipt was logged at the issuer at the time the root was published, or it was not.

The receipt log is exposed via the optional ChioReceiptLogService entry in a DID document. Org B's verifier discovers the URL, pulls inclusion proofs, and validates them against the roots embedded in the passport before any reputation projection runs.

$ chio did resolve \
    --did did:chio:80f2b577472e6662f46ac2e029f4b2d1300f889bc767b3de1f7b63a4c562fd8f \
    --receipt-log-url https://trust.org-a.example/v1/receipts

# The resolved DID document includes ChioReceiptLogService entries.
# Org B uses these to fetch inclusion proofs against passport roots.

Failure Modes

Worked Example: Buyer Org Evaluates a Provider Agent

Org B (buyer) is considering granting a capability to a provider agent that previously operated under Org A. The agent presents a passport. Org B already has a bilateral policy with Org A and has pinned Org A's kernel as a federation peer.

1. Verify the Passport

Org B's verifier checks the passport signature against the issuer's public key, confirms chio_subject_did matches the keypair the agent presented at the door, and consults the lifecycle sidecar. Anything other than active fails closed.

2. Pull and Verify Receipt Roots

The passport includes Merkle roots for the agent's receipt log at Org A. Org B fetches inclusion proofs from Org A's ChioReceiptLogService endpoint, declared in Org A's DID document. Each proof is verified against the root in the passport.

3. Check Issuers Against trusted_issuers

Receipts signed by an Org A kernel key absent from Org B's bilateral trusted_issuers set are dropped. The remaining receipts form the imported corpus.

4. Compute Reputation

Org B computes its imported-reputation projection over the accepted corpus, applying the attenuation factor declared in the bilateral policy. Org B also computes its native projection over receipts it signed locally for this subject (initially empty for a brand new agent).

5. Operator Decides

The comparison view presents both projections with provenance. The operator decides whether to issue the capability and, if so, with what scope, budget, and autonomy tier. Native receipts begin to accumulate from the first invocation.

Related

• Passports covers the credential bundle that carries history.
• Reputation details native scoring and projection algorithms.
• Scorecards explains the comparison view that places native and imported signals side by side.
• Bilateral Federation covers the per-pair trust contract that controls import.
• Bilateral Receipts covers the dual-signed evidence that lands in shares.