Resource Discovery

Expanded Definition

Resource discovery describes the stage where an AI model or agent inspects a connected service to learn which tools, endpoints, capabilities, or data sources are available. In Model Context Protocol, this is usually a structured capability query rather than an open-ended search, so the model can reason about permitted actions before it attempts them.

The boundary matters. Resource discovery does not mean the model already has permission to use every discovered capability, and it does not replace authorization or policy enforcement. A service may advertise functions that remain blocked by role, scope, tenant, or approval constraints. The practical distinction is between visibility and use: discovery tells the model what exists, while control layers decide what is allowed. That distinction is especially important in agentic systems, where a model may chain discovered capabilities into multi-step actions if governance is weak.

For identity and access teams, the common misunderstanding is treating discovery as a harmless metadata step. In reality, the discovery surface becomes part of the trust boundary because it shapes what the model believes is available, which in turn affects tool selection and execution paths.

Examples and Use Cases

Resource discovery appears wherever an AI client or agent connects to a tool-rich service and needs a machine-readable view of its options before acting.

• An enterprise assistant connects to an internal MCP server and enumerates available read-only and write-enabled tools before generating a workflow.
• A support agent discovers approved knowledge sources, ticketing actions, and customer-data queries, then selects only the capabilities allowed for that session.
• A developer copilot inspects a repository service to identify available documentation, test, and deployment helpers before proposing an action plan.
• A regulated workflow uses discovery to expose only the minimal tool set needed for a specific business task, reducing accidental overreach.
• An operations team uses the discovery response to verify whether a service is advertising unexpected capabilities that should not be exposed to that model.

The implementation tradeoff is straightforward: broader discovery improves agent flexibility and reduces configuration friction, but it also increases the value of strict scope enforcement and accurate capability labeling.

Security Implications

When resource discovery is too broad, poorly segmented, or insufficiently authenticated, the model may learn about capabilities it should never see. That can create exposure even if downstream permissions still block execution, because discovery itself can reveal internal functions, data classifications, workflow structure, or privileged operations. In agentic environments, that visibility can also increase the chance of unsafe task planning or unintended tool chaining.

Mismanaged discovery commonly produces three failure patterns: overexposure of capabilities, mismatch between advertised and actual permissions, and policy drift between service configuration and model expectations. Each one can lead to confusing failures, hidden privilege gaps, or inconsistent access decisions across tenants and sessions. A practitioner should pay attention when the discovery surface grows faster than the authorization model, because that is often where least-privilege assumptions break down.

For NHIMG, the security significance is not the discovery call itself but the trust it creates. Once a model can reliably inventory available actions, weak authorization boundaries can turn that inventory into a roadmap for misuse.

Domain and Governance Relevance

In AI and identity governance, resource discovery is the point where capability inventory becomes part of access control design. For connected AI services, governance must answer not only what a model can do, but what it is allowed to know exists. That is a subtle but important boundary in non-human identity environments, where service accounts, agents, and delegated workflows often rely on structured discovery to operate.

For NHI security, the connection is direct when discovery exposes machine-accessible tools, APIs, or data sources that are governed through service identities. If the discovery layer is not aligned with the underlying entitlement model, an agent may appear to have a broader operational footprint than its credentials actually permit. That mismatch complicates auditing, ownership, and offboarding, especially when multiple agents or services share the same integration path.

Resource discovery therefore sits at the intersection of capability management, authorization design, and operational trust. In practice, it is as much a governance concern as a technical one.

Related resources from NHI Mgmt Group

• What breaks when resource discovery is routed through a management proxy?
• What is the difference between resource discovery and code-to-resource mapping in Terraform operations?
• How should security teams implement OAuth protected resource metadata in a way that supports dynamic discovery without weakening trust boundaries?
• Automatic Resource Discovery