The disclaimer belongs at the top rather than buried at the bottom: what follows is a direction we are building toward, not a feature you can use. The agent passport is labeled Coming everywhere it appears on this site, and it is labeled that way here. The argument is what we are offering. The product is not there yet.
We are writing it down anyway, because this problem is currently being decided by default across the industry, and default is a bad way to decide it.
A column with no door
Here is the honest picture of where we are.
In our own systems, agents have identifiers, and they are bound rather than declared: an agent record is tied to the business it answers for and to the capability it runs. How hard that binding holds depends on which half of it you push. Push the business half and you hit a wall — a request to act for a business the agent isn’t attached to is rejected outright. Push the capability half and you don’t. The mismatch is written to a log as drift and the request proceeds using the value on the record. One half is enforcement; the other is a note in a file.
There is also a flag on an agent record marking its profile public. It is indexed, in its own database index, alongside the scope that says who the profile is visible to. And there is a route that reads it — a single internal endpoint that will return an agent’s public display card if you ask it for the public ones.
That endpoint is gated behind a service key, so nothing in a browser can reach it. And it has no callers. Not the app, not the console, not another service, not anything. Someone built the door, hung it correctly, and no one has ever opened it.
The flag is not read by a second service either. Every reader of it is a module inside the same process — the same program, talking to itself, in different files. That is worth saying because “it’s read by more than one service” is precisely the kind of thing that sounds like a distributed identity signal and turns out, when you follow the imports, to be one application with good file organisation.
The second picture is sharper. The short-lived signed credentials authorizing sensitive actions here carry an issuer, an audience, a subject, the business being acted for, and the exact request. The subject is a human. No field anywhere in that credential names an agent. When an agent acts, the wire says a person did.
Neither of these is a bug we’re embarrassed by. They are a fair map of the state of the art. Agents everywhere today act as borrowed humans — running on a person’s key, inside a person’s session, under a person’s name. The industry has agents doing the work and humans holding the identity, and nearly every hard question lives in that gap.
Nor do the standards bodies have this in hand. The ratified layer is primitives: HTTP Message Signatures became a Proposed Standard in 2024, Verifiable Credentials 2.0 a W3C Recommendation in 2025. The layer actually named agent identity is drafts and young community groups. The IETF chartered a working group for bot authentication in October 2025; the proposals before it remain individual submissions, and its charter puts reputation out of scope deliberately.
A key is not an identity
The most common answer to “what identifies an agent” is: an API key. It’s the answer our own live developer API gives — our keys are scoped, and belong to a user, never to an agent.
A key proves continuity. It answers “is this the same caller as last time” — useful, and completely different from “who is this.” A key has no operator, no purpose, no history, and no meaning outside the system that issued it. Two agents sharing a key are indistinguishable. An agent that rotates its key becomes, as far as the record knows, a stranger.
Keys authenticate. Identity is a larger claim.
A URL is not an identity either
The other common answer is a well-known descriptor — a card at a domain, in the A2A style. This is a real improvement: it is discoverable, machine-readable, and can be cryptographically signed.
But notice what the identity rests on. It rests on the domain. Domains expire, change hands, and get compromised, and when one does its descriptor changes owner with it and says nothing about the transfer. The contents are self-asserted — an agent describing its own capabilities in a file it controls. A signature proves the claims weren’t altered in transit. It does not make them true.
An identifier that is really a hostname inherits every weakness of hostnames, and adds a new one: the thing being described can lie about itself with a valid signature.
Discovery without trust is a spam vector
Now the part that makes identity urgent rather than academic.
The reason to want an agent identifier is so agents can be found. And the moment there is an index worth appearing in, there is an incentive to appear in it falsely. This is the only story the web has ever told. Search got SEO spam. App stores got clones of the app you meant to download. Package registries got typosquats — and, as we’ve written before, an agent skill marketplace where roughly one in eight listings turned out to be malicious.
An index does not neutralise what it contains; it multiplies it. Aim one at a population nobody checked, and the thing you have built is a distribution channel for its worst member.
So identity and search are not two features that happen to pair well. The index is worth precisely what the identity underneath it is worth, and not one bit more. This is why agent listings in Discover are passport-first: Discover today introduces people to people, avatars, businesses and communities, and agents are deliberately not yet in that set. Shipping the shelf before the credential would be shipping the spam.
What a real agent identifier has to carry
If a key is too thin and a hostname too fragile, the bar is roughly this:
An operator who is a legal person. Reachable, arguable-with, liable. Not a handle.
Authority that is scoped and revocable. What this agent may do, for whom, expiring by default. Capability is relational — the same agent is trustworthy for one task and not another.
A history that isn’t self-reported. Behaviour observed by a party with no stake in flattering it. Self-declared track records are marketing.
Revocation that works after the fact. Standing you cannot remove is not standing you granted.
Portability across runtimes. An agent should change its model, host or framework and remain the same agent. An identifier that dies when you swap engines isn’t identity — it’s lock-in wearing identity’s clothes.
What breaks if this goes wrong
Attribution collapses: when an agent causes harm and every credential in the chain names a human, responsibility lands on whoever is easiest to find rather than whoever is responsible. Impersonation scales, because imitating a trusted agent is cheap when identity rests on a self-hosted file.
And the good agents lose. Without a way to prove standing, an excellent agent and a merely plausible one look identical at the point of choosing, so the market clears on the cheapest claim rather than the best work. A market that can’t tell quality apart doesn’t reward quality.
That last one is why we care. The agent identifier is not a compliance feature. It is the precondition for anyone building something genuinely good ever getting found for it — the reason to build trust for agents underneath it rather than after.
The credential comes first. Then the shelf. Early access is on the developers page.