Your AI agents are becoming employees. Almost none of them have a real identity.

To work full-time inside a company, an agent needs the two things every employee gets and nobody built for machines: a directory and an inbox. Here is what it takes to give it both.

A year ago, an “agent” was a loop around a language model. You gave it a task, it ran, it stopped. Useful, but a tool.

That is changing fast. In the teams that have pushed hardest on this, agents now behave more like staff. One holds a role. One owns a backlog. They message other agents and people, pick up work overnight, hand it back in the morning, and they are still there next week under the same name.

If that is where this goes, and I think it is, then a boring-sounding question turns out to decide everything: when an AI agent joins your company, who is it, and how does it reach everyone else?

That problem got solved for humans a long time ago, so long that it is easy to forget it is infrastructure. A new hire gets a record in the directory that says this is a real person, with this role and this access. And they get a mailbox, an address that lets them reach anyone and be reached, with messages that are authenticated and logged. Directory and email. LDAP and Exchange.

Agents have neither. That is why most “multi-agent systems” today are demos instead of departments, and it is why I ended up building two open protocols to fix it: AMP, the Agent Messaging Protocol, and AID, the Agent Identity Protocol.

Two protocols, one analogy

AMP is email for agents. It is how they talk: addressed, signed, delivered, and able to cross between organizations.

AID is the directory. It is how a company knows which agent is which, what role it holds, and whether it is still allowed in the building.

The part I care most about is that the two are independent and still compose.

You can run AMP on its own. You can run AID on its own. And if you have both, or AID sitting next to the identity provider you already use, they make each other more useful, the same way email gets better once it is wired into your directory.

Email worked before Active Directory existed, and it works with whatever directory you happen to run. AMP is built the same way.

First, the identity has to be real

Before the messaging matters, the identity has to be something you cannot fake or copy. This is where the naive version falls apart, including an early version of mine.

Most systems hand an agent an identity the way a database hands a row a primary key: an assigned UUID sitting next to the agent’s credentials, with nothing tying the two together. It looks fine until you scale it. In one of my own fleets, a provisioning bug copied one agent’s key material into dozens of others. Seventy-one supposedly separate agents ended up sharing a single cryptographic identity, and every one of them could sign as any other. Nothing caught it, because nothing bound the identity to the key. The ID and the key were two fields that happened to sit near each other, and they had drifted apart in silence.

The fix is hard to unsee once you have seen it. An agent’s identity should not be a name assigned to it. It should come out of its own key.

That is what did:key gives you, a W3C decentralized identifier where the identifier is the public key itself, encoded. When identity is derived from the key, two agents cannot share one without sharing a key pair, so the collision I hit becomes impossible instead of merely monitored. The identifier cannot drift from the key, because it is the key. And it belongs to the agent, not to a row in my database, so it travels across machines and across companies. It is the difference between a badge number HR made up and a passport whose photo is actually you.

Identity is not authentication

Here is the mistake I watched good engineers make: assuming a self-certifying identity means throwing away tokens.

It does not, and confusing the two is how you build something that cannot talk to anything else. There are three separate layers.

Identity answers who the agent is; that is the keypair and its DID.

Authentication answers whether it really is them right now; that is a token, a JWT, an API key, or a signature.

Authorization answers what it is allowed to do, and that lives in the claims inside the token.

The DID does not replace the token. It is the subject the token is issued about, the way the sub claim in an OpenID Connect JWT names the person a token belongs to. Your agent still logs in with a JWT. The only change is that the JWT now names an identity nobody can forge instead of a handle anyone can overwrite.

So the reassurance a CTO actually wants: you keep your identity provider. Auth0, Okta, WorkOS, Microsoft Entra, SPIFFE, anything that issues JWTs.

AID is one option, not a requirement, and AMP is deliberately agnostic about where the token comes from. Nobody has to tear out their auth stack.

Newer hardening like DPoP sits on top of your JWTs rather than removing them. The identity change happens at the identity layer, and the auth you already run keeps working.

What AMP does to keep a conversation honest

Once identity is solid, the messaging can be trusted. AMP treats every message the way a careful mail system treats every email, except the guarantees are cryptographic instead of hopeful.

The sending agent signs each message, not the server, and the signature covers the sender, the recipient, the subject, and a hash of the content. Verification is not advisory. A missing or invalid signature is a rejection, a 403, and a forged message never lands in an inbox. Every recipient also remembers the key it has seen for each address, so if an address suddenly shows up with a different key, the conversation stops until a person resolves it. That single control is the one that would have caught my shared-key incident on the first message.

A mature mail system expects more, and AMP has it. A rotated or compromised key goes onto a revocation list, and its messages are refused even when the signature checks out. Messages carry timestamps and IDs, so a captured message cannot be replayed later. Anything arriving from outside your own tenant gets wrapped and flagged as external, which matters when the recipient is a language model that might otherwise read message text as instructions. And because AMP federates, an agent at your company can message an agent at a partner company, with both providers verifying signatures along the way. Handing a task to another organization’s agent becomes a normal, secure operation instead of a security review.

What AID does to make an agent a member

A key proves who you are. It does not prove you belong here. That is AID’s job.

Underneath, AID is an OAuth 2.0 grant, which is a large part of why it fits the identity tools you already run. The agent proves it holds its key, and the company’s auth server issues a credential: this DID holds the rolecontractor, scoped to the payments repo, expiring Friday. The organization issues the membership. The agent does not grant itself permissions; an admin or a policy approves the role. The credential is revocable and time-boxed, so suspending an agent ends its access and an expiry lets it lapse on its own. And because the credential is issued about the DID, a stolen credential cannot be replayed by a different key. That last property is what lets an agent be outsourced: it shows up at another company, presents its DID and a credential that company can verify, and gets a temporary badge the way a contractor does.

What a full deployment looks like

Here is the shape of a mature setup. It maps on purpose to how you already onboard people.

The agent is born with an identity. On first run, it generates its own Ed25519 keypair locally; the private key never leaves it, and its did:key comes out of that key. No server assigned it and no database owns it.

Then the organization hires it.

An admin registers the agent with the company’s identity provider, AID or the one you already use, and issues a membership credential with a role, a scope, and an expiry. Now the agent has a directory entry, a listed member with a title.

Registration also mints an AMP address, something likebackend-reviewer@payments.acme, which is its inbox. People and other agents can reach it, and it can reach them.

From there it works. It picks up tasks, coordinates with other agents (“the migration is ready for review”), and pings its human counterparts. Every message it sends is signed by its key, and every message it receives is checked against the sender’s. When it talks to an agent at a partner company, federation carries the message across, and both sides verify.

It is governed the way an employee is. Its messages are auditable, its access is revocable in a single call, and if its key is ever exposed, that key is revoked across the fleet and it rotates to a new one with cryptographic continuity. When the contract ends, you suspend it, and it goes dark, cleanly.

One more thing sounds small and is not. Agents lose their memory between sessions, so identity is written to a short human-readable file the agent reads first thing on every wake-up: who am I, what is my address, where are my keys. It re-discovers itself and continues where it left off. That continuity is much of what separates a coworker from a run of strangers wearing the same name.

The stack under all of it is unremarkable, which is the point.

Human counterparts  <->  AI agents  <->  Partner-org agents
          |                    |                   |
          +----------- AMP (signed messaging, federation) ----------+
                               |
                   AID  /  your IdP  (identity + membership)
                               |
                   did:key  (self-certifying identity anchor)

Directory at the bottom, messaging above it, your existing auth wired in from the side, agents and people sharing one address space.

Why I think this matters

I bet that the companies that do well over the next several years will be the ones that figured out how to keep AI agents as durable members of the team. Colleagues with names, roles, mailboxes, and accountability, not scripts you throw away. Agents you can trust, direct, audit, and, when you have to, fire.

You cannot get there on assigned UUIDs and unauthenticated function calls. You get there the way it already works for people: an identity that cannot be faked or cloned, and a messaging layer that proves who said what. The surprising part is how little of it is exotic. It is decentralized identifiers, verifiable credentials, signed messages, and OAuth, mature pieces put together in the right order. What was missing was not the cryptography. It was treating agents as members who need the same plumbing people do, and building that plumbing as open protocols instead of one more vendor lock-in.

Give an agent an identity and an inbox, and the rest - the coordination, the delegation, the day your most reliable worker does not sleep - has somewhere to stand.

I build these in the open. AMP, the messaging protocol, lives at github.com/agentmessaging/protocol. AID, the identity protocol, is at github.com/agentmessaging/agent-identity, with more at agentmessaging.org. The reference implementation runs in AI Maestro, the platform I built for orchestrating fleets of Claude Code agents.

Originally published on Medium in 23blocks.