Timely researched AI explainer | Updated 20 September 2026
An ordinary chatbot mainly returns text. An AI agent may also search a database, read a document repository, open a support ticket or call another software service. Once an AI system can use external tools, finding the correct tool and deciding whether it is safe to connect become separate engineering problems.
This article explains agent discovery using Google’s Agentic Resource Discovery announcement as a current example. It does not suggest that one specification has become a universal standard or that verification removes every security risk.
What tool discovery means
A software tool must describe what it can do before an agent can select it. A useful description might identify a function such as retrieving an order, querying approved documents or creating a ticket. Discovery is the process through which an agent locates and evaluates those available capabilities.
The challenge grows when tools are distributed across teams, providers and technical protocols. A name such as “customer-search” does not by itself prove who published the tool, which records it can access or what action it performs after receiving a request.
What Google announced
On 17 June 2026, Google announced Agentic Resource Discovery, or ARD, as an open specification for publishing, discovering and verifying AI capabilities across the web. The announcement describes resources that can include agents, skills, MCP servers and OpenAPI tools.
Google’s design uses catalogues published under an organisation’s domain and registries that index those catalogues. The proposal also describes trust metadata for verifying publisher identity before a client connects. ARD’s availability does not mean every agent platform or organisation currently uses it.
Discovery is not authorisation
Finding a legitimate capability answers only part of the question. An organisation must still decide whether a particular user or agent should be allowed to invoke it. A verified tool that deletes records remains dangerous if it receives excessive permission.
For example, a college helpdesk agent may need read-only access to approved frequently asked questions. It probably does not need permission to modify student results. This example illustrates least-privilege design: give the workflow only the access required for its defined purpose.
Review the proposed action, not just the response
An agent can produce a harmless-looking sentence after carrying out a consequential action. Therefore, logging only the final message is insufficient. Record which tool was selected, the parameters supplied, the identity under which it ran and the result returned.
Introduce human approval before high-impact actions such as sending money, publishing content, deleting information, changing permissions or messaging an external recipient. The approval screen should show the real proposed action clearly rather than asking a vague question such as “Continue?”
Build an internal tool register
Before enabling dynamic discovery, maintain a simple register of approved capabilities. Useful fields include:
- Tool name, publisher and verified domain;
- Business owner and technical owner;
- Data the tool can read, create, change or delete;
- Authentication and permission method;
- Actions requiring human approval;
- Current version and review date;
- Procedure for disabling the connection.
This register provides context that a technical catalogue alone may not contain. It also gives staff somewhere to record why a capability was approved.
Test failure cases deliberately
A pilot should include more than successful requests. Test ambiguous tool names, unavailable services, expired credentials, excessive parameters and content that attempts to redirect the agent away from its assigned task.
Use non-sensitive sample data during early testing. Confirm that the agent refuses or escalates actions outside its permission boundary. Verify that administrators can identify which tool generated an error and revoke its access without disabling unrelated services.
Do not confuse identity with safety
Publisher verification can help establish where a tool came from. It does not prove that the tool has no software defects, that its configuration is correct or that it is suitable for confidential information. Security review, permission controls, monitoring and incident response remain necessary.
Conclusion
AI-agent discovery is a trust-and-governance problem as much as a search problem. Verify the publisher, restrict permissions, expose consequential actions for approval and keep an auditable record. Connecting tools dynamically is useful only when the organisation can also disconnect and investigate them safely.
Sources and verification
- Google Developers Blog: Agentic Resource Discovery, 17 June 2026
- Agentic Resource Discovery specification website
Fact-check: 20 September 2026, evening IST. ARD is presented as an announced open specification, not a universal requirement.
