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.

This draft (v0.2, August 2026) supersedes v0.1 (May 2026). A summary of substantive changes appears in §16.

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.

Since v0.1, the demand side has moved from forecast to measurement. In Q2 2026 Cloudflare reported that non-human traffic crossed 50% of its network for the first time — a year ahead of its own forecast — with AI-agent requests up more than 1,700% year over year, and its CFO projecting non-human traffic at up to 1,000× human traffic within five years. In July 2026 Cloudflare began charging agents per request over x402 (Monetization Gateway, then Wallets). Once infrastructure operators bill agents per request, counterparties need a machine-readable answer to “should I transact with this agent” at the same per-request cadence. That is the gap this specification addresses.

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>|

5.1 Position in the identity stack

KYA Records are reputation, not identity. Edge-level agent verification (e.g. Web Bot Auth request signing, and Cloudflare-class verified-agent programs) answers what is connecting; credential schemes such as ACK-ID and W3C Verifiable Credentials answer who stands behind it. A KYA Record answers the remaining question: how has it behaved with value at stake. The three layers are complementary, and a Bureau Operator should bind KYA Records to whatever identity primitive the agent presents (§6.1mpp_did), so that edge identity, credentials and reputation compose rather than compete.

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.

9.4 Operator onboarding

An entity becomes a Bureau Operator by: (1) publishing an Ed25519 JWKS at a stable well-known URL; (2) implementing the read API (§7.1) and CRL endpoint (§7.3); (3) publishing its tiering bands (§6.2) and scoring-component coverage (§6.3); (4) passing conformance verification — its receipts must verify offline against its JWKS using the reference verifier; and (5) being listed in the operator directory (§14). Operators may additionally bond a stake against the honesty of their own attestations (§11); federated consumers may weight records by issuer bond.

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.

As of this draft the stake block is normative. When a stake exists, the KYA Record must include:

"stake": {
  "staked_amount":      "25000.00",
  "denomination":       "USDC",
  "staked_by":          "principal | operator",
  "slashing_policy":    "https://<operator>/bureau-slashing-policy",
  "slash_count":        0,
  "last_slash_at":      null
}

Slashing triggers are operator-defined but must be published at the slashing_policy URL and should include at minimum: confirmed fraud, sanctions-list matches, and critical policy-gate violations. Slashed amounts should compensate the harmed counterparty first, with any remainder burned or escrowed — never retained by the slashing Operator, which would create a perverse incentive. Each slash event must be recorded and auditable. The reference implementation carries the corresponding primitives (agent_stakes,slash_events) in its schema today.

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 live revocation pipeline (agent_revocations) publishing to the CRL endpoint
• A production control plane at skalor.xyz whose decision receipts verify publicly at /api/v1/verify with no credential
• Approval to operate a Canton Network validator node, extending settlement-layer participation beyond read-only integration
• 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.

Design intent: a network no one owns. The Bureau is architected to be mutualized. When multiple independent Operators are live, Skalor Labs intends to move stewardship of this specification and of the operator directory into a neutral, member-governed structure, with Skalor as a founding member rather than owner. Federation requires that no single participant — including the specification’s author — hold a structural veto over who may issue.

14Future Extensions

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

1. Edge-identity interop profile — a normative binding between KYA Records and signed-agent request identity (Web Bot Auth-class schemes), so edge verification and reputation compose per §5.1.
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.
10. [CF-Q2] Cloudflare, Inc. Q2 2026 earnings call — non-human traffic >50% of network; agent requests +1,700% YoY; 1,000:1 five-year projection. August 2026.
11. [CF-MG] Cloudflare. “Announcing the Monetization Gateway.” July 2026.
12. [CF-W] Cloudflare. “Announcing Cloudflare Wallets.” August 2026.
13. [WBA] IETF draft — Web Bot Auth: HTTP message signatures for automated agents.
14. [X402] x402 Foundation (Linux Foundation), operational July 2026.

16Changelog

v0.2 — August 2026.

• §3: demand-side evidence updated from forecast to measurement (Cloudflare Q2 2026).
• §5.1 (new): position of KYA Records in the identity stack relative to edge verification and credentials.
• §9.4 (new): operator onboarding steps, including optional issuer bonds.
• §11: stake block promoted to normative; slashing-policy publication and recovery waterfall specified.
• §12: reference implementation updated — live revocation pipeline, public receipt verification, Canton validator approval.
• §13: mutualization design intent stated.
• §14: stake schema removed (delivered); edge-identity interop profile added.

v0.1 — May 2026. Initial public draft.

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.