General communication workflow
With the rise of LLM platforms, internet users turn to AI agents to streamline their online experience. However, AI agents are bots that interact with websites, and the bot and fraud detection products that merchants commonly use to protect their sites are designed and trained to block such activity. AI agent developers are broadly adopting KYA to identify themselves and the platform they are running on to sites they want to interact with, provide visibility into the user principal they represent, their intent, and payment credentials to support agentic commerce. This translates concretely into the presence of a KYA JWT token with a set of claims in the request, which web security products protecting websites can use to authenticate the platform, the agent, assess the user and intent, and improve the accuracy of their Bot and fraud management strategy. This section describes the workflow and steps to integrate KYA validation into your bot and fraud detection stack.
Note: A lot of the claims included in the KYA standard are optional and their presence may vary depending on the depth of integration with the AI agent.
Figure 1 below shows the high level interaction between the user, agent, LLM platform, the token issuer, CDNs, merchants, CIAM, and payment gateways.
Fig.1: Communication between the various components servicing AI agents requests
A company running an AI agent registers with Skyfire or with another company that is federating agent identities. The business entity or individual is validated through KYB or KYC. Upon successful validation, an API key is returned.
Step 1: Once the initial registration is complete, the AI agent can use the Skyfire API key to call an API and generate a token to authenticate to the servers it needs to interact with.
Step 2: The token will include claims that identify at least the agent platform (apd). It may also include a claim that identifies the agent (aid) and one for the user principal the agent represents (bid). The information about the user and the agent is compiled into a JWT token and encrypted with a private key
Step 3: The agent sends the JWT token to the server it wants to interact with. The server may be fronted by a CDN and/or web security solution (bot manager, WAF). The web security solution must recognize the KYA token, retrieve the public key from its well-known location, decrypt it, and extract the various claims to validate it.
Step 4: The claims in the token help the web security solution to accurately identify the agents and categorize the traffic based on the information included in the claims
Step 5: The web security solution may share some of the user identity and payment claims extracted from the token with the web server, which will help create accounts as needed and complete a purchase.
Step 6: The agent is able to successfully access the resource and use the information retrieved to formulate an answer for the user or complete a transaction