Executive Summary

The emergence of agentic AI introduces a new class of autonomous systems capable of initiating, negotiating, and executing actions on behalf of individuals and organizations. As these systems begin interacting with APIs, services, and each other, the need for a shared protocol layer, one that defines identity, trust, and payments, becomes critical.

At the core of this challenge is the deep interdependence between payments and identity. Every transaction depends on knowing who is acting, on whose behalf, and whether they have the financial authorization or means to complete it. Identity enables basic account creation, compliance, such as Know Your Customer (KYC) and Anti-Money Laundering (AML), and makes it possible to enforce payment terms. Payments, in turn, provide utility and monetization. Without identity, payments lack security and accountability; without payments, identity lacks transactional value or operational relevance. In an autonomous digital economy, tightly coupling the two unlocks secure, agent-native access to services.

This whitepaper introduces KYAPay, an identity-linked payment protocol for agent-to-agent and agent-to-service interactions, which Skyfire implements in our production-ready Agent Checkout platform which Skyfire implements in our production-ready Agent Checkout platform today. We prioritize simplicity and compatibility with existing infrastructure, e.g., Web APIs, OAuth2 authorization flows, as well as with emerging agentic AI protocols, such as Model Context Protocol (MCP), Agent Connect Protocol (ACP), or Agent2Agent Protocol (A2A). We also highlight upgrade paths and integration points with other complementary specifications, including Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and others. Our goal is to provide a practical foundation for secure, interoperable transactions between AI agents and services in a rapidly evolving digital ecosystem.

In the paper, we present:

• The human-mediated agentic AI workflow and our proposal for a better approach.

• A protocol- and platform-agnostic token data model that embeds identity context and payment intent.

• Skyfire's lightweight API, as an integration example, for creating and verifying this token.

• A vision roadmap from infrastructure compatibility to full protocol interoperability.

We invite peers to review our approach, provide feedback, and collaborate on building a more interoperable identity and payment layer for agent AI. 

The Lay of the Land

As agentic AI applications and services evolve, they are increasingly expected to interact autonomously with other apps, services, and agents on behalf of users. These interactions take place across independently operated systems and require trust and coordination among an expanding network of actors.

For example, an agent using MCP may request access to third-party tools, APIs, and computing resources to perform actions, such as acquiring financial data, retrieving paid content, completing an ecommerce checkout, or creating a relational database on a managed service. Similarly, an agent may need to communicate, cooperate, or negotiate with other agents, for which it can use protocols like the A2A or ACP.

In most cases, when an agent interacts with external systems, whether they are third-party APIs, resources, or a directory of compatible agents, an existing account with credentials is required for access. In many cases, a payment or financial relationship is involved. Within such commercial ecosystems, agents can be viewed as participants in a buyer-seller dynamic: 

• Buyer: An agent, typically a user-controlled app or service, that initiates requests to third-party tools, resources, or cooperating agents on behalf of the user.

• Seller: An agent or service that exposes capabilities, resources or tools to be consumed by buyer agents, often acting on behalf of a commercial provider. Seller interfaces may be implemented via REST APIs, JSON-RPC calls, A2A Agent Cards, Agent ACP descriptors or traditional websites.

In this economic model, when a buyer agent makes a request to a seller, the seller likely needs to know several key pieces of information:

• User Identity: The identity of the end-user or organization behind the agent for internal use as well as externally for billing, compliance, and fraud prevention.

• Agent Identity: The unique identity of the agent acting on behalf of the user, along with its credentials or delegated permissions. 

• Payment information: Confirmation that the user has a valid and active payment method and has sufficient funds or credit available to pay for the transaction requested by the buyer agent.

Under today’s web architecture, enabling an autonomous agent to access a seller’s service typically requires a series of manual, human-mediated steps. This process must be repeated for every new seller the user wants their agent to interact with (see Diagram A below): 

Diagram A: Today’s Human-Mediated Workflow

1. User Registration & Identity Verification. The human user discovers the seller service and creates an account with the seller, usually by filling out a form or signing a contract. Identity verification requirements vary by seller from basic email confirmation to full Know Your Customer (KYC) or Know Your Business (KYB) checks, depending on the nature of the services provided.

2. Payment Method Setup. The human user adds a payment method, such as a credit card or bank transfer. Additional verification may be required depending on the payment processor and regulatory context.

3. Funding or Subscription. The human user either prepays for usage (e.g., credits), subscribes to a service plan or billing arrangement. This step is typically tied to the seller's internal billing system.

4. Agent Credential Provisioning. Once the account and payment details are in place, the human user creates an API key, client ID/secret, or other credentials for their agent. Today, little or no information about the agent itself is collected or verified during this step.

5. Credential Injection. The human user manually embeds the API key or client credentials into the agent, enabling the agent to authenticate with the seller on the user’s behalf.

6. Agent Authentication & Access. The agent uses the provided API key or credentials to authenticate and call the seller’s APIs and services. In some cases, The API key or client credentials may be exchanged for session tokens or OAuth2 access tokens as part of the authentication and authorization process.

This model significantly limits the world of autonomous agents. For buyers, it creates a growing operational burden, as manual setup and maintenance are required for each new service and tool. The effort grows linearly with every additional seller integration. It also increases implementation complexity for sellers, as it requires them to manage the authentication and authorization of human users and programmatic users differently.

Identity-Linked Agentic Transactions, an Alternative Model 

To support seamless and autonomous interactions between agents, we propose a new workflow (see Diagram B below) that binds identity and payment into a portable token. This enables agents to transact securely, verifiably, and programmatically without manual approval loops.

Diagram B: Identity-Linked Agentic Transactions Workflow

In the Identity-Linked Agentic Transactions model, identity verification involves both traditional KYC/KYB processes and the validation of agent identity, collectively referred to as Know Your Agent (KYA).

The roles of KYA and Payment Provider may be fulfilled by a single entity or distributed across multiple parties. In many implementations, the Payment Provider also acts as the issuer of tokens that embed both verified identity and pre-authorized payment information for the buyer. This consolidation simplifies issuance and verification, while maintaining the flexibility to delegate responsibilities to specialized providers as the ecosystem evolves.

This new category of providers will provide buyers reusable tokens that can be used for account creation, authentication, and payments, accepted across multiple Sellers. If providers can align on a shared token structure, it further increases utility and interoperability, making it easier for sellers to accept such tokens without needing to implement or validate multiple bespoke formats.

Introducing KYAPay: Identity-Linked Tokens That Anyone Can Implement

As builders who have experienced the limitations of closed, centralized payment and identity systems, we believe the agentic AI era demands a fundamentally more open, interoperable approach. So, while we continue to develop our commercial platform, we also began designing and building KYAPay, an open protocol based on the Identity-Linked Payment Transactions Model. 

In the following sections, we will introduce KYAPay, which includes the identity-linked JWT token data model we have defined, and demonstrate an example of how it can be issued and validated using Skyfire’s APIs as an example implementation. 

A Lightweight JSON Web Token

For KYAPay, we intentionally began with a lightweight JWT (JSON Web Token), focused on the essential attributes: just enough to know who is making the request (the agent), who is responsible for it (the user or organization behind the agent), and a valid payment method with sufficient balance. This approach keeps the system simple for early adopters, while laying the groundwork for a more capable and interoperable future. Behind the simplicity, though, we’ve built in upgrade paths and design flexibility, reserving room for richer semantics, cryptographic proof types, and interoperability features to evolve over time. 

At its core, our token is a standards-compliant JWT that embeds:

• Identity claims: Attributes about the agent or user, such as business name, email, or unique agent ID.

• Payment metadata: A reference to a pre-authorized payment token, subscription, or credit balance.

The result is a portable, tamper-evident, cryptographically signed token that any compatible service can verify and act on, removing the requirement for human login, and manual session management. An agent simply presents the token, the service validates its signature and claims, and the transaction proceeds securely.

Three Defined Token Types 

Based on our own implementations, we have defined three token types for KYAPay to begin with, each designed for a specific agent use case:

• KYA Token: ("typ": "kya+JWT") Contains identity information only, used for account creation, login, or verifying the agent or its owner.

• Pay Token: ("typ": "pay+JWT") Contains payment authorization only, used when the agent is already authenticated and needs to complete a transaction.

• KYA + Pay Token: ("typ": "kya+pay+JWT") Combines identity and payment data, enabling seamless guest checkout, where an agent can both identify itself and pay in a single interaction.

Example Token (JWT)

Header

{

  "kid": "<JWK Key ID>",

  "alg": "ES256",

  "typ": "kya+pay+JWT" // or "kya+JWT" or "pay+JWT"

}

Payload

{

  // Standard claims (from the JWT spec)

  "iss": "<issuer URL>",

  "iat": 1742245254,  // 'issued at' timestamp

  "exp": 1773867654,  // expiration timestamp

  "jti": "b9821893-7699-4d24-af06-803a6a16476b", // unique token id

  "sub": "<Buyer Agent Account ID>",

  "aud": "<Seller Agent Account ID>", // audience binding, prevents replay

  // Skyfire-defined claims common to both 'pay' and 'kya' types

  "env": "<Issuer environment (sandbox, production, etc)>",  

  "ssi": "<Seller Service ID>",

  "btg": "<Buyer Tag (Buyer's internal reference ID)>",

  // Skyfire-defined claims for 'kya' (Know Your Agent) type tokens

  "bid": {  // Buyer Identity claims

    "email": "buyer@buyer.com”, 

    “businessName": "Buyer Inc."

  },

  "aid": {  // Agent Identity claims

  },

  // Skyfire-defined claims for 'pay' (Agent Payment) type tokens

  "spr": "0.010000", // Seller Service Price

  "sps": "PAY_PER_MB", // Seller Service Pricing Scheme

  "amount": "15.000000", // Token Amount in Currency units

  "cur": "USD", // Currency units

  "value": "15.000000", // Token Amount in Settlement Network

}

Key properties of the token include:

1. Follows standard JWT structure (RFC 7519) for broad compatibility;

2. Cryptographically signed (using RFC 7515 - JSON Web Signatures) to ensure integrity and authenticity;

3. Designed to work with emerging decentralized identity frameworks (e.g., Decentralized Identifiers, verifiable credentials);

4. Tied to expiration windows. 

We share our token structure to enable the shared consumption of identity-linked payment tokens, with the goal of fostering a more interoperable ecosystem — one where agents from different networks can recognize, trust, and transact with each other seamlessly.

A Skyfire Example Implementation of KYAPay

Building on the reusable data model for identity-linked payment tokens introduced earlier, this section presents a Skyfire’s example API for issuing and verifying such tokens. This API is intended as an example implementation to demonstrate how the token model can be put into practice. While we believe it offers a convenient and developer-friendly approach, it is by no means the only way to implement or interact with these tokens. As adoption grows, we anticipate the emergence of diverse implementations and APIs across the ecosystem, all built on the same underlying token standard.

In the Skyfire’s example API that enables programmatic identity verification and programmatic payments, Skyfire takes on the roles of KYA and Payment Provider. Users are typically individuals or businesses in one of two categories (or possibly both):

• Buyers (or buyer agents): AI agents and other autonomous or semi-autonomous systems that purchase and consume goods, services, and/or tools, to perform a task or execute a workflow on behalf of the individual or business, e.g., consume APIs, purchase data, scrape websites for information.

• Sellers (or seller agents / seller services): Websites and services that sell goods, services, and/or tools, e.g., a seller of licensed images, a seller of premium financial data, a service that sends emails on demand, a content owner that publishes informational articles on their website.

API Entities

To understand how the identity-linked payment tokens are produced and consumed via the Skyfire’s example API, it's helpful to understand the overall entity model.

User

• At the top-level is a User. This is a human who creates an account with Skyfire. 

  • This human typically represents an individual or a business

• The User is either developing programmatic buyers (e.g., agents), programmatic sellers (e.g. MCP servers, agents), or possibly both.

Agent Account

• A User creates Agent Accounts.

• An Agent Account can represent a buyer or a seller but not both.

(In our example, we have limited a User to a maximum of one buyer Agent Account and one seller Agent Account.)

• The buyer Agent Account is created by default when a new User signs up.

• The User can create a seller Agent Account if they wish to sell goods, services, and/or tools programmatically to Buyer Agents.

• Buyers and sellers access their Agent Accounts programmatically using their API keys.

  • Each agent can have one or more API keys that are unique to that agent.

Wallets

• Each Agent Account comes with a Wallet.

• Buyers fund their Wallets so that they can purchase goods, services, and/or tools.

• Sellers receive funds in their Wallets once they provide the goods, services, and/or tools and charge the pay and/or kya+pay Tokens.

Buyer Agent

• Buyer Agents purchase or consume goods, services, and/or tools from Seller Agents.

• Buyer Agents may need to create accounts with Seller Agents and/or pay them.

• Buyer Agents create kya, pay, and/or kya+pay Tokens using the example API.

• Buyers pass the created Token to the seller when calling the seller’s MCP server or other APIs.

  • The buyer must adhere to the seller’s MCP server or other API contract.

  • Sellers may require the tokens to be passed in an HTTP header, request body, or some other payload field.

Seller Agent

• The Seller Agent account is NOT created by default when a new User signs up.

• The User creates the seller Agent Account if they wish to sell goods, services, and/or tools programmatically to Buyer Agents.

Seller Services

• Sellers create one or more Seller Services under their Seller Agent.

• Sellers can create a distinct Seller Service for every good, service, and/or tool that they want that Seller Service to sell/have consumed by buyers.

• Seller Services can be remote MCP servers, local MCP servers, or other APIs.

• Sellers specify the price, pricing scheme and buyer identity requirements for each Seller Service.

• Sellers specify how the Tokens must be passed to them in their MCP server or other API specification, e.g., HTTP header, request body, or some other payload field.

• Sellers inspect and verify the passed Tokens using standard JWKS mechanisms.

  • Sellers use the kya Token and/or the kya portion of the kya+pay Token, to create accounts, checkout the buyer, and/or conduct other business operations that require the buyer’s identity.

  • Sellers use the pay Token and/or the kya+pay Token, to charge the buyer once the goods, services, and / or tools have been provided.

    • Sellers call a Skyfire API to do this and Skyfire moves the funds from the buyer’s Wallet to the seller’s Wallet.

• Buyers create kya Tokens that contain the required identity fields and pay Tokens for the required sum of money.

  • Buyers can also create combined kya+pay Tokens.

• Sellers can make their goods, services, and / or tools available for free if they choose to.

  • In this case, buyers will likely send only kya Tokens that contain buyer identity information.

  • Sellers do not charge kya Tokens as no funds need to be moved.

Tokens

• Tokens are created by a buyer for a specific Seller Service.

• Buyers and sellers exchange Tokens directly with each other.

  • Skyfire is not involved in the exchange.

• kya Token

  • kya Tokens contain key-value pairs that specify the verified identity of the individual or business that owns the Buyer Agent.

  • The seller could use the verified identity of the buyer to create an account for the agent/buyer.

• pay Token

  • pay Tokens contain the payment value that the buyer has committed to pay to the seller when the seller provides the particular good, service, and/or tool.

  • Sellers charge the pay Token via the Skyfire example API once the good, service, and/or tool is provided.

• kya+pay Token

  • kya+pay Tokens contain both identity and payment value.

  • Sellers can use these to enable a guest checkout experience for the buyer.

API Workflows

Identity Verification

• Both buyers and sellers can verify their individual or business identity, which we call KYA in Skyfire’s system.

  • A User can verify as only one of an individual or a business.

• The User’s verified identity becomes the identity of all their agents, both buyers and sellers.

• A seller’s verification is displayed on each of their seller services in the Skyfire marketplace.

  • Buyers use this to build confidence in the seller.

• A seller can require a buyer to provide specific identity fields.

  • Buyers create kya and / or kya+pay tokens to share this with sellers.

Wallet funding

• Buyers can fund their wallets via Credit Card, Debit Card, USDC or ACH.

Platform and API Access

All API interactions in the example require authenticated access via API keys, which are created per agent (buyer or seller) in the Skyfire dashboard.

• Platform: https://app.skyfire.xyz

• API Endpoint: https://api.skyfire.xyz

Authentication 

To authenticate API requests, include your agent's API key in the skyfire-api-key header. Each agent (buyer or seller) manages its own keys.

Buyer Agent Integration

Onboard Buyers 

Buyer agents interact with seller services by creating and sending tokens. These tokens convey identity (KYA), payment, or both. The token format and transmission method are determined by the seller's API specification. See how to set up a buyer account in Skyfire. 

Create token 

This endpoint allows a buyer agent to create a kya, pay, or kya+pay token. These tokens are used to authenticate and/or authorize a transaction with a seller. See API details and sample code in Skyfire.

Seller Integration

Onboard Sellers 

Sellers and seller agents are responsible for validating incoming tokens, extracting necessary identity or payment data, and charging tokens once goods or services have been delivered. Skyfire example tokens can be verified using standard JWT libraries and JWKS key sets. See how to set up a seller account in Skyfire. 

Verify Token

Seller services must verify token authenticity and extract claims to determine identity attributes and payment parameters. This ensures that requests are authorized, valid, and aligned with the seller’s configuration. See API details and sample code in the KYAPay Github.

Charge token

This endpoint enables a seller to charge a buyer’s token once a service has been rendered. Sellers can perform full or partial charges, and retrieve updated balance information after the charge. See API details and sample code in the KYAPay Github.

Next steps for KYAPay 

Beyond this initial launch, we will continue to evolve our token and API model into a more standardized open protocol, grounded in common cryptographic primitives, well-defined authorization workflows, and interoperable identity frameworks. Our goal is to align with protocols developers already use and trust, while ensuring broad compatibility across businesses, the public sector, and the open-source ecosystem. 

Looking ahead, we plan to release additional, full protocol documentation and implementation guidelines to support adoption of identity-linked payment tokens across a wide range of agentic applications.

Vision Roadmap: "From Compatibility to Interoperability"

Building for agentic AI means planning for a world that doesn’t fully exist yet but is coming fast. As we developed our commercial platform and designed KYAPay, we recognized that this work cannot exist in isolation. It must be deeply connected to a fast-evolving ecosystem of protocols, standards and agent infrastructure.  

To navigate this progression, we’ve defined a Vision Roadmap: a pragmatic strategy that starts from today's infrastructure and builds toward a future of open and interoperable agent systems.

This roadmap reflects both a development philosophy and an engineering trajectory: start where the world is, and build toward where it needs to go.

Phase 1: Ensure Infrastructure Compatibility 

We began by working with the web infrastructure that already powers the internet today. This phase focuses on immediate utility — making agents usable within the boundaries of existing systems — while minimizing long-term lock-in.

• Use OAuth2 for human and agent authentication and authorization

• Support API key workflows and centralized access control

• Provide practical tooling for identity and payments without requiring protocol changes

This ensures that early adopters can deploy real-world use cases, while laying the foundation for more interoperable systems.

Phase 2: Introduce Identity-Linked Payment Tokens 

We are entering this phase now as we introduce our core contribution to the ecosystem: KYAPay, a standards-compliant identity-linked token format for agents. These tokens combine verified identity with payment authorization, allowing agents to gain access to gated services and APIs without additional logins or manual setup.

• Embed identity and payment logic in a single portable JWT

• Enable agents to present tokens for gated access to APIs, models, or other agents

• Keep the format flexible enough to evolve toward decentralized standards

This phase bridges the gap between centralized compatibility and decentralized potential.

Along with our current launch partners, we are working to bring on buyer focused agentic platforms, agent developers, AI interfaces as well as sellers of tools, data, content and agentic marketplaces.  Beyond these direct participants, we’re working to include participation from established identity platforms, payment services, and key infrastructure providers.   

Phase 3: Integrate Open Identity Standards

As decentralized identity standards mature, we’re prepared to evaluate and incorporate them natively into our architecture. These additions enhance agent trust, verifiability, and autonomy, enabling agents to interact without relying exclusively on centralized gatekeepers.

• Support for Decentralized Identifiers (DIDs) for agent and user identity

• Use Verifiable Credentials (VCs) for attestations, roles, and proof of reputation

• Enable agents to verify claims cryptographically at runtime

This phase lays the foundation for long-term interoperability across platforms, agents, and services.

Phase 4: Enable Full Agent Interoperability 

In the final phase, we envision a fully open, agent-native ecosystem, where agents from any network can interact, transact, and negotiate securely, without bespoke integrations or platform permission.

• Agents can discover and trust each other using shared identity and trust layers

• Tokens and credentials are portable, verifiable, and reusable across services

• Economic coordination (pricing, payment, negotiation) is automated

At this point, the system moves from platform-governed to ecosystem-driven — with agents, not platforms, as the primary actors.

Invitation: Explore, Experiment, and Collaborate 

This whitepaper marks our first step toward building an open, shared identity and payment layer for agentic AI, rooted in simplicity, extensibility, and interoperability. By introducing KYAPay with a lightweight, standards-compliant token format and practical APIs, we aim to lower the barrier to experimentation and accelerate ecosystem-wide adoption.

We believe this work lays the groundwork for a future where agents can authenticate securely, transact autonomously, and collaborate across services and domains, without being confined to proprietary platforms or heavyweight integrations.

We invite developers, protocol architects, agent framework creators, and infrastructure providers to explore compatibility, test out our APIs, and contribute to shaping KYAPay. Your insights, feedback, and use cases will directly inform the evolution of KYAPay and help define what trust, identity, and value exchange look like in an agent-native world.

About the Authors 

Authors: 

Ankit Agarwal

Head of Engineering, Skyfire

Craig DeWitt

Co-Founder & Head of Product, Skyfire

Contact: 

KYAPay@skyfire.xyz

Contributors: 

Dmitri Zagidulin

Partner, DID.coop, and Architect, MIT DCC

Lucy Yang 

Managing Partner, Identity Woman in Business

Kaliya Young

Founding Partner, Identity Woman in Business 

KYAPAY.ai

Licensed under CC BY-SA 4.0

kyapay@skyfire.xyz

KYAPay GitHub: https://github.com/skyfire-xyz/kyapay

Demo GitHub: https://github.com/skyfire-xyz/skyfire-solutions-demo