Know Your Agent (KYA): A Practical Definition

What Is Know Your Agent?

Know Your Agent (KYA) is the process of verifying an AI agent's identity, delegated authority, runtime integrity, and reputation before the agent performs a consequential action. A KYA check asks who controls the agent, what the principal authorized, whether the current request is in scope, and whether the evidence supports allowing the action now.

KYA is not another name for bot detection. Bot detection asks whether traffic is automated. KYA assumes automation may be legitimate and decides whether this specific automated actor has verifiable authority for this specific transaction.

Why KYC Does Not Cover Agents

KYC verifies a human customer. It does not describe the delegation between a principal and an AI agent. An agent can keep a valid identity while its mandate expires, its tool access changes, or hostile instructions redirect its behavior. That makes identity necessary but insufficient.

The practical difference is cadence. Human identity is usually checked at onboarding and refreshed periodically. Agent authority can change between 2 API calls. KYA therefore belongs at the point of action, before payment, fulfillment, data access, or another irreversible step.

KYA vs KYC vs KYB

KYC verifies a person. KYB verifies a company. KYA verifies a delegation: an agent acting on someone else's authority. The first two run once, at onboarding, because people and companies change slowly. KYA must run continuously, because an agent's integrity can change between one transaction and the next.

• Subject. KYC checks a natural person. KYB checks a business entity. KYA checks an AI agent and the mandate it carries.
• Proof of identity. KYC uses government ID and a liveness check. KYB uses registration records and beneficial owners. KYA uses a passport bound to a principal.
• Proof of authority. A person acts for themselves. A company shows officer records. An agent needs a mandate: scope, limits, expiry.
• Cadence. KYC and KYB run at onboarding and refresh rarely. KYA runs at every consequential transaction.
• Failure mode. KYC fails on stolen or synthetic identity. KYB fails on shell companies. KYA fails on a hijacked agent whose identity stays valid while its intent is replaced.
• Revocation. Human and business credentials revoke slowly, through case work. Agent authority must die in one call, from outside the agent, before the next transaction clears.

The last two rows carry the argument. A stolen human identity is an identity problem. A hijacked agent is not: its identity stays perfect while its intent is replaced. When that happens, revocation cannot wait for a case worker.

What Is an Agent Passport?

An Agent Passport is a signed identity object for an AI agent. It can carry a stable agent reference, principal binding, mandate version, wallet or workload associations, lifecycle status, and reputation context. A counterparty can resolve the passport before accepting an action.

A passport does not prove that every request is authorized. Possession of a passport ID is not proof of control, and a valid passport is not a blanket spending credential. Transaction authority still requires evidence that binds the acting agent, the principal's mandate, and the action being requested.

The 6 Layers of a Full KYA Check

• Principal Identity. Which person or company stands behind this agent?
• Agent Identity. Is this the same agent that was issued the passport?
• Wallet Provenance. Where did this agent's funds come from?
• Authorization Scope. What is this agent allowed to do, for how much, until when?
• Environment Identity. Is the agent running where it should run?
• Cross-Merchant Reputation. How has this agent behaved across other counterparties?

A vendor that checks 1 or 2 of these layers is doing agent identification. KYA requires all 6, because attackers route around whichever layer you skip.

The 4-State Verdict

A KYA check should end in an actionable decision, not a score alone. FLINT returns 1 of 4 verdicts: ALLOW, STEP-UP, REVIEW, or BLOCK. ALLOW means the evaluated request may proceed. STEP-UP identifies additional proof needed for a fresh decision. REVIEW sends the request to a human decision-maker. BLOCK means the caller should stop the transaction because affirmative evidence does not support execution.

The signed record does not move funds, hold an order, or freeze a passport by itself. Enforcement belongs to the system integrating the verdict. That separation keeps the evidence honest about what FLINT decided and what the merchant, platform, or agent operator actually did.

The Signed Verification Record

A signed verification record is the tamper-evident receipt of a KYA decision. It identifies the transaction, agent, authority context, evaluated signals, verdict, reason codes, rules version, and decision time. FLINT signs the record so a buyer, seller, auditor, or dispute team can verify that the evidence and verdict were not altered after issuance.

The record proves what FLINT evaluated and decided. It does not prove that the caller enforced the verdict, that a payment settled, or that the transaction later produced a good outcome. Those facts must be captured separately and linked back to the record.

Identity Is Not Integrity

Identity answers which agent is acting. Authority answers what that agent may do. Integrity asks whether the current runtime and request still serve the principal's mandate. Reputation adds prior outcomes. These are separate evidence categories because a strong result in one category cannot repair a failure in another.

This separation matters during agent takeover and prompt injection. A compromised agent may keep the same cryptographic identity while its instructions and behavior change. A system that verifies identity alone can authenticate the compromised agent perfectly.

How KYA Fits With Agent Identity and Payment Standards

KYA is a decision layer that composes existing identity, authorization, workload, wallet, and payment evidence. It does not need to replace the systems that create that evidence.

• Identity credentials DIDs, verifiable credentials, signed agent cards, and enterprise identities can establish who issued or operates an agent.
• Authorization standards OAuth grants, capability tokens, mandates, and policy engines can express what an agent may access or spend.
• Workload identity SPIFFE and runtime attestations can show where an agent workload is running and whether that environment is expected.
• Payment protocols x402, cards, bank transfers, and stablecoin rails can prove how value moved and whether payment conditions were met.
• KYA decisioning KYA combines the relevant evidence for the current action, returns a verdict, and preserves a signed record of the decision.

The distinction is practical: a credential can be valid while the action is out of scope, and a payment can settle while the agent lacks authority. KYA evaluates the combined transaction rather than treating any single credential as sufficient.

How to Add KYA to an Agent Transaction

KYA belongs immediately before the consequential action. The integration pattern is small enough to describe as 5 steps.

• 1. Identify the request. Bind a unique transaction or action ID to the amount, counterparty, resource, and requested operation.
• 2. Collect authority evidence. Present the agent identity, principal or delegation evidence, mandate, and any transaction-bound authorization.
• 3. Verify at transaction time. Evaluate identity, authority, wallet or payment context, environment, and reputation before execution.
• 4. Act on the verdict. Proceed, request more proof, route to review, or stop according to the returned decision.
• 5. Retain the record and outcome. Store the signed verification record, then link the completed, disputed, refunded, or rejected outcome back to it.

Common Questions