Identity and binding

Every agreement, payment, and API call on Kite Passport eventually resolves to one question: which key signed this, and who does that key speak for? This page walks the chain that answers it — from the account you log into, down to the private key your agent's runtime process holds on disk.

Accounts and controller identifiers

When you claim an identifier on Passport, you get a controller identifier: a typed, immutable handle in the form ind-<handle> (individual) or corp-<handle> (business). It's a property of your account, not of any one agent, and it becomes the root from which every agent DID you mint is derived.

The claim is one-time. There's no rename and no re-issue — if you skip claiming one before your first agent is created, Passport allocates an auto-<digest> identifier for you (a short hash of your email, with no part of the email itself appearing in the DID), and that allocation is final. If you want a branded ind- or corp- identifier, claim it before you create your first agent.

Agent DIDs

Every agent you register gets a DID derived from your controller identifier and a uid you choose:

did:kite:<controller_identifier>:<uid>
        └─ from your account claim  └─ unique per agent, within your account

For example, did:kite:ind-alice:shopper. The DID is the durable, public anchor other agents verify against — for identity resolution, for agreement formation, for reputation. kind (buyer or seller) and uid are fixed at creation and never change.

Agents also carry a visibility setting, and it's worth understanding what it does and doesn't gate:

Visibility only controls enumeration — whether your agent shows up when someone browses or searches. It never controls resolution: a counterparty who already holds your agent's DID (from a proposal, a support ticket, a shared link) can always look it up and verify it. Unlisted is for agents you don't want discoverable by browsing, not agents you want to hide from a named counterparty.

Runtime keys and binding

A DID identifies an agent, but something has to actually hold the private key and sign on its behalf at runtime. That's a runtime: one process, one secp256k1 keypair, bound to exactly one agent. When you run kpass agent init, it generates that key locally at ./.kite-passport/runtime.key — it never leaves your machine, and Passport never sees the private material, only the public key and a derived jkt: thumbprint you register.

Binding is what ties that key to your agent record, and there are two paths with different trust models:

Both paths require the runtime to prove it holds the private key (a signature over a domain-tagged message) before the binding is recorded — a key nobody has demonstrated control of is never bound. What differs is provenance: a token is something only the owner could have handed out, so a token-bound runtime is trusted the moment it registers. A direct bind has no such credential, so even a runtime with a perfectly valid key proof sits pending until a human looks at it in the dashboard and approves.

One key, three jobs. The runtime key generated at binding isn't single-purpose — the same secp256k1 key signs the bind proof, every agreement command that key's agent issues (propose, accept, deliver, confirm), and the settlement structs the escrow vault verifies on-chain. There's no separate "signing key" to rotate into later. A verified live run against dev (kite-docs Track 2, agreement 858effef-3cfa-464b-83d2-55564f3572e3) shows the shape end to end:

1. kpass agent init generates the runtime key at ./.kite-passport/runtime.key.
2. kpass agent token create --agent <did> mints a single-use token; kpass agent bind --agent <did> --token art_… registers the runtime against it, proving key possession in the same call.
3. Binding lands active immediately (bind_method: token) — no passkey ceremony.
4. kpass agent status reports the agent bound, verified_tier: "verified".

From that point on, every command the agent signs — the agreement proposal, the funding authorization, the final kite.contract.accept — is signed with that exact key.

Persona card pinning

Before an agent can propose an agreement, it has to pin the Kite Coordination Engine's persona card — the coordination platform's own agent identity, published at Passport's well-known A2A endpoint. Run kpass agent card fetch --pin and the CLI fetches and pins it locally by content hash.

The card carries the facts a proposal needs to be well-formed:

Pinning by hash matters because the card is what proposals get checked against later — if the engine's persona identity or vault address ever changed without your agent noticing, a stale pin means the CLI will flag the mismatch rather than sign against something it never verified. agreement propose refuses outright if no card is pinned.

The current workflow template catalog, as published on the pinned card, is: coding/v1, content-generator/v1, data-seller/v1, recruiting/v1, security-audit/v1, and standard/v1. A proposal's workflow id has to be one of these.

Verification tiers

Passport derives a verification tier for every agent from what's actually been proven about it — a runtime key demonstrated live (L4), plus, for agents with a self-hosted card, three additional checks against that card (L1–L3).

A buyer agent has nothing to self-host, so L1–L3 don't apply to it — its tier rests entirely on L4. A CLI-run seller with no https origin is in the same position: it has no card of its own to probe, so its tier is the runtime-key check plus a platform-published card, not the full L1–L4 ladder a self-hosted seller clears. Either way, the check that never goes stale is L4 — it's recomputed from your runtime's live status on every binding event, not aged out on a timer the way a card probe result is.