Vint Cerf is working on a plan to unleash AI agents on the open internet.

AI agents are moving from software features inside one company’s product to potential participants in the open internet. That creates a problem the web’s existing identity layer was not designed to answer: who is behind an autonomous agent, what authority does it have, and who answers for what it does?

TechCrunch reports that Vint Cerf is working with Innovation Labs on this problem. Cerf, one of the architects of the protocols that let independent networks interoperate, has joined the organization’s advisory effort after leaving Google. Innovation Labs is proposing DNSid, an open architecture that would anchor an agent’s identity to an existing internet domain and use cryptographic proofs to make that relationship verifiable.

Definition: DNSid is a proposed identity anchor for AI agents, not a finished standard or an autonomous-agent marketplace.

Example: A purchasing agent acting for a company could present an identity that resolves to the company’s domain, allowing another service to check who operates it before exchanging data or accepting a request.

Key takeaway: The open-agent internet needs more than capable models; it needs shared ways to identify, authorize and hold them accountable.

Business impact: A durable identity layer could make cross-company agent interactions easier to audit, but identity alone cannot establish that an agent is safe, competent or permitted to perform a particular action.

The internet was built for independent systems, not autonomous actors

The original internet connected independent networks through shared protocols. Those protocols did not require one company to own every application or control every route. Interoperability made it possible for separate systems to communicate without first becoming one organization.

AI agents create a different kind of participant. A domain name identifies a location or organizational namespace; an agent can interpret instructions, call tools, exchange data, negotiate with another system and take actions on someone’s behalf. It may also be copied, updated, delegated, compromised or replaced while continuing to appear under a familiar service name.

That activity makes identity a foundation question rather than a profile-page feature. Before an agent receives access to a data source or accepts a request from another agent, the other side may need to know:

• which organization operates it;
• whether its software identity is current and authentic;
• what authority was delegated to it;
• which human or organization is accountable for the result;
• whether the requested action is within its permitted scope.

Existing authentication methods can solve parts of this problem. The gap is the shared, durable layer that lets different organizations and agent systems make those checks across boundaries.

DNSid uses the web’s existing coordination layer

Innovation Labs’ DNSid proposal takes a deliberately familiar route: connect an agent’s identity to a domain that an organization already controls. The organization’s domain becomes an accountability anchor, while cryptographic proofs help demonstrate that the identity record was created and maintained by the domain owner.

The company says the proposal builds on existing DNS infrastructure rather than requiring a new global namespace or a proprietary identity silo. In its announcement about Cerf joining Innovation Labs, the organization describes DNSid as an Internet-Draft for durable AI-agent identity built on existing domain infrastructure.

The attraction is straightforward. DNS already provides a globally understood relationship between a domain and its operator. An agent identity layer that builds on that relationship may be easier to explain and deploy than a new registry controlled by a single AI company.

The limitation is just as important: control of a domain does not automatically establish that every agent associated with it is trustworthy. A domain can host many services, delegate authority to vendors, suffer a security breach or change ownership. DNSid can help establish an accountable operator; it cannot replace the rest of the security and governance stack.

Identity is not authorization

The easiest mistake in this conversation is to treat a verified identity as a permission slip. They are different questions.

An agent might have a valid identity and still be prompt-injected, over-privileged, misconfigured or wrong. An organization might be identifiable while disputing responsibility for an agent’s action. A receiving system therefore needs to combine identity with authentication, authorization, policy enforcement, monitoring and incident response.

For builders, the practical principle is simple: verify who is calling before deciding what it may do.

Cerf’s role is about standards, not a finished product

Cerf’s involvement gives the proposal historical and architectural weight, but it does not make DNSid the internet’s chosen standard. The TechCrunch report describes a field with multiple approaches under consideration and a familiar standards challenge: a protocol wins through usefulness and interoperability, not only through the prestige of its supporters.

That distinction matters because agent identity has many stakeholders. Domain registries understand naming. Cloud providers control deployment environments. Agent developers control software credentials. Enterprises control permissions and data. Regulators care about accountability. Users care whether they can tell when they are delegating a consequential task to a machine.

A workable standard must fit those interests without giving one provider a private trust monopoly. Innovation Labs says its proposal is not intended to own the registration data or become a broader AI platform. That positioning is part of the adoption argument, not evidence that adoption is assured.

Cerf’s comparison to TCP/IP points to the same lesson. The protocols that made the internet broadly useful succeeded because independent systems could use them together. An agent identity standard will face the same test: can a company’s agent discover, authenticate and interact with another company’s agent without joining the same vendor ecosystem?

The open-agent internet needs a discovery layer too

Identity answers “who is this?” but an agent ecosystem also needs to answer “what can this agent do?” and “how should I interact with it?”

A practical interaction may require a machine-readable description of an agent’s capabilities, supported protocols, authentication method, rate limits, data requirements, human escalation path and terms of service. Identity lets a receiving system attach those claims to an accountable subject. It does not make the claims true.

That means the eventual architecture may look like a stack:

1. Identity: who operates the agent?
2. Discovery: where can its capability description be found?
3. Authentication: can the message be tied to the claimed agent?
4. Authorization: what is the agent allowed to access or change?
5. Execution: can the action be performed safely and reversibly?
6. Audit: can people reconstruct what happened and why?

An AI agent is already a system that uses tools and feedback to pursue a goal. Once that agent crosses an organizational boundary, each layer becomes a dependency. A protocol that handles only the first layer is useful, but it is not the whole agent internet.

Why domain-anchored identity is attractive — and controversial

A domain-based anchor has several practical advantages:

• organizations already understand domain ownership;
• DNS is distributed rather than operated by one AI vendor;
• domain-based identity can map an agent to an existing operator;
• cryptographic proofs can make changes and registrations auditable;
• independent services can verify a relationship without asking the same platform for permission.

It also raises hard questions:

• Does one domain represent a company, a subsidiary, a contractor or a temporary project?
• How quickly can a revoked or compromised agent identity be detected?
• What happens when a domain changes hands?
• Can one operator create thousands of identities without meaningful accountability?
• How are agents operated by individuals, open-source communities or decentralized groups represented?
• What evidence does a receiving service need before trusting a high-impact action?

These are not reasons to reject the idea. They are the specification’s real work. A system can be cryptographically elegant and still fail operationally if revocation is slow, metadata is vague, or organizations do not maintain the records accurately.

The incentive problem is bigger than the technical problem

For an identity protocol to work on the open internet, both sides need a reason to use it. Agent operators must register and maintain identities. Receiving services must check them. Users must understand the result. Platforms must agree not to turn a supposedly open standard into a closed access gate.

There is also a privacy tension. An identity that is too weak provides little accountability. An identity that exposes too much can reveal a user’s organization, workflow, business relationship or personal information. The system needs a durable accountability trail without making every agent interaction permanently public.

Interoperability will therefore be judged at the edges, not only in the protocol document. Can a small company’s agent interact with a large company’s agent? Can a user revoke an agent’s access without deleting the organization’s identity? Can a security team detect an impersonating agent? Can a platform explain the identity check in language a nontechnical person understands?

What companies should do before agents roam the web

The open internet is not here yet, and DNSid is still a proposal. Companies do not need to wait for a final standard to prepare for the identity problem.

Inventory agents as production identities

Create a record for every deployed agent, including its owner, purpose, tools, data access, model, update path and human escalation contact. If the security team cannot name the operator, the agent is already an accountability gap.

Separate identity from authority

Give agents short-lived, least-privilege credentials where possible. An agent’s stable service identity should not automatically grant it broad access to databases, money movement, code repositories or customer records.

Log delegation and actions

Record who authorized the agent, which policy applied, which tools it called, what data it used, and what outcome followed. Future identity standards can strengthen these logs, but they cannot reconstruct events that were never recorded.

Test the failure path

Revoke an agent. Rotate its keys. Change its operator. Simulate a compromised tool. Ask whether another system can distinguish the old identity from the current one and whether a person knows what to do next.

Track standards without betting the architecture

Follow DNSid and competing proposals, but keep internal interfaces modular. A company that hard-codes one draft into every workflow will have difficulty adapting when interoperability requirements change.

The real promise is accountable interoperability

Vint Cerf’s involvement brings attention to a problem that is easy to underestimate. People can ignore a badly designed web service; autonomous agents may transact, modify records, expose data and coordinate with other software at machine speed.

An identity layer could make that world more legible. It could give organizations a durable subject to authenticate, authorize, monitor and hold accountable. But the open-agent internet will not be created by identity alone, and DNSid is not yet an adopted standard.

The important question is not whether every future agent will get a digital passport. It is whether independent systems can recognize one another, establish authority, limit action and produce an audit trail without surrendering the internet’s interoperability to one private platform.

That is the architectural test. Cerf’s plan is an attempt to start it before autonomous agents make the missing layer impossible to ignore.