Giving a Coinbase AgentKit wallet a verifiable identity

AgentKit gives an agent a wallet, and via x402, a way for that wallet to pay for things. It doesn't give that wallet anything a third party can verify beyond "this address exists." This page is about adding that, not about replacing AgentKit, and not about anything AgentKit itself doesn't already do well.

The gap

A wallet address proves control of a key and the ability to sign a transaction. That's the whole job it was built for, and AgentKit does that job properly. What it can't do, no wallet-address scheme can, on its own, is answer the questions a relying party actually has once an agent starts acting on its own: who operates this agent, has that operator been checked by anyone, and what is this specific agent actually authorized to do. Two AgentKit wallets that behaved identically yesterday could belong to a vetted, accountable operator and to nobody in particular, and the address alone gives no way to tell them apart. That's the general argument in more depth here; the AgentKit instance of it is exactly this: a real wallet, a real signing capability, and no portable, third-party-checkable identity attached to it.

The compose-with integration

The additive step is to issue a did:solidus identity, see did:solidus, and a BBS+ capability credential (see BBS+ Signature) that anchor to the wallet AgentKit already provisioned, rather than asking a developer to stand up a second wallet or migrate away from one. Mechanically, this uses the agent-identity SDK's "bring your own key" custody path: the DID-creation transaction is built and signed with the same key controlling the AgentKit wallet, so the chain enforces that the identity is bound to a key the developer already holds, Solidus's backend never takes custody of it. The BBS+ credential issued alongside it is a capability credential: a signed, selectively-disclosable statement of what this specific agent is authorized to do, checkable by a relying party without exposing anything beyond the specific claim it asks for.

Correction, 2026-08-02, and it matters because it points the other way from the paragraph above. The published package now ships an AgentKit adapter, @solidus-network/agent-identity/agentkit, and that adapter does not use the bring-your-own-key path. It delegates to a shared adapter core that hard-codes managed custody, so the backend generates a fresh signing key, encrypts it under a single escrow key and keeps it. A developer who reaches for the obvious import therefore gets the opposite of what the paragraph above describes: a second key, held by us, sitting next to the AgentKit wallet rather than bound to it. The bring-your-own path is real and is what this page recommends, but it has to be chosen explicitly, by calling createAgent with byo custody and passing the AgentKit signer, rather than by importing the adapter named after AgentKit. That gap is examined in full on the AgentKit composition page, and it has been filed as a product defect rather than left to be discovered.

One honest gap, stated plainly rather than smoothed over: as of this writing, there is no published, verified code sample that names AgentKit specifically end-to-end, the agent-identity SDK's own docs describe the bring-your-own-key mechanism in general terms, against any externally-held signing key, not against AgentKit's SDK by name. The mechanism composes cleanly with what AgentKit already exposes (a signer the developer controls), but a concrete "issue into an AgentKit wallet" walkthrough hasn't been written and tested yet. Better to say that than invent a snippet that looks more turnkey than what's actually shipped.

What this makes possible

Once the identity and the capability credential exist alongside the wallet, a relying party, another agent, a platform enforcing a spending policy, a merchant deciding whether to extend credit, has something to check that isn't just "this address exists." It can ask who's accountable if the agent misbehaves and get an answer traceable to an operator credential, not just a key. That's what "procurement-ready" means here: not a certification, not a guarantee, but the specific gap a security or compliance reviewer flags when a bare wallet address is the whole story, closed, without touching anything AgentKit already provides.

None of that replaces AgentKit. The wallet, the signing, the x402 payment path, all of it stays exactly as AgentKit built it. This is one additive call layered on top, not a migration away from it.

The proof, checkable now

The mechanism this page describes, a did:solidus identity anchored alongside an existing key, with a checkable credential attached, is the same one already live and independently verifiable for the one real agent passport Solidus has issued: ERC-8004 token 8064 on Base Sepolia. Verify it yourself with two eth_calls and one DID resolution, no AgentKit involved yet, but the identity-and-credential mechanism being described is the same mechanism, already running, not a hypothetical. For what the BBS+ credential itself can prove without over-disclosing, see the selective-disclosure demo, AgentKit ships no selective-disclosure primitive of its own, which is exactly the piece this integration adds.

What this is not