The Open Web Just Gave AI Agents Verifiable Identity

The Linux Foundation launched Agent Name Service on November 10, an open standard that lets an AI agent bind a versioned identity to a domain, certificate and auditable transparency record. The commercial consequence is that a supplier, payments gateway or customer platform can verify which agent is calling before it exchanges data or accepts an action. Businesses must now decide where verified agent identity becomes mandatory—and keep it separate from permission, reputation and behavioral trust.

The standard has launched; the specifications are still drafts

Agent Name Service, or ANS, has launched as a Linux Foundation project with support from 11 organizations, including Cisco, Cloudflare, DigiCert, GoDaddy, Salesforce and OWASP. Its seven-layer specification covers domain control, registration, versioned naming, DNS publication, transparency records, integrity monitoring and authentication.

An operator proves control of a domain, registers an agent host and software version, publishes DNS records, and binds the registration to certificate material. A transparency log records lifecycle events so another system can check identity, status and possession of the associated private key.

Reference implementations and early integrations exist. The Linux Foundation says AGNTCY’s Agent Directory Service supports ANS verification, while ANS Finder has passed Agentic Resource Discovery conformance tests. But the specifications remain drafts under active development. This is launched infrastructure with early adoption—not a standard proven across the internet.

Identity can become the first condition of access

Today, an agent often reaches a tool or partner API with a hostname and a token. That may establish what the token can access, but it does not necessarily prove which organization controls the calling agent, which software release is running or whether that registration has been revoked.

ANS adds those missing coordinates. A business could require a procurement, service or campaign agent to present a domain-anchored identity before it receives a product feed, customer record or workflow permission. Versioned names let a verifier distinguish one release from another.

For marketing and commerce, the change is the possibility that verified identity becomes a prerequisite for higher-trust channels. A marketplace could admit registered seller agents to richer inventory data. A brand could accept requests from verified partners while limiting unknown callers. Services could reject an impersonator before it reaches pricing, loyalty or account systems.

This shifts agent identity from a technical label into a distribution credential. The agent that can be discovered and authenticated may gain access to opportunities an anonymous agent cannot reach.

Domain ownership could become agent-channel equity

ANS is designed to avoid a single proprietary directory. It builds on DNS, public-key certificates and auditable logs—the same broad infrastructure model that allowed websites from different providers to identify themselves across the open web.

The domain could anchor not only web pages and email, but also a portfolio of named agents. A company could publish separate identities for support, sales, purchasing or analysis, then register each version as a distinct event. Partners could pin access to an approved identity and release.

A verified identity could remain meaningful across directories, gateways and protocols when a business changes platforms. Early interoperability is promising, but broad cross-vendor acceptance remains unproven.

For OrionPilot, the strategic lesson is that useful automation needs an explicit trust boundary before more autonomy. A marketing agent should be identifiable, connected to an owner and limited to its permitted actions. Identity can strengthen that model, but it cannot replace approvals, budget controls or outcome evidence.

Authentication is not authorization—or character

ANS is unusually clear about its limits. Its documentation says the system verifies domain-anchored identity, registration status and key possession. It does not authorize an action, delegate a user’s permissions, attest to the code executing on a remote machine or guarantee an agent’s behavior.

A verified agent can still be poorly designed, compromised or authorized to do too much. A familiar domain may create misplaced confidence if people assume authentication means safety. Businesses still need least-privilege permissions, transaction limits, approval thresholds and monitoring.

The draft specification addresses impersonation, DNS spoofing, registration-authority compromise, version rollback and log rewriting. Success depends on checking signatures, freshness, revocation and key possession—and deciding what happens when a check fails.

What businesses should watch next

First, watch interoperability: whether one implementation’s agents can be authenticated by unrelated gateways and directories. Conformance tests should expand beyond project participants.

Second, measure registration time, certificate rotation, revocation speed, false rejections and the cost of checking transparency records at transaction scale.

Third, watch market behavior. If marketplaces or enterprise gateways require verifiable identity, ANS could become infrastructure for commercial access. If adoption remains voluntary, it may stay a security layer without changing customer behavior.

The breakthrough is not that an agent receives a name. It is that another system can verify the organization, release and cryptographic evidence behind that name before deciding what the agent may do. The next business advantage will belong to companies that make that proof routine without mistaking identity for trust.