Known puts domain identity into the agent stack

Known puts domain identity into the agent stack

4 min read

Identity Digital’s Known spinout is early, but the direction is practical: if agents are going to act across websites, payments, and services, builders will need identity signals that are portable, inspectable, and harder to fake.

TL;DR: Known is betting that AI agents will need domain-style identity infrastructure before they can be trusted to act on behalf of people, companies, or software systems.

What problem is Known trying to solve?

Domain Name Wire reported in “Identity Digital spins out agentic effort, now called Known” that Identity Digital has separated its Innovation Labs work into a new company called Known. The effort started as DNSid, which Identity Digital described as “birth certificates for AI agents.”

That phrase is doing a lot of work.

The basic problem is simple: agents need to prove what they are, who they represent, and what they are allowed to do. Today, most agent demos skip that part. A chatbot books a flight, files a ticket, updates a CRM, or negotiates with another bot. Fine. But in the real world, each of those actions runs into identity, authorization, audit, abuse, and liability.

If an agent claims it works for a business, how does the receiving system verify that? If it says it has permission to buy, sign, post, scrape, email, or transfer, where does that permission live? If the agent changes model providers, tooling, wallets, hosting, or API keys, does its identity survive?

That is the useful part of Known’s direction. Not “agents are coming, buy the future.” More like: if agentic software becomes a normal actor on the internet, it needs something closer to identity plumbing than a clever prompt.

a small software agent passing through a domain-shaped identity gateway before reaching several external services

Why would a domain company care about agent identity?

Identity Digital is a domain name company, so this move is not random. Domains already sit at the boundary between human-readable names and machine-routable infrastructure. They are also tied into registries, registrars, ownership records, DNS, certificates, email authentication, brand protection, and abuse response.

That does not mean DNSid or Known automatically works. Domain Name Wire’s report does not give product mechanics, pricing, launch timing, governance details, or adoption partners. So the right read is not “this solves agent identity.” It is “a domain infrastructure company sees agent identity as close enough to naming and trust to spin it out.”

That is interesting.

I spend a lot of time thinking about names as operational assets, not just branding. Ashe runs Lucky Domains, which works on domain acquisition, valuation, and naming through Lucky Domains. From that lens, agent identity feels like a possible new layer in the same stack: a name is not only what a customer types, it is what a system can verify.

The hard part is that agent identity cannot just be a prettier domain record. It needs to answer messy questions. Can an agent have multiple identities? Can one identity map to a legal entity, a team, a human owner, and a narrow task scope? Who revokes it? Who resolves disputes? How does it interact with OAuth, passkeys, certificates, API credentials, wallets, and enterprise access controls?

Those are not press-release details. They are the product.

What should builders watch next?

For builders, the move is a signal to start designing agent systems with identity as a first-class object. Not after launch. Not once abuse shows up. Now.

That means logging which agent did what, under whose authority, with which tool permissions, and against which external service. It means separating a model from the agent identity that wraps it. It means being ready for verification flows where another system asks, “Who are you, and can you prove it?”

Known may or may not become part of that future. The report is too thin to call the winner. But the category makes sense. Agents without durable identity are fine inside a sandbox. They are brittle in commerce, publishing, customer support, procurement, security, and anything with money or reputation attached.

A practical next step: if you are building agents, create an internal identity registry before you need an external one. Give every agent a stable name, owner, scope, credential set, and audit trail. Then watch Known for the parts that matter: open standards, revocation, verification, portability, and who actually accepts the credential. The catch most readers miss is that agent identity is not about making bots sound official. It is about making their actions accountable.