A Hypothetical: Beacon Got an RFP from AI
Late on a Friday afternoon, Beacon, an industrial pump manufacturer, finds itself reluctantly dragged into agentic commerce. They receive an RFP from Acme, a major customer. If booked, this would be Beacon’s largest order of the year, but the party initiating the RFP is an AI agent, not a human.
From: Acme Procurement Agent <procurementagent@acme.com>
To: Beacon Legal <legal@beacon.com>
Subject: RFP 2026-1847 — Industrial Pump Order
Acme is requesting a proposal for 120 industrial pumps. Please provide your responses no later than 11:59 p.m. ET on September 6, 2026, by following the instructions set forth in the agent address below.
Agent: Acme Procurement Agent
Agent address: https://agents.acme.com/procurementagent
Automated system—no human employee is monitoring this mailbox.
Beacon is caught in a dilemma: Ignore it and risk losing a million-dollar deal, or submit confidential pricing to an AI and risk exposing proprietary data to an imposter.
In the “glorious old days,” this RFP would have arrived from someone like Jane Smith, Acme’s procurement manager. Her email signature, title and company logo provided a sense of security. Human trust filled the gaps. Today, if Beacon tries to call their human contact at Acme, they hit a brick wall: Acme has gone AI-first.
The Future Is Already Here
Agent commerce is no longer a future fantasy. A February 2026 Cloud Security Alliance survey estimates that 70 percent of organizations expect to manage anywhere from dozens to hundreds of agents within a year. Security firm Human reported that in 2025, 77 percent of agentic AI activity was on product and search pages, but unfortunately, 5.7 percent of observed traffic presenting an AI crawler or scraper was spoofed.
Unwilling to lose the deal, Beacon assigns an employee to investigate. Because acme.com is a confirmed Acme registered domain, and agents.acme.com is verified by a chain of digital signatures via DNS Security Extension (DNSSEC), Beacon infers that Acme must have authorized the address https://agents.acme.com/procurementagent. When the employee clicks the link, they see instructions only readable by machines. The employee quickly uses an interactive AI tool to build a response agent, feeds it the https://agents.acme.com/procurementagent URL along with Beacon’s pricing and RFP data, and deploys it. Twenty minutes later, the agent reports that the RFP was successfully submitted.
Beacon Wins! (And Then Doesn’t)
The next day, the Acme procurement agent emails an award notice: Beacon won! Exhilarated, Beacon ships the pumps through Acme’s distributor and gets paid.
Ten days later, life takes a turn. The distributor demands Beacon to issue a refund, claiming that the RFP was still open and no award had been approved. Lawsuits quickly follow.
In court, the facts unfold. Acme had deployed a second, more secure agent at https://agents.acme.com/procurementagent2 to collect the detailed pricing and engineering data that other vendors were concerned about sharing. Unfortunately, the first procurement agent didn’t know about the second agent, and decided to declare Beacon as the winner.
Acme claims the first agent exceeded its authority and was never permitted to accept bids. Beacon argues “apparent authority”: just as an email from “Jane Smith, Acme procurement manager” binds Acme, an agent operating at Acme’s official endpoint should carry the apparent authority to declare a winner.
Filling the Gaps: Augmenting DNS Records with Richer Data
This hypothetical highlights the gaps in today’s internet standards, which were built for human consumption.
- DNS could confirm that Acme controls agents.acme.com, but because it operates at the host level, it is unable to route or verify who controls specific application paths like /procurementagent versus /procurementagent2.
- HTTPS could confirm a secure connection to the endpoint, but it couldn’t verify the agent’s delegated authority or prevent Beacon from transacting with an agent acting beyond its scope.
In the past, DNS was a “dummy router.” You give it a domain name, and it points you to an IP address like 192.0.2.1. It couldn’t provide agent names, capabilities or other contextual data.
Verifying Acme controls agents.acme.com does not answer any of the following questions:
- Does Acme have a procurement agent?
- Does the procurement agent live at the address https://agents.acme.com/procurementagent?
- Is this agent authorized to receive RFP responses, and more importantly, accept bids and declare the winner?
This is where DNS for Agent Discovery (DNS-AID) comes in.
DNS-AID, initially proposed by Infoblox, is an Internet Engineering Task Force (IETF) draft that publishes agent records under a domain the operator controls using Service Binding (SVCB). Because SVCB provides customers with all necessary connection details in a single DNS query, it eliminates vulnerable back-and-forth handshakes, offering a secure way to authenticate the endpoint and route information in one go.
More importantly, this establishes a deterministic reinforcement point, allowing DNS servers to automatically block unauthorized traffic and sever connections before a single byte of confidential information is transmitted.
How Would DNS-AID Prevent a Million-Dollar Dispute?
If Acme had published a DNS-AID record for its procurement agent, Beacon could have looked up that record by running a simple command:
dig procurementagent.agents.acme.com SVCB
They might receive this answer back:
procurementagent.agents.acme.com. 3600 IN SVCB 1 procurementagent.agents.acme.com. (
alpn=”a2a,h2″
port=443
ipv4hint=192.0.2.1
well-known=”/.well-known/agent-card.json”
)
This rich response tells Beacon what it needs to know before deciding whether to send a response:
- The official agent is hosted at procurementagent.agents.acme.com.
- It communicates using an agent-to-agent (A2A) protocol over HTTPS (alpn=”a2a,h2″).
- It can be found at port 443 under the IP address 192.0.2.1.
- Additional verification and capability data is available at the URL https://procurementagent.agents.acme.com/.well-known/agent-card.json.
Paired with DANE, a security protocol that uses DNSSEC to securely bind digital certificates to a domain name, Acme ensures a verifiable chain of trust proving that this record comes directly from Acme.
Beacon’s agent could now safely proceed to pull information about the agent from the URL: https://procurementagent.agents.acme.com/.well-known/agent-card.json
This link allows Beacon to connect to agents.acme.com over HTTPS. During the connection, the server presents a certificate covering agents.acme.com. Beacon checks that the certificate is valid, has not expired and is issued by a trusted certificate authority.
Using this HTTPS link, Beacon’s agent retrieved the following “business card” (see excerpt below):
const acmeProcurementAgent: AgentCard = {
name: “Acme Procurement Agent (Initial Contact)”,
description:
“Distributes requests for proposals (RFPs) and collects preliminary vendor qualifications on behalf of Acme. STRICTLY PROHIBITED from accepting final bids, executing contracts, or receiving sensitive pricing and product roadmap information.”,
url: “https://agents.acme.com/procurementagent”,
provider: {
organization: “Acme Corporation”,
url: “https://www.acme.com”
},
version: “1.0.0”,
…
},
authorizedScope: {
canBindContracts: false,
canAcceptBids: false,
dataClassificationLimit: “Public/Non-Confidential”,
prohibitedData: [“Detailed Pricing”, “Proprietary Architecture”, “Product Roadmaps”]
},
Noting that this agent is unable to accept sensitive information or issue an award, Beacon’s agent would have proceeded to search for a new agent that is authorized to do so. By querying _catalog._agents.acme.com, Beacon’s agent would have queried the catalog of Acme’s agents from a well-known entry point and found two agents:
- /procurementagent: Authorized for initial contact and basic RFP information.
- /procurementagent2: Authorized for receiving sensitive pricing and technical data and finalizing bids.
By checking the agent catalog and the agent “business card” via DNS, Beacon’s agent would have discovered the second, authorized agent. It would have stopped the transaction with /procurementagent, and the multi-million-dollar dispute would have been averted.
DNS-AID: Extension of the Most Widely Used Trust Infrastructure
Domain ownership remains the foundational proof of trust on the internet. By extending that trust through augmenting DNS records, DNS-AID gives autonomous agents more tools to ensure that the party on the other side of the table has the authority to close a deal.
Providing additional context via SVCB parameters in the DNS doesn’t solve every problem. However, by extending the most widely used trust infrastructure that exists today, DNS-AID provides a first layer of trust that will help protect merchants like Beacon avoid a million-dollar loss.
DNS-AID is currently proposed as an open standard through the IETF Discovery of Agents With Names (DAWN) working group. The reference implementation has been contributed to the Linux Foundation as an open-source project, with support from organizations including Akamai, Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium (ISC) and WWT.
To learn more about DNS-AID, visit https://dns-aid.org, https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ (IETF draft) and https://github.com/dns-aid/dns-aid-core (GitHub).
