KYA Bureau

An open, federated, signed reputation primitive for AI agents transacting on bank-custodied capital. Skalor operates the reference implementation under this spec; anyone may implement an interoperable Bureau against this RFC.

1Abstract

This document specifies KYA Bureau — an open, federated reputation primitive for AI agents (“Know Your Agent”). The Bureau publishes per-agent reputation records consisting of a tier, a composite score, and a set of weighted quality signals derived from observable agent behaviour. Each record is signed Ed25519 by the issuing Bureau operator and is verifiable offline by any counterparty against a published JWKS.

The Bureau is designed to be the institutional analogue, for autonomous AI agents, of what Plaid is for consumer financial data, what FICO is for human credit, and what Chainlink is for off-chain oracles: a neutral, federation-capable layer whose value compounds with each new participant.

This RFC defines the wire format, the signing scheme, the score schema, the federation protocol between independent Bureau operators, and a reference revocation mechanism (CRL). It does not mandate a specific scoring algorithm.

2Status of this Memo

This is a draft specification published for public comment. It is not a final standard. Implementations following this draft should be prepared to update once v1.0 is published.

Comments and proposed revisions are welcomed by email to founders@skalor.xyz or as a pull request against the canonical source at github.com/SkalorAI/skalor-protocol. Substantive changes between draft revisions will be tracked in the document history.

3Motivation

AI agents are increasingly authorized to transact on real capital. In April 2026, Sean Neville (Catena Labs / Circle co-founder) named the missing primitives for autonomous agent commerce in his Possible podcast appearance: identity, policy enforcement, and a liability framework. In the same month, Christian Catalini and co-authors at a16z crypto published “Agents are starting to operate real systems,” using the term Know Your Agent (KYA) verbatim. In May 2026, Anchorage Digital Ventures’ Request for Startups listed “Agentic Wallets & KYA” as its first AI-agent infrastructure bullet.

The market consensus is that institutions deploying AI agents on bank-custodied capital cannot do so without:

1. An agent identity primitive (addressed by [ACK-ID] and W3C [VC-DM])
2. Programmable policy enforcement at the contract level (addressed by Skalor’s Mandate.sol)
3. A reputation signal counterparties can rely on when deciding whether to transact with an unknown agent

The third primitive does not exist. This RFC proposes one. The requirement that it be open and federation-capable is deliberate: a single closed Bureau is a single point of failure and a chokepoint for institutional adoption. A spec that allows multiple interoperable Bureaus — analogous to Equifax / Experian / TransUnion in the human-credit world — is what institutions actually need.

4Conformance & Terminology

The key words must, must not, should, should not, and may in this document are to be interpreted as described in [RFC 2119] and [RFC 8174].

Agent

An autonomous software entity that proposes or executes financial transactions on behalf of a principal.

Principal

The legal or natural person on whose behalf an Agent acts. The Principal sets the Agent’s spending mandate.

Bureau Operator

An entity that issues KYA Records under this specification. Multiple Bureau Operators may exist; they federate per §9.

KYA Record

A signed reputation record about an Agent. See §6.

KYA Receipt

The wire-format encoding of a KYA Record: skalor_bureau_v1.<b64url-payload>.<b64url-sig>.

Tier

A coarse summary of the Bureau Score: one of AAA, AA, A, BBB, BB, B, CCC, or UNRATED.

Verifier

A counterparty that fetches a KYA Receipt and verifies it offline against the issuing Bureau’s published JWKS.

5Architecture

A KYA Bureau exposes three surfaces:

1. Read API — issues signed KYA Receipts for agents on demand (§7).
2. JWKS endpoint — publishes the operator’s Ed25519 verifying keys at a stable well-known URL.
3. CRL endpoint — publishes a signed Certificate Revocation List of agents the operator has revoked.

Bureau Operators shouldadditionally expose a public registry browse view so verifiers can discover agents that have opted into public visibility.

The integration flow between an Agent, its Principal, a counterparty (the Verifier), and the Bureau is:

Principal           Bureau              Counterparty           Agent
   |                  |                     |                  |
   |--register agent->|                     |                  |
   |                  |                     |                  |
   |                  |                     |   propose tx --> |
   |                  |   read KYA receipt -|                  |
   |                  |<-- signed receipt --|                  |
   |                  |                     |   policy check   |
   |                  |                     |   verify offline |
   |                  |                     |   against JWKS   |
   |                  |                     |                  |
   |                  |                     |--accept / reject>|

6Data Model

6.1 KYA Record payload

A KYA Record is a JSON object. Conforming implementations must populate at least the fields shown below; they may add additional implementation-specific fields under namespaces prefixed withx_ (these are not signed by other Bureaus during federation pulls).

{
  "v": 1,
  "iss": "skalor.xyz",
  "kid": "skalor-attest-2026-04",
  "agent_id": "2392ad6b-3df2-4ee1-a03a-d92ff2f0d3ec",
  "mpp_did": "did:key:z6Mk...",
  "issued_at":  "2026-05-12T12:00:00Z",
  "expires_at": "2026-05-13T12:00:00Z",
  "score": {
    "bureau_score":     652,
    "bureau_tier":      "BBB",
    "weighted_quality": 0.640
  },
  "components": {
    "approval_quality":          0.83,
    "gate6_history_quality":     0.50,
    "gate0_attestation_quality": 0.0,
    "settlement_quality":        1.00,
    "gate6_enforcement_quality": 0.40,
    "tenure_quality":            1.00
  },
  "raw": {
    "total_cleared":            336,
    "total_denied":             179,
    "settlement_failure_count": 0,
    "days_since_first_tx":      127,
    "has_gate0_attestation":    false,
    "gate6_enforcement_mode":   "shadow"
  }
}

6.2 Tier semantics

Tier must be one of AAA, AA, A, BBB, BB, B, CCC, or UNRATED. The semantic mapping from bureau_score to tier is implementation-defined, but Bureau Operators must publish their tiering bands and must return UNRATED for any agent whose data is insufficient for a confident score.

6.3 Score components

The components object decomposes the composite bureau_score into named, normalized (0–1) signals. The reference implementation uses the following six; conformant implementations must emit at least approval_quality and tenure_quality and should emit the remainder where data is available.

7API Surface

7.1 Read API

GET /bureau?agent_id=<uuid> or /bureau?did=<did:key:...>

Returns a KYA Record envelope. Status codes:

• 200 — record returned, including signed receipt
• 404 — agent not found, or has not opted into public visibility
• 410 — agent revoked (CRL entry exists; see §9)
• 4xx / 5xx — error JSON of form {"error": "..."}

Response body must include a receipt field carrying the canonical wire-format encoding of the signed payload (§8). All other fields are unsigned conveniences for clients that do not (yet) verify offline; verifiers must base their trust on the receipt field only.

7.2 JWKS endpoint

Bureau Operators must publish their verifying keys at a stable URL (the reference implementation uses /.well-known/skalor-key.json; per [RFC 8615], deployments should use a /.well-known/ path).

7.3 CRL endpoint

GET /bureau-crl returns a signed Certificate Revocation List of agents the Bureau Operator has revoked. Verifiers should consult the CRL before relying on a KYA Receipt.

8Cryptography

KYA Receipts are signed with Ed25519 ([RFC 8032]) over the canonical-JSON encoding of the KYA Record payload. Implementations must use canonical JSON with sorted object keys and UTF-8 encoding.

Wire format:

skalor_bureau_v1.<base64url(canonical_json_payload)>.<base64url(ed25519_sig)>

The skalor_bureau_v1. prefix is the type tag. Verifier libraries route on this prefix to apply the bureau-receipt schema, distinct from transaction-attestation receipts which use skalor_v1. / skalor_v2.. All three types share the same JWKS.

Signing keys should be rotated on a defined cadence. To enable rolling rotation, JWKS responses may contain multiple keys; the kid field embedded in each receipt indicates which key was used. The reference implementation publishes both the outgoing and incoming key during a 30-day overlap window.

9Federation Protocol

A Bureau Operator may import KYA Records from other Bureau Operators to extend its coverage. This is the federation protocol.

9.1 Pull

A Bureau Operator A queries Bureau Operator B’s read API (§7.1) for a given agent_id or did. Operator A must verify the returned receipt against Operator B’s published JWKS before incorporating it.

9.2 Trust

A Verifier consuming a federated KYA Record must be able to determine which Operator originally signed each component. The composing Operator must not re-sign another Operator’s payload as if it were its own. Where multiple Operators have rated the same Agent, Verifiers may aggregate using implementation-defined weights, or display the highest-confidence individual record.

9.3 Revocation

A Bureau Operator may revoke a previously-issued KYA Record (e.g. on operator request, on evidence of fraud, on OFAC SDN list match). Revocations are published via the CRL endpoint (§7.3). Verifiers should consult the originating Operator’s CRL before relying on a federated record.

10Security Considerations

10.1 Replay

KYA Receipts include issued_at and expires_at timestamps. Verifiers should reject expired receipts and may reject receipts whose issued_at is implausibly far in the past.

10.2 Score gaming

Because the components are derived from observable agent behaviour, an operator may attempt to inflate them by churning trivial transactions. Bureau Operators should apply minimum-volume thresholds and de-weight self-dealing transaction patterns when computing the composite score.

10.3 Privacy

KYA Records refer only to AI agents and the principals who register them. They must not include personally-identifying information about end users. Operators must respect a principal’s opt-out of public visibility; the reference implementation does this via a bureau_public flag enforced server-side.

10.4 Sybil resistance

A bad actor may register many fresh agents to acquire fresh ratings. Bureau Operators should return UNRATED until an agent has accumulated sufficient verifiable transaction history, and may require stake (§11) for non-UNRATED tier assignment.

10.5 Compliance posture

Bureau Operators offering cross-org reads should structure their service following Fair Credit Reporting Act (FCRA) patterns where applicable: permissible-purpose checks, adverse-action notices, dispute flow. The reference implementation treats KYA scores as B2B reference data, not consumer credit data — Bureau scores must not be used to make decisions about natural persons.

11Stake-Backed Reputation

Bureau Operators may support an optional stake-backed reputation tier. Under this model, a principal posts a stake (in USDC, PathUSD, an institutional stablecoin, or a programmable credit instrument) against an agent’s good behaviour. The stake is slashed on defined triggers — e.g. Gate 6 critical-tier hits, OFAC SDN list matches, operator-confirmed fraud — and the slashed amount should compensate the counterparty harmed by the slashing event.

Stake amounts and slashing parameters are implementation-defined but must be reflected in the KYA Record (under an additional stake object in forthcoming v0.2 of this RFC) so that Verifiers can price the additional assurance into their counterparty decisions.

12Reference Implementation

Skalor operates the reference Bureau. The reference implementation comprises:

• Edge Functions for the read API, registry browse, federation pulls, CRL, and operator-labeling endpoints
• A Postgres view (agent_kya_bureau_scores) computing component qualities from observable transaction activity
• Ed25519 signing under a key documented in this Bureau’s JWKS at /.well-known/skalor-key.json
• An offline verifier in TypeScript and Python (@skalor/sdk on npm; skalor-sdk on PyPI)
• A public registry browse view at skalor.xyz/registry
• An interactive verifier at skalor.xyz/verify and a shareable receipt landing at skalor.xyz/receipt

Source under MIT at github.com/SkalorAI/skalor-protocol.

13Governance

This document is editorial-controlled by Skalor Labs through v1.0. After v1.0 publishes, Skalor Labs intends to assign editorial control to a multi-stakeholder working group with published acceptance criteria; participation will be open to any implementer of a conforming Bureau and any institutional consumer of KYA Records.

Substantive changes to this RFC will be published as numbered drafts (v0.1, v0.2, ...) until v1.0. Compatibility-breaking changes after v1.0 must be published as a new RFC (e.g. kya-bureau-v2) rather than as a revision to this one.

14Future Extensions

The following are anticipated for subsequent drafts of this RFC, in approximately the order they are expected to mature:

1. Stake schema — a normative stake block in the KYA Record payload covering staked amount, denomination, slashing triggers, and counterparty-recovery waterfall.
2. Soulbound anchor — an optional ERC-5192 soulbound NFT minted per agent that anchors the agent’s KYA tier on-chain for smart-contract counterparties (e.g. an ETF stablecoin’s mint/redeem function reading the tier before authorizing).
3. Cross-Bureau aggregation — a normative algorithm for combining records from multiple federated Operators with operator-disclosed confidence weights.
4. Adverse-action notice format — a structured notification payload for principals whose agents have been denied by a counterparty on the basis of a KYA Record.
5. Bureau-of-Bureaus directory — a discovery mechanism for Verifiers to enumerate known conforming Bureau Operators.

15References

1. [RFC 2119]Bradner, S. “Key words for use in RFCs to Indicate Requirement Levels.” BCP 14, RFC 2119, March 1997.
2. [RFC 8032]Josefsson, S. and I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017.
3. [RFC 8174]Leiba, B. “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” BCP 14, RFC 8174, May 2017.
4. [RFC 8615]Nottingham, M. “Well-Known Uniform Resource Identifiers (URIs),” RFC 8615, May 2019.
5. [VC-DM]W3C Verifiable Credentials Data Model 2.0. W3C Recommendation.
6. [ACK-ID]Catena Labs, Agent Commerce Kit — Identity Layer.
7. [a16z 2026]Catalini, C. et al., “Agents are starting to operate real systems,” a16z crypto, April 2026.
8. [Possible 2026]Neville, S. interview on the Possible podcast, April 2026.
9. [ADV-RFS]Anchorage Digital Ventures, Request for Startups, May 2026.

Source for this RFC is maintained at github.com/SkalorAI/skalor-protocol under docs/spec/kya-bureau-v0.1.md. Comments to founders@skalor.xyz.