The open KYAPay protocol gives an agent record a fixed shape: a human identity, an agent identity, the platform that operates it, and the scope of what was checked. Experian’s Know Your Agent framework reads records in that shape, and between them they fix the form of the claim.
KYA ATTESTATION · KYAPAY-MAPPED · SIGNED
The verifier field on an agent record is usually their own name.
KYAPay reserves that field for a third party. We fill it - signed, dated, and revocable.
hid
aid
apd
scope
verifier
Our promise
“A mark you cannot follow is a decoration.”
Every claim is written against the field it lands in — the protocol’s where the protocol defines one, ours where it does not. The fee is fixed at $5,000, and nothing is charged until you approve it.
Request this verificationThe case file
The attestation, in three chapters
What neither settles is whether any of it is true. Both the human and the platform objects reserve three separate fields for a verifier — a name, a flag and a reference — and on most records in the wild those fields are empty, or they carry the name of the party the record is about.
Ours is the independent read. We check the human, the entity standing behind it and what the agent is really able to do, write our own name into the field the protocol reserves for a party like us, and then publish the result where anyone can follow it up without having to ask us first.
The four objects
Four objects. Two of them name a verifier.
The protocol fixes who asserts what, and leaves whether it is true to somebody else.
- hid - the human, and the verifier triple beside them
- Name, organization and email, checked against documents
- aid - the agent, and what it is able to do
- Name, endpoint, capabilities hash, agent_ref
- apd - the operator, and its own verifier triple
- The principal that answers for the agent, named not implied
- scope - how far the mark actually reaches
- Verification tier and declared capabilities, stated
Know who is asserting
The claim is yours. The schema is theirs.
The operator, running the agent
Whoever puts an agent into service under their own name is who a relying party comes to. What it can do, whose authority it spends, which human stands behind it - those are your assertions, and a field in a record is a place to put a claim rather than evidence for one. In the JSON the two look identical.
The people who defined the shape
KYAPay defines the claim's structure and Experian's Know Your Agent framework defines what a relying party does with it. Both do that job well. Neither checks whether your particular agent is what your particular record says it is, which was never what a schema is for. A shape is not evidence.
When you are your own verifier
The verifier / verified / verification_id triple is the only part of the record a relying party can lean on, and nothing stops a platform writing itself into it. Self-asserted verification has the shape of verification and none of its weight, and the two are indistinguishable until someone who is not the subject checks.
What most teams assume
“Our record says verified, so we’re covered.”
What the field says
Verified by whom? That field is the answer.
It is the most common finding we write up.
- Who it is for
- Agent platforms
- Agent operators
- Marketplaces & registries
- Payment & fintech rails
- Procurement & vendor risk
Standing & the verifier slot
02
A self-asserted “verified” parses exactly like a checked one. The two are indistinguishable until somebody follows the reference beside it.
03
A record with no revocation path is a photograph of a fact rather than the fact. Ours is withdrawn on change, never quietly amended.
04
The status resolves at a public verifier, so nobody has to ask us whether it still holds. It is checkable from outside, by anyone.
The 60-second check
Three questions. Then you’ll know.
No email, no signup. A starting point, not a determination.
Opens in a panel. Close it any time - your answers are kept.
KYA attestation
Your standing check
The lifecycle
Four states, and every attestation is in one.
An attestation is a claim about a moment, not a certificate - so it carries the date it was taken, and it has a way of stopping being true.
-
Issued
At verificationThe identity is checked by a person, the triple is populated with our name, and the record is signed and dated.
-
Published
Same dayThe attestation reaches our public verifier, so a relying party can confirm it without ever contacting us.
-
Re-verified
Every 12 monthsA verification is a claim about a moment. Twelve months on it is checked again, or it lapses on its own.
-
Revoked
On any changeChange the operator, the endpoint or the capabilities and the old record is revoked rather than quietly edited.
The trap
Teams read an attestation as a certificate and forget it is dated. A record issued against capabilities that have since changed is still signed, still parses, and is no longer true - which is exactly what state 04 is for.
Field & mapping
What the protocol defines, what we write
12 fields, and what goes into each one. Paired, so every claim on this page can be checked against the field beside it.
- Who the verifier is KYAPay - verifier, and it is not you
- iDharma named in the field, as a party with no stake in the answer and no fee tied to it.
- How the identity was checked Beyond the protocol - our method, stated
- The evidence a person actually looked at, recorded against the claim it supports rather than summarised.
- Human identity KYAPay - the hid object
- The verified consultant: name, organization and email, checked against documents rather than a form.
- Agent identity KYAPay - the aid object
- The notarized agent: name, endpoint, capabilities hash and agent_ref, each one recorded as found.
- Agent platform KYAPay - the apd object
- The agent's operator or principal - the party that answers for it, named rather than implied.
- The verifier triple KYAPay - verifier / verified / verification_id
- iDharma, the verified flag, and the badge code or notarization reference that resolves it.
- Scope KYAPay - the scope object
- The verification tier and the declared capabilities, so nobody reads the mark as wider than it is.
- Our own fields iDharma extension - idharma_extensions
- reputation, provenance and revocation_status, inside a named envelope and labelled as ours.
- Provenance iDharma extension - SHA-256
- A hash over the capabilities as verified, so a silently changed agent stops matching its own record.
- Revocation status W3C VC credentialStatus pattern
- A status a relying party can read at any moment, on the pattern the W3C already settled for this.
- Public checkability Our verifier, not our word
- Every attestation links back to our credential verifier, so nobody has to take the JSON on trust.
- What it is not Not authorship, not endorsement
- Compatibility with two published standards, stated as that - neither of them has certified us.
The engagement
Your agent, independently read
From a single tool-using assistant to a whole fleet.
-
Verify
Who the human is, whose the agent is, and what it is actually able to do.
-
Map
Each verified fact into the KYAPay field the protocol reserves for it.
-
Sign and publish
You see the JSON first. Then it is signed, dated and made checkable - by anyone.
Struck in your favour
Why a relying party should believe our entry
Genuinely independent
We build, resell and operate no agents of our own, and take no fee tied to what we find.
Mapped, never invented
Every protocol field carries the protocol's meaning; anything else is under our own envelope.
Signed, dated, revocable
A verification is a claim about a moment, so ours carries its date and can be withdrawn.
Checkable without us
The status resolves at our public verifier, so nobody has to ask us whether it still holds.
Four marks, struck on every attestation.
Deliverables
What you get
Concrete artefacts, each with a name and a format - you know what lands before you buy.
The KYA-compatible attestation
The signed JSON itself: hid, aid, apd and scope populated from what was actually checked, the verifier / verified / verification_id triple carrying our name and a reference that resolves, our own reputation, provenance and revocation fields inside a labelled idharma_extensions envelope, and a link back to the public verifier.
Verification record
What was checked, by whom and on what date, with the evidence named against each claim rather than summarised as a conclusion.
Public verifier entry
A permanent page a relying party can open without contacting us, showing the current status of the attestation rather than its status at issue.
Registry entry and badge
Your entry in the verification registry, with a badge that carries its own code so the mark on your site resolves to the record behind it.
Field mapping memo
Which of your facts landed in which protocol field, which went under our envelope, and why each call was made - the record behind the JSON.
Provenance hash set
The capabilities as verified, hashed, so a quietly changed agent stops matching its own attestation instead of continuing to pass.
Revocation and re-verify plan
What triggers a revocation, who can raise one, how fast the public status changes, and the date the next re-verification falls due.
Format & fee
Real numbers, upfront.
- Scope
- Set by the protocol, not by us
- Input
- Your agent and what stands behind it
- Re-verify
- Annually, or on change - $3,000 against your known baseline
The protocol fixed the fields, not us, so the fee is flat - nothing to meter, and nothing charged until you approve it.
Request your attestation
KYA attestation · Verification
$5,000 flat
- Independent verifier triple
- Full KYAPay field mapping
- Public verifier entry and badge
- Revocation path included
Show your hand
Four things a relying party has to be able to read
A record is not graded on intent. Each of these is either legible on the day somebody checks, or it is not.
The human,
named
A person or an organisation that answers for the agent, checked against documents rather than a signup form. An account is not an identity, and neither is a domain.
The verifier,
independent
Somebody other than the operator in the verifier field, with a reference that resolves. A record whose only witness is its own subject has actually told you nothing at all.
The scope,
bounded
What was actually verified and what was not, written down. A tier and a capabilities list stop a narrow check from being read across an agent that it never looked at.
The status,
current
Whether the attestation still stands today, readable now rather than as at issue. A signed record with no revocation path is a photograph of a fact, and not the fact itself.
Four cards, and the date on each one is part of the card.
FAQ
Plain answers
Standing, contents, and what happens when it lapses. Answered straight.
Request your attestationAre you endorsed by Experian or Skyfire?
No. "KYA" and "Agent Trust" are Experian frameworks and "KYAPay" is an open Skyfire protocol. We produce attestations compatible with them as an independent verifier, and neither organisation has certified us.
What is the verifier field, and why does it matter?
Both the human-identity and agent-platform objects carry a verifier / verified / verification_id triple - the named place a third party asserts an identity was checked. On most records it is empty or holds the operator's own name.
What stops you writing your own name in there?
Nothing in the protocol - which is the point. What makes ours worth reading is that we operate no agents, take no fee tied to the finding, publish the status where anyone can check it, and revoke rather than edit.
What is actually in the attestation?
The protocol's own objects - hid, aid, apd, scope - filled from what a person checked, the verifier triple naming us with a reference that resolves, and our reputation, provenance and revocation fields under a labelled envelope.
How long does it take?
Typically one to two weeks from hand-over for a first attestation, longer where the agent's capabilities turn out to be wider than the documentation says - which they usually are. Scope is agreed before anything is charged.
Get started
Request your attestation
Tell us about the agent and the entity behind it, and we come back with a scoping call within one business day.
What we need from you
Nothing you do not already have. Most of this is a folder someone can assemble in an afternoon, and we name every document first, in writing, before you commit.
- Which agent you want attested, and what it can do
- The legal entity and the human who answer for it
- Any documentation - agent card, endpoint, scopes
- Whether you built the agent, bought it, or host one
- What your own record claims about it today
What happens next
- You send the five items we need.
- You get a scoping call within one business day.
- Nothing is charged until you approve the scope.
Sources & standing
Where this page gets its facts
Where the claims on this page come from, and what they are worth - stated, not assumed.
What it is drawn from
- Skyfire KYAPay profile (IETF draft)
- Experian Know Your Agent / Agent Trust
- Read on
- 17 July 2026
- Status
- Live drafts
What it means
- General information about two published standards and how our attestation maps onto them — not legal advice, and no professional relationship arises from reading it.
- Compatibility is not endorsement: neither Experian nor Skyfire has certified, admitted or approved iDharma.
Scope & limitation
- Both source documents are live drafts and can move under this page.
- It covers the attestation format alone - your own regulatory duties are elsewhere.
- Use it as a starting point for a scoping conversation, not as your final word.
Has either standard moved since we last read it?
Tell usFrom Insights
Before you rely on an agent
What Is an AI Audit? Scope, Standards, and What You Get
An independent review of what your AI actually does, measured against a named standard — not a certificate, and not a review of what the documentation says it does.
Read the notes
METHODOLOGY NOTES
How to Prepare for an AI Audit: The Readiness Checklist
Six things to have ready before the engagement starts. Assembling them takes a fortnight off the clock — and tends to find the first two findings before an auditor does.
STANDARDS EXPLAINED
What an AI Governance Framework Actually Contains
Five working parts, not a policy document. What each one has to do, how to tell whether yours is real, and why a framework is not the same thing as compliance.
STANDARDS EXPLAINED
ISO/IEC 42001, SOC 2 and NIST AI RMF: Which One Your Buyer Is Actually Asking For
One certifies an organisation, one is an opinion about controls over a window, one is a method with nothing to issue. What each covers — and what none of them answers.
