What KYAPay is
kyapay.org defines Know Your Agent (KYA) as a protocol that provides AI agent developers with a standardized way to identify themselves, the platform they are running on, and the users they represent, and says KYAPay extends it by declaring user intent and supporting tokenized payment credentials. Skyfire describes itself as giving AI agents verified identity and payment credentials that work across the open internet.
The token format is specified in the Internet-Draft draft-skyfire-oauth-kyapay-token, authored by contributors from Skyfire Systems and Self-Issued Consulting; as an individual draft it has no formal standing in the IETF standards process. The draft defines JWT-based KYA, PAY and combined KYA-PAY tokens, identified by typ values kya+jwt, pay+jwt and kya-pay+jwt. It says JWTs must be signed using allowed algorithms, currently ES256, and that a validator discovers the issuer's JWK Set at the issuer URL with the /.well-known/jwks.json suffix.
Claims are grouped into a human identity object (hid, with email required), an agent platform object (apd) and an agent identity object (aid). The verification-related sub-claims under hid are optional. PAY tokens add payment fields such as amount (amt) and currency (cur). The GitHub repository places the specification under the Community Specification License 1.0 and the code under the MIT License.
What AgenID is
AgenID is an open protocol, specified in the MIT-licensed AgenID specification, that gives an AI agent a permanent identifier, agenid:<ULID>. The operator generates an Ed25519 key pair locally or in the browser at /issue, writes a manifest covering identity, ownership, purpose and disclosure, and signs a proof binding that manifest by SHA-256 digest.
The registry at www.agenid.com serves the result at https://www.agenid.com/a/<agenid> as a Verification Card or a JSON resolution envelope that anyone can re-verify offline. The manifest names the operator, not the end user the agent serves, and AgenID moves no money.
Key differences
The signer differs. A KYAPay token is signed by its issuer, and a validator checks it against the issuer's published JWK Set, so the validator's confidence rests on that issuer's key and on what that issuer checked. An AgenID record is signed by the operator's own key; the registry stores it but cannot sign it, and a verifier compares the registry's copy of the operator key with the operator's own published copy (two-path key discovery).
The subject differs. A KYAPay token describes a human principal, an agent platform and an agent, and optionally a payment. An AgenID identifier is permanent and describes one agent and its accountable operator, independent of any single transaction or platform.
The cryptography differs: KYAPay specifies ES256 JWTs; AgenID uses pure Ed25519 over RFC 8785 canonical JSON. And the payment scope differs entirely: PAY tokens carry payment information, while AgenID has no payment object.
Identity is not permission
Which agent is acting is a separate question from what it is allowed to do or spend. KYAPay's PAY fields express payment terms such as amount and currency within its token format. AgenID v1.1.1 expresses no permissions at all: it identifies the agent and operator, and any decision about what that agent may do stays with the relying party.
Where they are complementary
The two answer adjacent questions at the moment an agent reaches a service. A KYAPay token tells the service about the principal, the platform and, optionally, a payment, as vouched for by the token's issuer. An AgenID identifier tells the service which persistent agent this is and which operator signed its declaration, checkable without trusting the registry. Neither specification defines a claim that references the other today, so combining them would be a relying party's own policy.
When to use which
These are fit questions, not quality judgments.
- Consider KYAPay when a service needs issuer-vouched information about the human principal and agent platform, or a payment token, in a JWT format.
- Consider AgenID when a counterparty needs a permanent, operator-signed identity for the agent itself that it can re-verify offline, with no account and no payment relationship.
- Consider both in agentic commerce flows where the merchant wants a persistent agent identity and an issuer-signed principal or payment token.
AgenID's current limits
AgenID's boundaries, stated as plainly as its design:
- Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
- No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
- No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and
permissionsandauthorizationsare reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available. - Two-path key discovery depends on the operator. The registry serves the operator key at
GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy athttps://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.