An agent presents a valid identity and still exceeds its authority. A verifier reads a public manifest and still cannot answer three questions at the moment of action: who authorized this action, within what scope, and what record will prove the decision later. Know Your Agent (KYA) matters because agents now initiate payments, call tools, and change state without a human in the loop for each step. Identity disclosure alone does not answer those three questions. A runtime decision does. We argue that builders should order KYA work by decision, not by disclosure: bind the action to a principal, check a scoped delegation credential, enforce the check at the tool or payment gate, record the decision in a replayable chain, and publish disclosure last. The four systems in this article each cover part of that chain. None covers the full chain. The payment networks add a fifth pressure that the four systems do not resolve: counterparties accept only credentials they already verify.
Figure 1 is the decision chain this article defends, in check order.
Figure 1: The decision chain, in check order. A verifier checks principal, delegation, gate, and evidence before it trusts disclosure.
Why disclosure fails — the three questions a manifest cannot answer at action time: authorization, authenticity, and accountability.
Open-KYA Manifest — what a machine-readable disclosure artifact proves, what it leaves unchecked, and why no universal certifier exists.
KYA-OS conformance — how DIF structures adoption from existing identifiers to enterprise audit, and where demonstrations stop short of deployments.
KYAPay and payment coupling — why identity without payment authorization changes nothing for merchants, and why a single token must not merge two checks.
The payment incumbents — Visa, Mastercard, and Google AP2, and the credentials that merchants and networks already verify today.
Runtime scoring — how the arXiv KYA Framework scores behavior, where its design is strong, and where its numbers need caution.
Where the systems disagree — trust roots, credential formats, and enforcement points that do not align, plus fragmentation, revocation, and liability gaps.
Builder's Playbook — the adoption order we recommend, with a copy-ready checklist that starts from the counterparty credential.
Open-KYA publishes a disclosure artifact. A verifier reads the artifact, checks signatures against governance keys, and applies local policy to constraints and evidence. The artifact proves what the agent claims. It does not enforce a limit at action time. Builders use it to publish claims in a machine-readable form.
KYA-OS structures delegation and adoption. A verifier checks a delegation credential, its scope, and its revocation status. The system supports existing identifiers at Level 1 and credential-based delegation at Level 2. At Level 3, both parties verify each other and audit trails become immutable. Builders use it to move from simple identifiers to enterprise delegation without changing credential formats at each step.
KYAPay couples identity with payment authorization. A token carries identity information and a payment authorization in one signed JWT. A merchant verifies the token, creates an account, and captures payment after delivery. Builders use it when a merchant needs identity and payment in a single presentment, inside a platform that issues both.
The arXiv KYA Framework scores runtime behavior. Gates check identity, action, and tool permission. Rogue signals feed a score that moves with behavior. Evidence chains record decisions for replay. Builders use it when they need continuous monitoring inside their own runtime, not merely disclosure to a counterparty.
Start with the principal. Ask who the agent acts for, and ask for the identifier that binds the agent to that principal. If the agent cannot name its principal, stop the review. An agent without a principal has no delegation to check. A principal without an identifier has no accountability to enforce.
Next, read the delegation credential. Ask what scope the principal granted, what limits apply, and when the credential expires. Ask whether the credential covers this tool, this merchant, and this amount. If any answer is missing, treat the action as unauthorized until the principal supplies it. Scope gaps are authorization gaps, not documentation gaps.
Next, locate the gate. Ask where the check runs: on the tool call path, on the payment path, or at the edge. Ask what happens on failure: denial, approval routing, or logging only. A gate that logs only does not enforce. A gate that sits beside the path does not block the path. Fail-closed behavior is the test. A missing credential, an expired credential, or a revoked credential must produce a denial.
Next, test the evidence chain. Ask for a record of one past invocation, with prompt, tool call, arguments, decision, and outcome. Ask whether an auditor can replay that record without the agent runtime. If replay requires the runtime, the chain proves little in a dispute. If the chain uses a single operator key, say so plainly. Operator verification is not third-party verification.
Finally, read disclosure last. Ask for manifest version, conformance level, trust root, and revocation behavior. Ask when the manifest last changed, and whether a policy-bearing change updated it. A manifest that predates a tool change is stale. A manifest that omits revocation behavior is incomplete. Disclosure that passes those checks adds context. Disclosure that fails them adds risk.
Authorization asks whether a principal granted this agent a scoped delegation for this action class. A delegation states scope, limits, and expiry. A verifier reads those fields before it allows an action. An action without a delegation, or outside a delegation, fails this check. The paid section examines delegation formats and their limits in detail.
Authenticity asks whether the request binds the action to that delegation. A signature must cover the action, not merely the agent identifier. A verifier checks the signature, the key, and the delegation reference together. A valid agent identifier with an unsigned or mismatched action fails this check. The paid section examines signature and credential formats for each system.
Accountability asks whether the system records the decision in a form an auditor can replay later. A record must include principal, agent, tool, arguments, decision, and outcome. A verifier must replay that record without trusting the agent runtime alone. A log without a delegation binding, or a chain without a verifiable key, fails this check. The paid section examines evidence chains and their key limitations.
A final free-section point frames the paid argument. The systems in this article do not fail for lack of cryptography. They fail when a verifier accepts a credential without checking scope, expiry, revocation, and enforcement point together. The paid section tests each system against that combined check, and it names the test that each system passes and the test that each system fails.
