What is the Agent Name Service (ANS)? How it works and why it matters

Key takeaways:

• The Agent Name Service (ANS) gives AI agents a verifiable identity. This helps people and systems check who or what an agent represents before sharing information or accepting its requests.
• ANS supports secure AI agent discovery by adding identity checks. However, verifying an agent’s identity does not guarantee that its answers are correct or that every action it takes is safe.
• ANS is an identity framework, not an app store. Directories and marketplaces can use it to help users find and check agents, but ANS itself is not a place to download them.

An AI agent asks for your customer’s contact details to book an appointment. It says it works for the salon your customer wants to visit. How do you know that claim is real?

As AI agents do more across websites, apps, and business tools, businesses need a way to check which agents they are dealing with. A familiar name or logo is not enough.

The Agent Name Service offers a shared way to check agent identity using domain names and digital credentials. These credentials give other systems evidence they can verify before connecting.

For small business owners, this could help answer a practical question: “Is this the agent I expect to work with?”

This guide explains what ANS is, why it matters for secure AI agent discovery, and how it works. It also looks at possible small business uses and where you may find agents whose identities have been verified.

What is the Agent Name Service (ANS)?

Agent Name Service (ANS) is an emerging open standard for AI agent identity, designed to give AI agents a verifiable identity anchored to a domain name. It helps other systems check that an agent is connected to the domain it claims to represent, what its capabilities and permissions are, and what its lifecycle looks like. Instead of accepting an agent’s name at face value, the system checks its digital credentials and registration information.

ANS builds on DNS addressing and uses DNS-inspired naming conventions, which means organizing AI agent names in a structured way, similar to website addresses. DNS helps computers find online resources using domain names. ANS uses a related naming approach to help systems find AI agents and check their identities.

For example, a booking agent might claim to work for a local salon. But using the salon’s name alone doesn’t prove it. Linking the agent’s identity to the salon’s domain gives other systems a way to check that connection.

Depending on the service, agent records may also include the operator, software version, connection details, and registration history. However, these details do not automatically prove that the agent performs well or should have access to your business data.

What does “open standard” mean?

When we say ANS is an “open standard,” it means the rules for identifying and verifying AI agents are publicly available. Different organizations can use those rules without depending on one company’s private identity system.

Developers, businesses, security researchers, and infrastructure providers can contribute to the standard’s development. Verification may still involve registries and certificate providers, but the shared approach allows different organizations to build services that follow the same rules.

Where did the ANS come from?

ANS was developed under the OWASP GenAI Security Project–Agentic Security Initiative. It introduced a comprehensive framework to help AI agents find one another, verify their identities, and connect across different systems.

Ken Huang, Vineeth Sai Narajala, Idan Habler, and Akram Sheriff submitted their initial ANS research paper on May 15, 2025. The paper proposed shared infrastructure for secure agent discovery and interoperability—the ability of different systems to work together. Its goal was to support future interoperable agent ecosystems, where agents from different providers could identify and communicate with one another.

On June 23, 2026, the Linux Foundation announced its intent to launch ANS under neutral, community-led stewardship. It invited businesses, developers, infrastructure providers, and security researchers to contribute, supporting shared development rather than control by one vendor.

ANS is still developing. Its original IETF submission was an experimental draft, not an approved IETF standard. The features available today depend on the service implementing it.

Why is the ANS important for AI agent discovery?

ANS matters because finding an agent is different from checking who it represents. A listing may describe what an agent can do, but identity verification helps a system check whether the agent is connected to the business or service it claims to represent.

This becomes more important as autonomous agents take on tasks. An autonomous agent can carry out some actions without a person approving every step. Those actions might involve customer information, bookings, orders, or requests to other agents.

Consider these possible situations:

• A fake scheduling agent asks for customer details. It claims to represent a salon, but your system hasn’t checked its identity. Sharing those details could expose customers’ names, phone numbers, or email addresses to someone outside the business.
• A fraudulent purchasing agent sends an order request. It claims to buy products on your business’s behalf, but the supplier hasn’t verified that connection. Accepting the request could lead to unauthorized orders, lost stock, or payment disputes.
• An agent asks for more access than it needs. A real support agent might only need to view an order’s status, yet request access to download all customer records or change orders. Granting that access could expose private information or allow unwanted changes.
• Someone changes an agent’s stored connection details. Your system could be sent to an attacker’s address instead of the intended agent. Information meant for a legitimate service could then reach the wrong person.

These examples show why a name and a list of agent capabilities are not enough for secure discovery.

Research also shows broader concerns about agent security. In the December 2025 survey behind Gravitee’s State of AI Agent Security 2026 report, 88% of surveyed organizations reported confirmed or suspected AI agent security or privacy incidents in the previous year. Reported examples included unauthorized database access and attempts to send sensitive information outside an organization.

These findings show why businesses need to examine how agent security problems can happen and where safeguards are needed. ANS addresses part of that challenge by supporting identity checks, though it cannot prevent every type of incident.

To examine those risks, OWASP’s ANS framework uses the MAESTRO seven-layer framework for comprehensive threat analysis—a review of security risks across different parts of an AI system. It considers threats such as:

• Agent impersonation: An agent pretends to be another agent.
• Registry poisoning: Someone tampers with stored agent information.
• Denial of service (DoS): An attacker overwhelms a service so others cannot use it.

ANS can support identity checks before an interaction begins. Your business still needs to decide what an agent may access and which actions it may take.

Knowing who an agent represents is one part of protecting your business. Setting permissions and reviewing important actions are separate parts.

How does the Agent Name Service work?

ANS connects an agent’s name with registration information and digital credentials. A system that supports ANS can look up that information and check the agent’s identity before connecting.

The exact process varies by service, but the basic flow looks like this:

1. The operator registers the agent: The person or organization running the agent submits information such as its name, version, capabilities, and connection address. It may also submit a certificate signing request, which is a request for a digital certificate.
2. The registration service checks the request: A registration authority checks whether the request meets its rules. In a domain-based service, domain validation checks that the applicant controls the domain being used for the agent.
3. Digital certificates support identity checks: A certificate connects an identity with a cryptographic key. Think of the key as part of a digital proof that the agent can present when another system checks its identity.
4. Another system looks up and verifies the agent: It retrieves the agent records and checks the relevant credentials. The records can also provide an endpoint, which is the online address where the agent can be reached.
5. The records and credentials are kept current: Certificates expire and need renewal. Credentials may also be revoked, meaning they should no longer be accepted. For example, if a key has been compromised.

Together, these stages support lifecycle management: managing an agent’s registration and credentials from creation through renewal or removal.

For most small business owners, these checks would happen inside a supporting platform or tool. You would not usually need to inspect certificates yourself. Instead, ask what the service verifies and whether it checks that the information is still current.

The naming approach builds on familiar internet concepts. Our guide to hostnames versus domain names explains how names identify online resources.

The roles of Public Key Infrastructure (PKI), JSON schemas, and the protocol adapter layer in ANS

The original ANS framework uses three technologies to help systems check identity and exchange agent information.

PKI helps verify the identity

Public Key Infrastructure (PKI) is a system for managing digital certificates and cryptographic keys. ANS uses it to help systems check an agent’s identity before connecting.

Think of a certificate as a digital ID issued by a certificate authority. Rather than taking the agent’s word for who it is, a system can check that certificate and ask the agent to prove it holds the matching key. This is similar to checking someone’s ID and making sure it belongs to the person presenting it.

These checks use cryptographic verification, which means checking digital evidence through mathematical methods. Digital signatures use related methods to help systems check who signed information and whether it has changed since it was signed.

Together, these tools help verify identity and detect changes to signed information. They don’t prove that an agent’s answers are correct or that it has permission to carry out a task.

JSON schemas create a common structure

JSON schemas are a standardized format that helps different systems interpret agent information consistently in ANS. Basically, it describes how information should be organized.

Think of everyone filling out the same form. The form has clearly labeled fields, such as name, provider, and supported tasks. In ANS, JSON schemas help systems exchange registration and discovery information in a consistent format. They can also check whether required information is missing or entered in the wrong format.

This supports structured communication between different systems. However, a correctly completed form doesn’t prove that every claim on it is true. Identity checks serve a separate purpose.

The protocol adapter layer helps different agents communicate

Once a system can verify an agent’s identity and read its information, it also needs a compatible way to connect. A protocol provides the rules for exchanging information, but different tools may use different protocols.

To help bridge those differences, OWASP’s original ANS framework includes a modular protocol adapter layer. Think of it as a translator between the registry’s shared format and the formats different tools understand. “Modular” means separate adapters can support different protocols, including:

• Agent-to-Agent (A2A)
• Model Context Protocol (MCP)
• Agent Communication Protocol (ACP)

This multi-protocol support matters because agents from different providers may describe their capabilities and connection details differently. The protocol adapter layer helps translate those details into a shared structure. This supports protocol-agnostic registry infrastructure, meaning the registry can serve tools using different protocols rather than depending on just one.

For example, a business assistant looking for a scheduling agent needs to know both what the agent can do and how to reach it. Finding an agent based on its supported tasks is called capability-aware resolution. Secure resolution adds identity and integrity checks to the lookup process. ANS combines adapters with robust mechanisms such as certificate checks and digital signatures to support these steps.

However, translating registry information doesn’t guarantee that two agents can complete a task together. Their tools must still support compatible interactions, and the business must set appropriate permissions. The adapter helps systems understand connection information; the actual workflow depends on the integrations available.

How can small businesses use the ANS?

For small businesses, ANS could help answer a simple question: “Is this agent really connected to the business it claims to represent?” Services and tools that support ANS could handle those checks, so business owners wouldn’t need to build their own identity system.

As support grows, those checks could help businesses:

• Verify customer-facing sales and support agents
• Verify scheduling and booking agents
• Add trust to purchasing and vendor interactions
• Support multi-agent business workflows

Verify customer-facing sales and support agents

An online store might use an AI agent to answer product questions, check order updates, or collect contact details from potential customers. Before sharing information, a customer or their AI assistant needs a way to check that the agent actually represents the store. Anyone could copy a business’s name or logo.

A service that supports ANS could check the agent’s digital credentials against the store’s expected domain. For example, if a sales agent asks for an email address to arrange a product demonstration, the customer’s supporting tool could verify the agent’s connection to the business before passing along those details. This could help reduce the risk of sending information to an impersonator.

Note: The purpose is to check who the agent represents, but it doesn’t prove that its product advice is accurate or that it can resolve a support issue. The store would still need to review its answers and set limits on the customer information it can access.

Verify scheduling and booking agents

Imagine a customer asks their AI assistant to book a haircut for Friday afternoon. The assistant contacts the salon’s booking agent, checks available times, and requests an appointment. This is agent-to-agent communication: two agents exchange information to complete a task.

Before sending the customer’s name and phone number, the assistant’s supporting system could use ANS to check that the booking agent is connected to the salon’s expected domain. This helps reduce the risk of sharing personal details with an impersonator. The salon’s system would also need to verify the requesting assistant’s identity and check that the customer authorized it to make the booking.

When agents communicate, systems need to check who each agent represents, what it can do, and what it’s allowed to do. Agent capabilities describe the tasks it can perform, while permissions limit which tasks it may carry out. For example, an assistant might be able to book, change, or cancel appointments, but the customer may only allow it to make one booking. The scheduling system should enforce that limit to prevent unwanted changes, especially when autonomous agents act without someone approving every step.

Add trust to purchasing and vendor interactions

A small retailer might use a purchasing agent to reorder stock when supplies run low. The agent could contact a supplier’s agent, request a price, and submit an order within limits set by the retailer. Identity matters more when an agent’s requests can lead to goods being shipped or money being spent.

Before exchanging order details, systems that support ANS could check that each agent is connected to the expected business. The retailer needs to know it is contacting the intended supplier, and the supplier needs to know the order request comes from the retailer’s agent. Without those checks, an impersonator could collect business information or submit fake orders.

Note: ANS helps verify identity, but it doesn’t approve purchases, authorize payments, or guarantee legitimate transactions. Businesses still need supplier checks, spending limits, and approval rules—and must confirm that an agent has permission to place an order.

Support multi-agent business workflows

A small business might use one agent for customer questions, another for scheduling, and a third for order updates. These multi-agent systems involve several agents handling different parts of a task, sometimes through tools from different providers.

For example, a repair shop’s support agent could receive a customer’s request and pass it to a scheduling agent. Once an appointment is booked, the scheduling agent could ask a notification agent to send a confirmation. Before accepting each request, the receiving system needs to check which agent sent it and what that agent is allowed to do.

ANS gives systems a common way to check an agent’s identity, even when the agents come from different platforms. This could help agents built with different agent frameworks find and identify one another. Though they still need compatible tools and connections to work together, its protocol adapters act as translators, helping tools that use diverse communication standards read information about registered agents.

Consistent identity checks could also support scalable agent ecosystems, helping businesses add more agents as their needs grow. Each workflow would still need compatible connections and clear permissions so agents can exchange information and act appropriately.

Where can I find verified AI agents?

Users may find AI agents through marketplaces or directories that implement ANS-based identity verification, including Network Solutions’ ANS Registry. Verification processes vary by platform. You may be able to browse listings and review identity information before connecting to an agent.

A directory or marketplace may display those records in an easier-to-read format, which generally includes:

• Agent identity or name: The name that identifies the registered agent.
• Provider or operator: Who runs or provides the agent.
• Agent capabilities: The tasks the agent claims it can perform.
• Supported protocols: The connection methods compatible tools can use.
• Verification information: What identity checks were completed or whether the registration is current.
• Version and endpoint: The agent’s software version and the online address where systems can reach it.

Note that the information shown varies by platform. These are general examples.

Before choosing an agent, ask what “verified” means. The platform may have checked that the operator controls the linked domain. That does not mean it has tested the agent’s answers or how well it works.

Also check the cost, whether it works with your tools, how it handles your data, and what access it needs. A listing doesn’t necessarily mean the agent is ready to use. You may need an account, subscription, or setup with its provider.

Frequently asked questions

Work with verified AI agents today

As autonomous agents take on tasks involving customer information, appointments, and purchases, small businesses need to know who or what those agents represent. ANS is designed to support that check by giving agents verifiable identities through established internet infrastructure, including domain names and digital certificates.

Agent discovery helps you find an agent that may fit your needs. Agent verification helps you check the identity behind it. Before choosing one, review who operates it, what the service has verified, and which permissions it needs.

As more tools adopt shared identity standards, businesses could connect agents across their services with greater confidence. Start with one clear task, check the agent’s identity, and keep control over the actions it can take.