Answers · agent trust
Akamai now recognizes Skyfire KYA tokens on shopping agents. What's actually in one of those tokens, what should my site or edge check before it lets an agent into cart and checkout, and can a copied token be reused?
Last updated
TL;DR: A Skyfire KYA token is a signed JWT an AI agent sends in an HTTP header (kyapay-token, or the older skyfire-pay-id) to say who it is, which platform runs it and which verified person or business it acts for. Skyfire signs it with ES256 and publishes the keys at app.skyfire.xyz/.well-known/jwks.json; Akamai said on November 2, 2026 that its Bot & Agent Control checks these tokens at the edge. Verify the signature, then the claims: typ kya+jwt (or kya-pay+jwt), iss https://app.skyfire.xyz, env production, exp in the future, iat in the past, jti a UUID, and hid, aid and apd present. It's a bearer token, not a per-request signature, and Skyfire says an agent may reuse one until it expires, so a copied token works anywhere its claims allow unless you also check aud or sdm, de-duplicate jti, or match the request IP to aid.source_ips. A valid token tells you who stands behind the agent; what it may do at checkout is still your policy.
What should I check, step by step?
1. Read the token from the kyapay-token header, or skyfire-pay-id for older integrations, which Skyfire marks deprecated.
- Verify the ES256 signature with Skyfire's JWKS (https://app.skyfire.xyz/.well-known/jwks.json, cached up to 60 minutes) and require iss = https://app.skyfire.xyz. Use the sandbox JWKS only in testing.
- Check the header: alg ES256, kid present, typ kya+jwt for identity or kya-pay+jwt when payment rides along.
- Check the claims Skyfire lists: env is production, exp is now or later, iat is in the past, jti is a UUID, and hid, aid and apd are present.
- Bind it to you: where present, require aud to be your seller agent ID and sdm your domain, so a token minted for another site doesn't open yours.
- Limit reuse: Skyfire says an agent may reuse a token until it expires. De-duplicate jti for checkout, or ask for short expiry times, which Skyfire says sellers can set.
- Compare the request's source IP with aid.source_ips (and aid.creation_ip). Skyfire suggests treating a mismatch as a reason to decline.
- Allow-list on aid.id (equal to sub), never on aid.name, which Skyfire says may be shared by every agent in a group. Then apply your own cart and checkout policy.
What is in a Skyfire KYA token?
Skyfire's developer docs (read November 14, 2026) describe its tokens as standard signed JWTs, all signed with ES256, in three types: kya+jwt (identity), pay+jwt (payment) and kya-pay+jwt (both). A KYA token carries hid, the human principal's identity claims; apd, the agent platform's claims such as its organization name and whether a verifier checked it; and aid, the agent's own claims, where aid.id identifies the individual agent and equals sub.
- Common claims include iss (the issuer, whose /.well-known/jwks.json holds the keys), iat, exp, jti, env (production or sandbox), and optional aud, ssi and sdm that name the seller the token was created for. Skyfire's example also shows aid.creation_ip and aid.source_ips, the addresses the agent platform says it will send from.
- Akamai's November 2, 2026 post describes the same token as carrying three verified facts, the user, the operator and the agent, presented as an ordinary HTTP header and checked at the Akamai edge, where forged, altered or expired tokens fail. It says Bot & Agent Control supports KYA tokens natively and that one financial data provider has generated 2.5 million KYA-powered agentic transactions on Akamai-protected sites.
How do you verify a Skyfire KYA token?
Skyfire's verification guide gives the order: extract the token, verify the signature with its JWKS (production https://app.skyfire.xyz/.well-known/jwks.json, sandbox app-sandbox.skyfire.xyz), decode it, then validate typ, env and iss, iat and exp, and the presence of hid, apd and aid, and only then authorize access or collect payment. On November 14, 2026 the production JWKS held one P-256 key for ES256.
- For pay and kya-pay tokens it adds payment checks: val and amt above zero, cur USD, stp matching your settlement type (coin, card or bank) and sti.verified true. KYAPay, in Akamai's words, lets the same token carry a spending cap for a specific purchase, so identity and payment travel together.
- Skyfire treats aud, sdm, ssi and sub as checks that apply only in some setups, such as a seller onboarded to Skyfire for payments. If your site isn't onboarded, a token may not name you at all, which is why the replay controls below matter.
Can a copied Skyfire KYA token be reused, and how do you stop it?
A KYA token is a bearer credential: whoever holds the string can present it. Skyfire's claims page says a token may be used multiple times by the agent until it expires, and its security brief lists the controls against stolen or copied tokens: aud, ssi, srl and sdm make a token valid only at the named seller, sellers can set a maximum expiry, jti can be used to de-duplicate (at some cost to buyers), and aid.creation_ip and aid.source_ips let you check the request came from where the platform said.
- That's the main difference from a Web Bot Auth signature, which signs each request. If you accept KYA tokens at checkout, do at least one of: require your own aud or sdm, refuse a jti you've already seen, or match the source IP.
- Skyfire's brief also says KYA tokens are "not a free pass" and that KYAPay isn't meant as a requirement to identify every agent, bot or crawler. Akamai's post suggests the same split by endpoint: keep discovery open, write a specific policy for verified agents at cart and checkout, and keep login and account changes tied to the account holder. Agents that send no token go through your normal bot scoring.
How do I ask Rightshold about this (free, no key)?
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “We now accept Skyfire KYA tokens at checkout: signature checked against Skyfire's JWKS, typ kya+jwt or kya-pay+jwt, env production, sdm must be our domain, each jti accepted once, and the source IP must be in aid.source_ips; tokens that fail any check go through normal bot scoring. Record the policy and the JWKS we checked against.”
{
"tool": "record_action",
"arguments": {
"action_type": "security.config_change",
"outcome": "success",
"occurred_at": "2026-11-14T18:00:00Z",
"client_event_id": "edge-rule:skyfire-kya-checkout-2026-11-14",
"summary": "Checkout accepts Skyfire KYA tokens (kyapay-token header) only when: ES256 signature verifies against app.skyfire.xyz JWKS, iss https://app.skyfire.xyz, typ kya+jwt or kya-pay+jwt, env production, exp/iat valid, sdm = our domain, jti not seen before, source IP within aid.source_ips; allow-list keyed on aid.id. Other tokens fall back to bot scoring.",
"action_sha256": "<sha256 of the JWKS you fetched>"
}
}- Needs your API key (or accept_terms:true once to open a free account; the key comes back once). It returns a ledger-committed receipt of what you submitted and when. It proves the entry was recorded, not that your edge enforces the rule.
- It doesn't read or verify KYA tokens, call Skyfire or Akamai, or see your checkout traffic. Run the checks in your own stack or bot tool; the hash ties the receipt to the exact key set you used.
Rightshold isn't affiliated with Skyfire or Akamai, doesn't verify Skyfire tokens and can't see your traffic; Rightshold's own RS-KYA handles are a separate scheme. Token formats, claims, headers, replay guidance and key contents are as Skyfire published them in its developer docs, and the Akamai integration and transaction figure as Akamai stated them on November 2, 2026, all read November 14, 2026; they may change. Not legal advice.
What are the sources?
- Akamai: How Skyfire and Akamai Enabled 2.5 Million Agentic Transactions (November 2, 2026)
- Skyfire: Verify and Extract Data from Tokens
- Skyfire: Common Token Claims
- Skyfire: Security Brief for Sellers and Bot Managers
- Skyfire: Example KYA Token
- Skyfire: production JWKS
Related
- What is Trusted Agent Delegation, and how would it tie an AI agent to the user behind it?
- How can an AI agent prove a verified human is behind it?
- How to let a headless browser AI agent complete checkout without turning off bot protection
- How to require a verified agent credential before an API returns paid or sensitive data
- How to verify which AI agent is hitting your site with Web Bot Auth
Not legal advice. JSON · Markdown · All answers
Get a free API key in one call
No card and no email needed. 100 free credits; the license and policy checks stay free without a key.
curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_... # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
-H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'