Developer Preview · In Development

KYA: Know Your Agent

KYA is a credential reference framework that Autheo is developing on top of TheoID. It is designed to give a counterparty a quick, verifiable answer to the questions every agent transaction depends on: what is this agent, who controls it, what authority has been delegated, what policy applies, and what mandate is being invoked.

Status: KYA is an Autheo proposed reference framework. It is not, at this stage, a formal global standard. The implementation work referenced here is in development.

Why KYA

Autonomous agents now buy, sell, subscribe, pay for API access, negotiate, and execute mandates on behalf of users and enterprises. Existing identity primitives such as KYC and KYB describe humans and legal entities. They do not, on their own, describe agents.

KYA fills that gap. It is designed to interoperate with AP2 style payment mandates, OAuth style delegation, W3C Verifiable Credentials, W3C DIDs, and a future post quantum signing path.

What KYA aims to provide

  • A clear definition of agent, controller, and merchant identity.
  • A model for delegated authority, scope, and policy.
  • A model for mandates and their lifecycle.
  • A model for expiry and revocation.
  • A proof method aligned with established cryptographic standards.
  • A migration path toward post quantum signing for long lived credentials.
  • Interoperability with AP2 style payment mandates and existing agent communication protocols.

KYA does not aim to replace KYC or KYB, to define a new commerce execution protocol, or to compete with card network identity rails. KYA is not a governance instrument and not a token based voting mechanism. THEO remains a utility token.

Core entities

Agent

An autonomous software entity that takes actions on behalf of a controller. The agent has a stable identifier, a public key, declared capabilities, a controller reference, optional credentials about the runtime or vendor, and a status (active, suspended, revoked, expired).

Controller

The user, enterprise, organization, or other legal or natural entity that owns and authorizes the agent. The controller is the source of authority. The controller credential anchors the agent in a verifiable identity, which may be linked to KYC or KYB out of band.

Merchant

A counterparty that sells goods, services, or API access. A merchant credential exists at the agent layer so that other agents can verify merchant identity, policies, accepted payment routes, jurisdiction, and trust metadata without relying on a single platform.

Mandate

A specific, scoped authorization that allows an agent to perform a class of actions, often involving payment. A mandate references a controller, an agent, an optional merchant target, an authority scope, spend limits, time bounds, and conditions. AP2 style mandates fit into this concept.

Verifier

The party that needs to validate one or more KYA credentials. A verifier may be a merchant accepting an agent payment, a settlement rail confirming a mandate, or another agent negotiating an interaction.

Credential types

KYA defines four credential types, each issued, signed, and revocable following W3C Verifiable Credential conventions:

  • Agent Credential— establishes the agent identifier, public key, controller reference, capabilities, runtime metadata, and status.
  • Controller Credential — binds the controller identity (user or organization) to its verification method and out of band KYC or KYB reference.
  • Merchant Credential— asserts merchant identity, jurisdiction, accepted protocols, and trust metadata.
  • Mandate Credential— authorizes a class of actions, with scope, spend limits, time bounds, allowlists or blocklists, and conditions.

TheoID and post quantum cryptography

KYA is anchored on TheoID, Autheo's identity layer. TheoID is designed to use NIST selected post quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) for key material and signatures, with hybrid signature options planned during the transition. This matters because agent credentials, long lived mandates, and merchant credentials may persist for months or years.

Example use

A simplified mandate verification flow:

  1. An agent receives an intent from its controller (for example, “buy this product from this merchant, subject to a spend cap”).
  2. The agent presents its Agent Credential, the Controller Credential that authorizes it, and the Mandate Credential that scopes the purchase.
  3. The merchant or its agent layer verifies signatures, expiry, and revocation status against the issuer's status list.
  4. The merchant checks that the mandate scope covers the requested purchase and that the merchant is permitted under the mandate's allowlist.
  5. On success, the route handler proceeds to checkout and settlement. On failure, the verification returns a structured reason.