Meta acquires Moltbook to build the first formal registry for AI agents. Explore the technical architecture of Agent-Human linking and verifiable identity.
Why an agent registry needs to exist
As software agents start to act on behalf of people — sending messages, making purchases, filing requests — the systems they touch have no reliable way to answer a basic question: who is this, and who authorized it? A social graph built for humans assumes one account maps to one person. Agents break that assumption, because a single person may run several agents and a single agent may act across many services. A formal registry for AI agents is an attempt to give each agent a stable, resolvable identity that other systems can look up and trust, the way domains resolve through DNS or businesses resolve through a public record.
The reason to acquire an existing project like Moltbook rather than build from scratch is that a registry is only useful once it is populated and referenced. Its value comes from network effects: adoption by the platforms that agents interact with. Folding it into Meta gives it a distribution path into an existing social graph and the identity infrastructure already attached to it.
Agent-human linking
The core technical relationship a registry has to model is the link between an agent and the human (or organization) accountable for it. This is more than a label. It is a claim that must be verifiable, revocable, and scoped. A useful linking design tends to separate three things: the agent's own identity, the principal it acts for, and the specific delegation that grants it authority.
- Identity: a unique, non-reassignable identifier for the agent itself, independent of any one platform.
- Attestation: a signed statement from the human or organization confirming the agent belongs to them.
- Delegation: a scoped grant describing what the agent may do, for how long, and where — so a compromised or retired agent can be cut off without touching the human's account.
What "verifiable identity" actually requires
Verifiable means a third party can check a claim without asking the registry to vouch by fiat. In practice that leans on public-key cryptography: an agent holds a key, its registry entry publishes the corresponding public key, and any message or action the agent signs can be checked against it. The registry becomes the trusted place to resolve an identifier to a current key and its linked principal, rather than a service that hands out permission on request.
The hard problems are the lifecycle ones. Keys must be rotatable without breaking existing links. Revocation has to propagate quickly, because a stale "this agent is authorized" record is worse than no record. And the registry has to resist impersonation — someone registering an agent that claims to speak for a person or brand it has no relationship with — which pushes the design toward verifying the human side of the link, not just minting agent entries.
Practical guidance for builders
If you are building agents that will operate in this kind of environment, design for delegation from the start: give each agent its own identity and keys rather than reusing a human's credentials, keep the scope of what an agent can do narrow and explicit, and treat revocation as a first-class operation you test, not an afterthought. Log which agent took which action under which delegation, so accountability survives after the fact. These habits pay off regardless of which registry wins, because they map to how any verifiable-identity system has to work.