FACT overview

FACT (TM) gives AI agents a portable, verifiable identity so platforms can decide who they are dealing with, who the agent represents, and whether to trust or challenge an action.

Problem FACT solves

• Platforms have no shared way to confirm which verified person or business an agent represents, whether that identity was checked anywhere else, or what to do when the agent crosses ecosystems.
• Payment and agentic commerce protocols (Stripe and OpenAI ACP, Google AP2, Coinbase x402) assume an agent identity model but do not standardize it.
• KYA (Know Your Agent) gaps mirror KYC/KYB: accountability, revocation, and auditability of non-human actors.

Proposed solution

FACT is a portable credential that binds:

• The verified principal (person or organization) behind the agent.
• The agent instance, tied to stable cryptographic material.
• A verifiable principal-agent relationship without baking in permissions.
• Issuance, refresh, and provenance metadata.

Federated means any compliant issuer can mint FACTs; relying parties choose which issuers to trust and apply their own policy. Validation and revocation use open mechanisms (VCs, OIDC4VC, JOSE).

How FACT works

Four layers compose a FACT:

• Identity layer: verified principal attributes (e.g., KYB/KYC outputs, registry data).
• Agent binding layer: cryptographic binding between principal and a specific agent instance.
• Identity delegation metadata: asserts the agent carries the principal's verified identity; scopes and permissions remain out of band.
• Risk and provenance layer: optional risk scores, lifecycle events (creation, rotation, suspension, revocation), and provenance signals.

Relying parties verify issuer signature, integrity, validity window, and agent anatomy (model family, context window, modality, hosting). They can fold in risk/provenance signals per local policy.

Use cases

Agent-initiated checkout

• User or business completes KYC/KYB once; issuer binds the agent and issues a FACT.
• At checkout, the agent presents its FACT; the payment platform verifies issuer, cryptography, and optional risk.
• When policy passes, the platform can skip redundant challenges while keeping an auditable link to a certified agent.

Agent-initiated on-ramp or account action

• Agent presents a FACT when funding accounts or triggering account changes across providers.
• Providers verify the FACT, apply local controls (jurisdiction, instrument risk), and avoid repeated onboarding for returning agents.
• Supports high-frequency, autonomous transactions with revocation and auditability.

Why standardize

• Aligns with identity research (KYA, OpenID Foundation work on agentic AI) and regulatory interest in agent accountability.
• Complements agentic payment protocols (ACP, AP2, x402) by filling the missing identity layer instead of competing with them.
• Federated, multi-stakeholder: no single vendor gatekeeps agent identity; issuers, financial institutions, and platforms can participate; relying parties keep control over policy.

References (selected)

• OpenID Foundation, Identity Management for Agentic AI (2025)
• D. Greenwood, AI Agent ID (2025)
• Trulioo, Know Your Agent (KYA) white paper
• Captain Compliance, KYA: Know Your AI Agent (2025)
• Skyfire, Know Your Agent (2024)
• OpenAI Developers, Agentic Commerce Protocol (ACP)
• Stripe, Developing an open standard for agentic commerce (2025)
• x402, The Payment Protocol for Agentic Commerce (2025)
• Orium, Agentic Payments Explained: ACP, AP2, and x402 (2025)
• Visa, Trusted Agent Protocol announcement (2025)
• Consumer Reports and Stanford Digital Economy Lab, The Race to Standardize Agentic Commerce (2025)
• OnFinality, What is x402? (2025)