Who Owns This Agent? The Internet Still Has No Identity Standard for AI Agents, and How UIID Closes the Gap

Picture a normal Tuesday in a mid-sized company. A support agent approves a refund. A research agent reads a customer contract. A coding agent opens a pull request. A finance agent pays a supplier invoice. Later, someone in the security team asks two simple questions. Which agent did this? And whose agent is it?

In most organizations today, nobody can answer both parts. The log shows a service account, an API key, or the name of the employee whose credentials were reused when the workflow was built. The agent itself does not appear anywhere, because the agent never had an identity of its own. It borrowed one.

This is the quiet problem underneath the AI agent boom. We have models that can reason, tools that can act, and protocols that let agents talk to each other. What we do not have is a settled, shared answer to the oldest question in security: who are you, and who stands behind you?

This article looks at that gap in detail. It covers what exists today, why none of it adds up to a real standard yet, and where the hardest missing piece sits: ownership. Then it shows how UIID from Linkspreed approaches the problem, and how the provisioning key makes every agent belong to a person or an organization from the first second of its life.

Part 1: Agents are everywhere, identities are not

Start with the scale. According to Palo Alto Networks’ 2026 Identity Security Landscape report, which is based on nearly 2,930 security decision-makers, machine identities now outnumber human identities 109 to 1 in the average enterprise. A year earlier the ratio was 82 to 1. A follow-up analysis of the same data puts 79 of those 109 machine identities down as AI agents rather than classic service accounts. The same analysis finds that only 37 percent of organizations can revoke an AI agent’s credentials at all.

Other numbers point the same way. A security researcher who reviewed the field in August 2026 cites Entro Security research finding that 47 percent of non-human identities have stayed unchanged for more than a year. He also cites a 2025 World Economic Forum analysis in which 51 percent of organizations said they have no clear ownership of their AI identities. Both numbers describe the same failure. An identity is created once, for a reason that made sense that day, and then nobody looks at it again.

Now look at what an agent usually runs on. A technical team at a Dutch consultancy described the typical small-business setup in September 2026. The agent runs in a workflow tool or a small custom service. It reaches the accounting system through one API key, or through one integration user that was created when the workflow was first built. In their words, the agent does not have an identity. It borrows one, and it borrows the whole of it.

Three problems follow from that.

The first is blast radius. The agent can do everything the credential can do, not only the two things the workflow needs.

The second is revocation. When something goes wrong, the only lever is to disable the credential. That stops every workflow that uses it, including the healthy ones.

The third is attribution, and it is the one that hurts most. The audit log of the accounting system records the integration user, or worse, the human whose key was reused. Six months later, someone asks whether a credit note was approved by a person or generated by a model running unattended. The log cannot say. As that team put it, nobody asks that question in advance. It is asked after an incident, when the logs are already written.

Linkspreed calls this the Ghost Agent problem. A ghost agent acts in your systems, with real permissions, but has no name, no owner on record, and no way to be switched off on its own. Software agents and automated workflows have operated in a gray area, relying on shared human credentials or static API keys. That description is accurate, and it is the starting point for everything below.

Part 2: What exists today, and why it is not a standard

It would be unfair to say nothing exists. A lot exists. The honest summary is that many good pieces exist and no agreed whole exists. Here is a tour.

OAuth and the Model Context Protocol

Most agent-to-tool connections today rely on OAuth, the standard that lets an application act on a user’s behalf without learning the user’s password. The Model Context Protocol, usually called MCP, is the most widely adopted way to connect language models to tools and data. Its authorization specification builds on OAuth 2.1. An MCP server acts as a resource server that checks access tokens. The client proves who it is through pre-registration, a client metadata document, or dynamic registration.

This area is moving fast. The November 2025 revision made client metadata documents the preferred way for a client to identify itself and demoted dynamic registration. The July 2026 revision goes further and deprecates dynamic registration in favor of client metadata documents. In June 2026 MCP also shipped an enterprise-managed authorization extension, which lets a company’s identity provider grant a user access to approved servers at login.

All of this is useful, and none of it answers the ownership question. OAuth tells a server which client is calling and which user approved it. It does not tell the world which person or organization is accountable for the agent that is calling. The OpenID Foundation made this point in its October 2025 whitepaper on identity management for agentic AI. Existing frameworks work well inside a single trust domain, for example an enterprise agent using internal tools. They fall short when agents act across organizations, act highly autonomously, work asynchronously, or serve several users at once.

The IETF drafts

The IETF, the body that writes the internet’s core standards, has a lot of agent identity work in progress. This is where the picture gets confusing.

In March 2026, engineers from Defakto Security, AWS, Zscaler and Ping Identity published a draft called AI Agent Authentication and Authorization. Later versions added authors from OpenAI and Okta. Its central idea is that agents are workloads, so they should get workload identity, the kind used for services in modern infrastructure, combined with OAuth. The draft says openly that it does not define new protocols. It describes how existing standards can be combined, and it tries to find the gaps. That version has since expired and been replaced by a document in the IETF’s WIMSE working group.

Other drafts take different approaches. An August 2026 overview from AI Stack Current points out that four separate, active Internet-Drafts use the name Agent Identity Protocol or the acronym AIP. They are not compatible with each other. They use different identity roots, token formats, delegation models, and verification rules. If someone tells you their product supports AIP, the right follow-up question is which one.

A technical review published in September 2026 by an AI engineering firm summed up the situation bluntly. As of August 2026, every AI agent identity draft at the IETF is an individual submission with no formal standing. Two of the four most-cited ones had already expired. No working group had adopted any of them. The OAuth working group’s document list contained no adopted agent identity work at all. The drafts people often cite as agent standards, identity chaining and transaction tokens, are real and adopted. But they solve cross-domain token exchange and call-chain context, and they would exist without AI.

A mid-October 2026 news analysis described the same vacuum from the market side. Six vendors are now shipping agent identity products, while the IETF has not finished the standard any of them would need. One camp builds on a draft called ID-JAG, which is still an Internet-Draft. The other camp builds protocol-neutral governance layers. Okta’s Agent SSO reached general availability in August 2026. Descope shipped a new agentic identity hub in October 2026. Both are real products built on top of a moving target.

Government and industry bodies

In February 2026 the US National Institute of Standards and Technology, through its National Cybersecurity Center of Excellence, published a concept paper called Accelerating the Adoption of Software and AI Agent Identity and Authorization. It asked how organizations use agents, what new problems agents bring, and which standards apply. More than 600 responses came in. The project’s stated end product is a practice guide with example implementations. In other words, even the national standards body is still in the stage of collecting input and building reference designs.

The OpenID Foundation whitepaper lists the open problems clearly: fragmentation of agent identity because there is no common standard, the difference between impersonating a user and acting with delegated authority, recursive delegation where agents hand work to other agents, and agents that serve many users at once. Every item on that list is an identity problem.

Vendor platforms

Microsoft’s Entra Agent ID is one of the most complete answers so far, and it is worth describing fairly. It introduces an agent identity blueprint, which is a template that holds credentials and security settings, and individual agent identities created from it. An agent identity has no credentials of its own. It relies on its blueprint to get tokens on its behalf. Every agent identity can have a sponsor, the human or group accountable for the agent, and an owner who administers it. Disabling a blueprint blocks all of its agent identities at once, which gives administrators a fast kill switch. Some agents also get an agent user account when they need to act like a digital worker with a mailbox.

This is good design, and Microsoft’s own best practice guidance recommends one identity per agent instance and an assigned sponsor and owner at creation time. The limit is scope. It lives inside a Microsoft Entra tenant. It is excellent for agents inside that world and says little about an agent that wanders into another company’s systems.

Discovery and trust layers

Several efforts try to let agents find and verify each other across the open internet.

Version 1.0 of the Agent2Agent protocol, usually called A2A, adds signed Agent Cards. An Agent Card is a small file describing what an agent can do and how to reach it. Signing it lets a client verify who published it. Analysts are careful to point out that an Agent Card is a discovery contract and not an authorization decision. A signed card protects the card’s integrity. It does not authenticate each request.

Web Bot Auth, being developed in an IETF working group, lets automated clients sign their HTTP requests with a key and publish the matching public key in a directory at a well-known address. It is already used in production at Cloudflare and others, and companies such as OpenAI and Anthropic have been named as signers. It is not yet an RFC. It proves which operator is knocking. It does not say who owns the agent behind the operator.

In June 2026 the Linux Foundation announced its intent to launch the Agent Name Service, which anchors agent identity to the existing Domain Name System. An agent gets a versioned, DNS-style name, and an identity certificate is issued after domain validation. This is a thoughtful design that reuses the internet’s most proven infrastructure.

An InfoWorld analysis from September 2026 makes an important point about all of these. They agree that agents need identities of their own. But the naming layer answers one question, which is who you are. It does not answer whether the agent is still the thing someone approved. The author’s example is a supplier who passes a security audit and then swaps the model behind the agent. The certificate stays valid and the endpoint stays up, but the thing behind it no longer resembles what anyone signed off on.

Taken together, this is the state of play. A lot of work is happening, much of it is good, and almost all of it is a draft, a single-vendor product, or a layer that solves one slice of the problem.

Part 3: The gaps nobody has closed

If you read across all of those efforts, five gaps keep showing up.

Gap one: ownership is attached late or not at all. Most systems create an identity first and add an owner as a field afterwards, if at all. Microsoft’s approach assigns a sponsor at creation time, which is the right instinct, but it is still a policy applied to a record, and it works inside one tenant. In many other setups there is no owner field to fill in.

Gap two: humans, organizations, and agents live in different identity systems. People have accounts. Companies have domains and verified properties. Agents have API keys. Nothing connects them in one model, so the question of who stands behind an agent has no natural place to be written down.

Gap three: static secrets. Most agents still authenticate with a long-lived key. Anyone who copies the key becomes the agent. The Palo Alto numbers on revocation show how rarely organizations can undo that quickly.

Gap four: cross-organization trust. Your agent calls my agent. Which of us vouches for whom? Today the answer is usually a contract and a shared secret, which is exactly what does not scale to an internet of agents.

Gap five: privacy and lock-in. If every agent identity lives in one vendor’s directory, the vendor becomes the gatekeeper of who is allowed to exist. That might be acceptable inside a company. It is a poor foundation for an open internet.

Notice that gap one is the root of the others. If you know exactly who owns an agent, you can write policy for it, revoke it, audit it, and hold someone accountable. If you do not, every other control is guesswork.

Part 4: Why ownership is the heart of the problem

There is an ongoing argument in the identity community about agent identity. One side says agents should have native identities of their own. The other side says an agent should always act as a human, with the human’s identity, because a human must stay responsible. The OpenID Foundation whitepaper frames the underlying tension as impersonation versus delegated authority.

The two sides are less opposed than they look. The real requirement is that an agent has its own identity and that this identity is permanently and verifiably tied to an accountable owner.

Think about how this works for people and companies. An employee has a badge with their own name, so the building can tell them apart from everyone else. The employee also belongs to a company, so everyone knows who is responsible if the badge is misused. A subsidiary has its own legal identity and a known parent. A car has its own registration number and a registered keeper. In each case there are two facts: this thing is distinct, and this thing belongs to someone.

Agents today usually have neither. They are not distinct, because they share a key. They do not visibly belong to anyone, because the key does not say whose it is.

A proper agent identity needs four properties together. It is unique to the agent. It is verifiable by others without calling the owner. It carries a provable link to an owner, which can be a person or an organization. And it can be revoked without hurting anything else. Most existing efforts deliver one or two of these. The interesting question is how to deliver all four from the start.

Part 5: UIID in a nutshell

UIID, short for Universal Integrated Identity, is Linkspreed’s identity protocol. It began as a way to give people a digital passport that they control instead of one that a platform controls. If you want the product itself, start at https://uiid.me.

A few ideas from that human-first design matter for what follows.

The first is local-first creation. According to Linkspreed’s public descriptions, UIID creates cryptographically secure identities directly on the user’s device. It uses device biometrics and zero-knowledge proofs, which are techniques that let someone prove a statement, such as being over a certain age, without revealing the underlying data. Keys are secured in hardware using WebAuthn, the same standard that powers passkeys.

The second is the split between a Core ID and Aliases. A person has one master Core ID and many context-specific Aliases. Outside services see an Alias, so they cannot easily correlate your behavior across unrelated sites.

The third is that identity is decoupled from any single platform. The user is meant to be the administrator of their own identity, instead of a platform account that the platform can suspend.

Those are choices that make sense for people. What makes UIID relevant to the agent problem is what Linkspreed did with version 2.8, announced on June 16, 2026.

Part 6: UIID 2.8 and the end of the ghost agent

Version 2.8 widened UIID from a human-only framework into what Linkspreed calls a multi-entity system. It defines six entity types, each with its own enrollment flow: Human Individual, Organization, AI Agent, Hardware Node, Digital Service, and Collective, which covers multi-signature groups and shared governance bodies.

That list is the first big step. In UIID, a person, a company and an agent are all first-class identities in the same system. That solves gap two from Part 3. The thing that owns and the thing that is owned live in one model, so a link between them can be written down in a way that anyone can check.

Version 2.8 then adds four innovations that matter for agents.

Autonomous agent birth. Using a machine-readable skill.md protocol, an AI agent can register its own UIID account autonomously. The skill.md format is the same simple idea that many coding agents already use: a plain Markdown file that tells an agent how to do something. Here the file tells an agent how to get an identity. UIID also supports OpenClaw-compatible Markdown on public profiles, so an agent can describe what it can do and negotiate handshakes with other nodes without a human writing an integration.

The Agent Factory. This is a control center for individuals and organizations. From this dashboard, a creator can issue multi-use provisioning tokens, start new machine processes, and watch fleet activity, resource consumption and trust scores in real time. The name makes the idea clear. Agents are not scattered, anonymous things. They come out of a factory that belongs to someone, and that someone can see all of them.

Zero-trust provisioning. Version 2.8 replaces static secrets and long-lived access keys with dynamic, single-use or multi-use authorization tokens. Linkspreed’s argument is that an intercepted token cannot be turned into a weapon against the broader fleet. That targets gap three.

A classification framework. Beyond the six entity types, the framework gives each type its own enrollment flow, so that an agent is enrolled as an agent, an organization as an organization, and so on.

The piece that ties these together is the provisioning key. It is the mechanism that makes an agent belong to someone.

Part 7: The provisioning key, step by step

In the 2.8 release notes, Linkspreed describes these as provisioning tokens. This article calls them provisioning keys, because that is how most people think about them: a key that opens the door to creating an identity. The key idea is simple and powerful. An agent does not get to decide who owns it. The owner decides, by handing over a key.

Here is the flow in plain words.

First, an owner exists. The owner is either a person with a UIID or an organization with a UIID. Both are normal UIID identities. The person is a Human Individual and the company is an Organization.

Second, the owner opens the Agent Factory and issues a provisioning key. The key can be single-use, for one specific agent, or multi-use, for a group of agents that belong together, such as every instance of one kind of support agent.

Third, the key is given to the agent or the system that runs it, together with the skill.md file that tells the agent how to register.

Fourth, the agent follows the instructions in skill.md and registers its own UIID account. This is the autonomous agent birth step. It presents the provisioning key as part of the registration.

Fifth, the new identity is created as an AI Agent entity, and it is linked to the owner who issued the key. From this moment the agent has a name that is its own, and the world can see whom it belongs to.

Sixth, the new agent shows up in the owner’s fleet view in the Agent Factory, with its activity, its resource consumption, and a trust score.

Notice what is different from the usual way of doing things.

With a classic API key, the key is both the identity and the permission. Whoever holds it is the agent. With a provisioning key, the key’s job is the introduction. It starts the life of a new identity and states who that identity belongs to. After that, the agent is its own entity with its own cryptographic identity root.

With a classic setup, ownership is documentation. It lives in a wiki page, a ticket, or the memory of the person who set it up. With a provisioning key, ownership is part of how the identity is created. An agent cannot be born without an owner, because the key that lets it be born comes from an owner.

With a classic setup, the agent and its owner are linked by trust and habit. With a provisioning key, they are linked by something that can be verified.

That last point deserves a moment, because it is what makes the design different from a sponsor field. A sponsor field is a note that someone made. A provisioning relationship is a fact about how the identity came into existence. A relying party, for example a service your agent wants to call, can ask who this agent belongs to and get an answer that is not a claim made by the agent itself.

Part 8: Agents that belong to a person

Take Mara, a freelance consultant. She runs three agents. One drafts her invoices, one watches her inbox for client requests, and one prepares research briefs. In the old setup, all three use her own login or a shared key, so everything they do looks like her.

In UIID, Mara is a Human Individual. Through the Agent Factory she issues a provisioning key for each agent, or one multi-use key if she wants them grouped. Each agent registers and becomes its own UIID identity, linked to Mara.

What changes in her daily life?

If a client asks who sent an email, there is a clear answer. It was Mara’s research agent, acting for Mara, not Mara herself. That sounds like a small detail. It matters a lot for trust and for disputes. Mara can show that she is not hiding behind a bot, and she can show that the bot is not pretending to be her.

If one agent starts to behave oddly, Mara can deal with that one agent. The other two keep working, because they never shared an identity.

Mara’s own Core ID stays protected. Her agents do not need to hold her master identity to do their jobs. That fits the UIID design in which outside services deal with context-specific identities instead of the master identity.

Part 9: Agents that belong to an organization

The organizational case is where the design earns its keep.

Take Northwind Logistics, a company with a few hundred employees and, in a year, a few hundred agents. Northwind has an Organization UIID, which Linkspreed describes as made for formal legal entities, corporations, non-profits and institutional bodies. The company’s administrators use the Agent Factory to issue provisioning keys. A multi-use key can cover a whole class of agents, for instance every customs-document agent. Individual agents are born from it and linked to the organization.

Here is why that matters.

The owner is the organization, not an employee. In many setups, an agent’s identity quietly hangs on the person who built it. When that person leaves, the agent keeps running on credentials that nobody feels responsible for. That is exactly the pattern behind the surveys about missing ownership. With an Organization UIID as the owner, the agent’s accountability does not depend on any one employee’s contract.

The fleet is visible in one place. The Agent Factory gives the organization a view of every agent it has created, with activity, resource consumption and trust scores. The shadow agent problem that Microsoft’s governance guidance describes, where an agent works with data nobody approved and appears in no inventory, becomes much harder to create when agents can only be born through a key issued by the organization. An agent without a provisioning relationship does not belong to the fleet. It is, by definition, unowned, and that is a signal in itself.

The organization can issue keys in a controlled way. Because keys are dynamic and can be single-use or multi-use, the company decides how many agents a key can create. A key for ten agents is not a key for unlimited agents.

External parties can see who is behind an agent. When a Northwind agent contacts a supplier’s system, the supplier can tell that this agent belongs to Northwind Logistics, as a verified organization identity, instead of trusting a name in a header.

Notice how this lines up with what Microsoft recommends inside its own world: every agent has a unique identity, every agent has an accountable owner from creation, and the fleet can be inspected and switched off. The difference is that UIID aims to make this a property of the identity itself, not a feature of one vendor’s directory.

Part 10: Trust between agents

So far we have looked at the owner’s view. The other half of the story is what an agent sees when it meets another agent.

Imagine Northwind’s customs agent contacts a carrier’s scheduling agent. Today, the two systems usually rely on a pre-agreed secret or a human-set integration. That does not scale. Nobody can pre-agree secrets between millions of agents.

The version 2.8 design points to a different pattern. Each agent has a public profile. That profile can use Markdown to describe the agent’s operational capabilities, in a form that other agents, and people, can read. When two agents meet, they can read each other’s profiles and negotiate a handshake.

Because each agent is a UIID identity linked to an owner, a handshake can include the question that matters most: who is behind you? A scheduling agent can decide that it talks to agents owned by verified organizations, and refuse agents with no verifiable owner. A person can decide that their personal agent only works with agents owned by organizations they know.

The trust score in the Agent Factory is a further input. Linkspreed describes owners monitoring trust scores for their fleet in real time. Whatever the details of the scoring, the design principle is sound. Identity says who an agent is, and a score gives a running view of how it has behaved. They are different things, and a good system keeps them separate but connected.

Part 11: How this answers the three problems from Part 1

Go back to the three problems with borrowed credentials.

Blast radius. When each agent has its own identity, permissions can be given to that identity alone. An agent that only needs to read invoices can be allowed to read invoices. If it is compromised, the damage stops at its own permissions, not at the permissions of whoever’s key it was using.

Revocation. When agents do not share a credential, one agent can be shut down without stopping the rest. And because the owner can see the fleet, the owner can find the right agent quickly. The other revocation question, what to do about keys that were handed out, is addressed by the dynamic, single-use or multi-use design. Linkspreed’s stated goal is that an intercepted token cannot be weaponized against the wider fleet.

Attribution. Because the identity of an agent is distinct and tied to an owner, an audit log can name the agent and the owner. The question from the beginning, which agent did this and whose is it, has a two-part answer again.

Part 12: How UIID fits with the standards, not against them

A fair question is whether UIID competes with MCP, A2A, Web Bot Auth, the Agent Name Service, and the IETF work. It is better understood as a layer that those pieces can sit on top of. The comparison below is a design view, not a statement about announced integrations.

MCP and OAuth need a way for a client to identify itself and for a server to know whom it is dealing with. A UIID agent identity is a natural candidate for the thing that the client is. The server still does its job of checking tokens and scopes. What the identity adds is the answer to who owns this client.

A2A needs to know whether an Agent Card was published by who it claims. Signed Agent Cards help verify that. An agent identity with a clear owner gives the signature a meaning beyond a key: a key that belongs to an agent that belongs to a known organization.

Web Bot Auth proves which operator is signing requests. A UIID agent identity could be the thing behind that operator key, which would link a signed request to an accountable owner.

The Agent Name Service anchors names in DNS. UIID anchors identity in the owner relationship and in local-first cryptography. These are complementary angles on the same need.

The IETF work on workload identity treats an agent as a workload. UIID’s AI Agent entity type and its Hardware Node and Digital Service types cover a similar range of non-human things. Both approaches start from the idea that machine identities need to be first-class.

The practical message is that nothing in this ecosystem has to be thrown away. What is missing is a shared root that connects the agent, its owner, and the protocols it speaks. UIID proposes to be that root.

Part 13: What UIID does not claim to solve

A deep dive that only lists strengths is not a deep dive. Here are the limits, stated plainly.

Identity is not behavior. The InfoWorld analysis makes the case well: a valid identity proves very little if the agent can change its behavior without anyone noticing. UIID tells you who an agent is and whom it belongs to. It does not, by itself, prove that the model behind the agent is the same one that was approved last month. Trust scores and fleet monitoring in the Agent Factory help here, because they give owners a running view. But runtime integrity, such as proving what code and model are running, is a hard problem that the whole industry is still working on. Even the Linux Foundation’s naming layer lists it as future work.

Identity is not authorization. Knowing who an agent is and who owns it does not decide what the agent may do. Policies, scopes, and approvals still have to be written. A strong identity makes those policies enforceable, because there is a stable thing to attach them to. It does not write them.

Identity is not law. Questions of liability, contracts and regulation sit above any technical system. An ownership link makes accountability possible and visible. It does not decide how courts or regulators will treat it.

A standard is not the same as a product. UIID is Linkspreed’s protocol. The wider market has not settled on a single standard, as Part 2 showed. A fair reading is that UIID offers a working, opinionated implementation of the missing ownership layer while the formal standards catch up. Organizations should treat their adoption like any other architectural decision: look at what depends on what, and keep options open.

Stating these limits makes the case stronger, not weaker. The claim is narrow and useful: every agent gets its own identity, every identity has a provable owner from birth, and credentials are dynamic instead of static. That claim is exactly the one that most deployments today cannot make.

Part 14: What you can do this week

You do not need to wait for a standard to improve your situation. Whether or not you use UIID, these steps help.

Count your agents. The surveys in Part 1 suggest that the real number is usually several times the number on the official list. Look at service accounts, API keys, automation tools, and every place an employee has connected an AI tool to company data.

Write down an owner for each one. A person, a team, or an organization. If you cannot name an owner, that is the finding.

Stop sharing credentials between agents. One agent, one identity. It is the single biggest improvement in blast radius, revocation and attribution.

Replace long-lived keys with short-lived or dynamic ones wherever you can. Treat every static key as a liability with a countdown.

Decide in advance how you will switch off one agent without breaking the others. If the answer is that you cannot, you have just found your first project.

Make ownership part of creation, not an afterthought. This is the principle behind the provisioning key. An agent that cannot be created without an owner is an agent that always has one.

If you want to try the UIID approach, the starting point is an identity for the owner, either a person or an organization, at https://uiid.me. From there, the Agent Factory is where provisioning keys are issued and where the fleet is visible.

Part 15: Where this is heading

The internet already went through a version of this story. Websites needed a way to prove who they were, and the answer was certificates tied to domain names. People needed a way to sign in without a separate password for every site, and the answer was single sign-on and, later, passkeys. Businesses needed verifiable properties, and the answer was verified listings and extended validation. Each of those took years of messy competition before a workable shared answer emerged.

Agents are at the start of that road. The pace is much faster, because agents are already acting, spending money and touching sensitive data. The messy phase is visible in the numbers: four incompatible drafts sharing one name, vendors shipping products against drafts that expire in a few months, national standards bodies still collecting feedback.

Linkspreed’s bet with UIID is that the winning shape will have three features. Agents will have identities of their own, not borrowed ones. Those identities will be tied to accountable owners at birth, not later. And the credentials that bring them to life will be dynamic and controlled by the owner, not static secrets that sit in a configuration file for years.

The provisioning key is the small mechanism that carries that bet. It is how a person or an organization says: this agent is mine, I created it, and I can see it. It is how the agent gets a name that is its own. And it is how the rest of the internet can finally answer the question that started this article, which agent did this, and whose is it.

In a world where machine identities already outnumber human ones more than a hundred to one, that question is worth answering before the next incident, not after. Learn more about UIID and the Agent Factory at https://uiid.me.