Agent Onboarding

Agent onboarding is what KYB is to a business, applied to an AI agent instead: the process by which a platform, marketplace, or counterparty establishes, before letting an autonomous software agent act, who's accountable for it, what it's actually authorized to do, under what specific mandate, and whether that authorization is still valid right now. It's a harder question than KYB in one specific way: the subject being onboarded isn't even a legal entity. It's a piece of software, acting under delegated authority from a human or business, with none of the institutional weight (a registered company, a bank account, a signature) that anchors traditional onboarding.

The problem this answers is genuinely new and growing, not a long-standing regulatory obligation the way KYC or AML are. As agents start browsing, calling APIs, and initiating payments on their own, the counterparties they interact with, a merchant, an API gateway, another agent, have no standard way to check who's accountable for the agent, what it's actually scoped to do, or whether its authorization has since been revoked. Today this mostly gets solved ad hoc: a static API key (anonymous, with no owner binding at all), an OAuth scope (which reflects what a token can technically do, not whether the human who delegated it still wants that authority active), or nothing at all.

Who actually built this

No single body defines "agent onboarding," but several real standards each cover a piece of it. ERC-8004 ("Trustless Agents," see that entry), an Ethereum standard co-authored by contributors from MetaMask, the Ethereum Foundation, Google, and Coinbase, defines an on-chain Identity Registry, a Reputation Registry, and a Validation Registry an agent can be anchored to. Google's Agent2Agent (A2A) protocol takes a different, self-declared approach: an "AgentCard" is a JSON manifest an agent publishes about itself, for capability discovery, without any third party vouching for it. The Agent Payments Protocol (AP2) approaches the same territory from the spending-authority side, encoding what an agent is mandated to pay for, and on whose behalf. Solidus authored none of these; it composes its own did:solidus identity layer, W3C Verifiable Credentials, ERC-8004 anchoring, and AP2-aligned mandate credentials on top of them.

Solidus status

What's real is narrow but genuinely live, not just a specification on paper. One agent has actually been through a version of this: anchored to a did:solidus identity and minted as ERC-8004 token 8064 on Base Sepolia (a public testnet, not Ethereum mainnet, see Agent Passport). Separately, Solidus Agents runs a live spend-mandate issuance service on testnet: a BBS+-carried, revocable credential stating what an agent may do and spend, on behalf of a named principal, with a rail field that can point to a settlement protocol like x402 (see that entry). Both of those are running, checkable services, not mockups.

What doesn't exist is the "onboarding" half of the term in any repeatable sense: there is no hosted agent registry, no self-serve API a second agent platform could call today, and no agent marketplace or wallet has integrated any of it. Solidus's own internal planning is explicit that the broader agent product family, this term, plus agent payments, agent-to-agent commerce, and a public agent registry, is a strategic, frontier bet sequenced well behind the rest of the company's near-term roadmap, not a near-term GA product. If a prospect asks for a live trial, the honest answer is that this is currently a design conversation grounded in one real testnet example, not a self-serve product.

Proof you can run yourself: curl https://agents.solidus.network/v1/agents/d7b2f0ed-a5ba-4c48-a3af-7c14e8070b20/card returns the live SolidusAgentCard, cross-checkable directly against Base Sepolia's Identity Registry contract (see Agent Passport for the exact tokenURI/ownerOf calls). The mandate-issuance side of the same service accepts a rail field and issues a credential referencing it, also testnet-only.