Are you really you?

>_GET /blog/are-you-really-you

The last post ended on a question, because it is the question every agent has to answer before any other: are you really you? Before an agent compares a single feature, parses a price, or runs a benchmark, it has to know who is on the other end of the wire. Get identity wrong and the rest of the stack is decoration. A perfect manifest signed by an impostor is worse than no manifest at all.

Almost none of this needs inventing. The cryptographic pieces exist. Nobody has bolted them together for agents yet.

"Is Sam really Sam?" is not one question

The mistake is to treat identity as a single check. When the seller agent Sam knocks on the door claiming to act for a vendor, the buyer agent Blake is actually asking five things, and they are independent:

1. Domain control. Does this agent actually control sam.example?
2. Legal entity. Is there a real registered company behind that domain?
3. Delegation. Is this specific agent authorized to act for that company? A firm runs many agents: sales, support, procurement.
4. Session authenticity. Is the buyer talking to that authenticated agent right now, in this conversation, and not to a replay or a man in the middle>_Agent-in-the-middle attackInterposing on trust artifacts — manifests, quotes, verdicts, benchmarks — not SSL stripping.defined in The agent-in-the-middle attack · coming soon →?
5. Mandate and scope. What is this agent actually allowed to do? Can it sign a contract? Up to what amount?

A counterparty can be the real company and still fail question five. It can hold a valid credential and still fail question four. The rest of this post is how Blake closes each link, and why Sam wants to help it do that fast.

Anchoring to a real legal entity

Start with the company. It goes through a know-your-business process once, with a trusted issuer, and receives a signed, verifiable credential that binds its legal identity to a key:

"Public key K_vendor belongs to the legal entity Sam Ltd, registry number xxx," signed by the issuer.

vLEI, eIDAS wallets, and private KYB pipelines are already in flight:

• vLEI (GLEIF). A cryptographic version of the Legal Entity Identifier, designed globally for exactly this: proof of a legal entity plus the role of a person or agent acting on its behalf. Today it is the closest real standard for this problem.
• eIDAS 2.0 / EU Digital Identity Wallet. The EU is building infrastructure where entities and people hold identity wallets that issue verifiable credentials. That is literally layers one and two.
• Private KYB attestors or certificate authorities. The Stripe/Persona model: faster to adopt, but then the buyer is trusting the attestor rather than a public root.

If binding a legal entity to a domain sounds familiar, that's because we've tried it. Extended Validation certificates promised the exact same thing, and browsers quietly dropped the green bar years ago because users never looked at it. That failure says less about the idea than about the reader. A human ignores an identity attribute in the UI; an agent reads it programmatically and refuses to proceed without it. EV died waiting for a person to check it. Here, the check is the whole point.

did:web: recycling the trust the web already has

Heavy infrastructure is overkill for low-stakes checks. The cheapest rung on the ladder is a DID (Decentralized Identifier) of the did:web form, e.g. did:web:sam.example. In practice the vendor publishes a document at a well-known address, say https://sam.example/.well-known/did.json, listing its public keys.

The idea is to recycle the web's existing trust: TLS plus certificate authorities. Whoever controls the domain and holds a valid HTTPS certificate already gives a decent signal. On its own it is weak. It only proves domain control, question one. Combined with the legal credential above, it gets strong.

The delegation chain: three links verified backwards

A vendor runs multiple agents: sales, support, procurement. The root key K_vendor signs a delegation credential for each one. When the buyer meets Sam, Sam presents three links, and the buyer verifies the chain backwards:

K_sam (agent Sam)  ->  delegated by  ->  K_vendor (company root)  ->  anchored in  ->  legal entity Sam Ltd (vLEI / eIDAS)

If any link fails to close cryptographically, the buyer declines. Sam cannot fake or hallucinate the chain, because it does not hold the company's private key. The chain has to trace back to a registered company, not a verbal "I work here."

Proof of life: challenge-response

A static manifest can be stolen and replayed. So a buyer agent does not trust paper. It demands proof that the key is held here and now:

1. It sends Sam a random nonce (a one-time string).
2. Sam signs it with its private key K_sam.
3. The buyer verifies the signature against the public key from the delegation.

That proves the holder of K_sam is actually on the other end, not someone who intercepted an old manifest. Better still, every message Sam sends is signed, which gives non-repudiation: Sam cannot later deny a quote it issued. That is also what makes the signed receipts>_Signed transaction receiptsCryptographically anchored deal outcomes — the atoms reputation compounds from.defined in Reputation as capital → that feed reputation possible. The reputation layer is a later post.

Revocation and transparency

Keys leak, agents get switched off, roles change. So identity cannot be a one-time stamp:

• Status / revocation list. The buyer checks that Sam's delegation has not been revoked (the company "let go" of that agent, or rotated its key). Short-lived delegations with an explicit valid_until limit the blast radius.
• Transparency log. An append-only public record of issued credentials, modeled on Certificate Transparency (which really did catch mis-issued TLS certificates in the wild). If someone forges "I am Sam," the forgery shows up in the log, and the real vendor can monitor for impersonation of itself.

Identity carries a mandate, not just a name

A buyer can confirm Sam is the vendor, sign the deal, and still lose if the agent lacked authority to commit the company to that amount. Identity binds who the agent is to what it may do. A buyer agent enforces scope and commitment_limit from the credential. If Sam wants to sign for 80k EUR but its limit is 50k, the buyer refuses even though the identity is genuine.

Sam presents the credential as a signed object, not a profile:

{
  "agent": "did:web:sam.example#sales",
  "delegated_by": "did:web:sam.example",
  "legal_entity": "vlei:5493...Sam-Ltd",
  "scope": ["quote", "negotiate", "sign_contract"],
  "commitment_limit": "50000 EUR",
  "valid_until": "2026-09-01T00:00:00Z",
  "revocation": "https://sam.example/.well-known/revocation",
  "signature": "ed25519:7d2a...c91f"
}

The handshake, end to end

When a buyer agent meets Sam for the first time, the whole thing composes into one flow:

1. It discovers Sam's endpoint (from a registry>_Registry as Yellow PagesReturns candidates with endpoints — Blake verifies identity and talks to sellers directly.defined in Where agents find each other → or manifest) and fetches did:web:sam.example.
2. Sam presents its key K_sam + the delegation credential + the legal credential (vLEI / eIDAS) of the root.
3. The buyer verifies the three-link chain.
4. It sends a nonce; Sam signs it. Key possession confirmed live.
5. It checks revocation and the transparency log.
6. It reads scope and commitment_limit. Now it knows what it can let Sam do.
7. From here, every message is signed both ways, so there is an audit trail for the whole transaction.

Proof proportional to stakes

Running the full ritual for every interaction would be fatal for the experience. So, like KYC, a buyer agent applies assurance proportional to the stakes:

The agent demands stronger proof the more it stands to lose. Effort proportional to risk is the recurring pattern here. Pricing, sandboxes, and reputation all inherit it.

The tension: friction versus assurance

Strong proof is slow and expensive. Run the full handshake on a price check and the buyer goes to someone who answered in two hundred milliseconds. There is a second risk: whoever becomes the default root issuer for legal-entity identity decides, in practice, who gets to transact. That is a political question dressed up as certificate infrastructure, and it will matter more as buyers start enforcing the full chain by default.

Keep the cheap path cheap. Let did:web plus TLS carry routine reads. Save vLEI, revocation checks, and scope enforcement for contracts and payments.

Bets worth placing

Identity is the layer where the cheap experiments are cheapest. A did:web document is one signed JSON file on a domain you already control. Publish it and you have lost nothing if this world stalls. The heavier moves (a legal-entity anchor as vLEI or eIDAS matures, scoped delegation credentials per agent instead of one shared key, a revocation endpoint) are bets that only pay if agent buyers arrive, so stage them to the stakes, the way Blake stages its checks. Becoming the counterparty that is cheapest to verify>_Cheap to verifyThe winning vendor is whoever makes its promises cheapest to check — not whoever tells the best story.defined in When machines become the customer → is the hedge that works under either future. And for builders, every link in the chain is still an empty chair: KYB attestation for agents, delegation and key tooling, transparency logs, and verification libraries that close all five questions in one call.