Dynamic Tool Discovery

Expanded Definition

Dynamic tool discovery is an agent operating pattern in which the agent queries a registry, directory, or capability endpoint at runtime before selecting a tool. In practice, this makes tool access more adaptable than hardcoded integrations, but it also shifts governance from build time to execution time. In the NHI and agentic AI context, the key question is not only whether a tool exists, but whether that tool should be discoverable by that specific agent in that moment.

Definitions vary across vendors on whether discovery includes only metadata retrieval or also policy evaluation, tool ranking, and invocation permissions. NHI Management Group treats those as related but distinct steps. Discovery is the lookup; authorization is the decision; execution is the action. That distinction matters because a permissive registry can expose tools that an agent should never be able to invoke, even if downstream checks exist. For a standards anchor on governance outcomes, see the NIST Cybersecurity Framework 2.0.

The most common misapplication is treating discovery as an access control boundary, which occurs when organisations expose broad tool catalogs to agents and assume later checks will fully contain overreach.

Examples and Use Cases

Implementing dynamic tool discovery rigorously often introduces policy complexity, requiring organisations to weigh agent flexibility against tighter registry controls and continuous authorization checks.

• An internal support agent queries a service catalog before opening a ticketing or incident-response tool, but only receives tools approved for its workload identity and environment.
• A code-assist agent discovers deployment and observability tools at runtime, while a policy engine suppresses destructive actions unless the request meets explicit change-control rules.
• A data-retrieval agent uses a directory to find approved database connectors, with scopes constrained so it cannot enumerate tools exposed to adjacent teams.
• A multi-agent workflow routes through a shared registry so new tools can be added without redeploying every agent, while least-privilege filters are enforced centrally.
• See the broader lifecycle and access implications in the NHI Lifecycle Management Guide and the related attack surface discussion in Top 10 NHI Issues.

For policy-driven agent design, the same runtime discovery idea appears in broader AI control discussions, including the NIST Cybersecurity Framework 2.0 emphasis on governed access and protective controls.

Why It Matters in NHI Security

Dynamic tool discovery expands the attack surface if registry access is too broad, because an agent can surface tools that were never meant for its role, tenant, or risk tier. In NHI security, that is especially dangerous when service identities are already overprivileged or poorly inventoried. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which means dynamic discovery often lands in environments where ownership, scope, and offboarding are already weak. Combined with the fact that 97% of NHIs carry excessive privileges, discovery can become a multiplier for misuse rather than a convenience.

The governance challenge is to ensure the registry reflects real entitlement boundaries, not just what is technically reachable. That requires continuous alignment between tool publication, identity claims, and policy enforcement, especially for third-party or cross-domain tools. It also means treating discovery logs as security telemetry, since anomalous tool lookups can reveal reconnaissance or policy probing. The issue becomes operationally unavoidable after an agent reaches an unauthorized tool, triggers a failed action, or exposes a hidden capability during an incident review.

Related resources from NHI Mgmt Group

• When should organizations consider adopting advanced tool discovery for AI agents?
• How should security teams handle tool discovery for AI agents in MCP environments?
• When does app discovery automation become a governance control instead of a reporting tool?
• Tool discovery