Should organisations use search-and-run instead of exposing every tool directly?

Why search-and-run fits long-tail tool access

Search-and-run is strongest when the tool catalog is broad, unevenly used, or changes often. It treats tool exposure as a just-in-time decision instead of a permanent part of the agent’s default context, which reduces noise and makes tool discovery more deliberate. That matters most when only a small subset of tools should ever be relevant to a given task.

It also changes the governance model. Instead of assuming every exposed tool is acceptable all the time, teams can control which capabilities are searchable, which require additional approval, and which should remain hidden unless a use case actually justifies them. That gives operators a cleaner way to separate capability availability from routine reachability.

For agentic systems, this approach can be especially useful because tool choice is part of runtime authority, not just interface design. A smaller default surface tends to improve action selection, reduce accidental invocation, and make it easier to reason about what an agent could do in a given session.

What search-and-run changes about safety and control

The main security benefit is that it narrows unnecessary exposure. If every tool is directly exposed, the agent may over-approximate what is available and reach for functions that were not intended for the current workflow. Search-and-run reduces that ambient reach by making the tool an explicit, selected object rather than a standing option.

That does not remove the need for authorization, logging, or scoped credentials. It simply makes the access path more intentional. Teams still need to decide who can publish tools, who can discover them, and what conditions allow execution, but they can do so with better granularity than a flat all-tools-visible model.

The governance upside is strongest where the tool estate includes specialized, high-impact, or sensitive actions. When a tool only appears after a search step, the review surface shifts from “everything the agent might call” to “the smaller set it can actually reach for this task.” That is easier to audit, easier to classify, and easier to retire when it is no longer needed.

When direct exposure is still the better choice

Direct exposure still has a place for a small, stable, and universally safe core set of tools that every workflow needs. If the catalog is tiny, the overhead of search can become friction rather than control. In that case, the simpler model is easier to operate and easier for developers to understand.

It is also reasonable when the tool set is tightly curated and the cost of hiding a needed tool is higher than the cost of overexposure. Some teams will choose a hybrid model: a short, always-available core and a larger long-tail catalog that is only discoverable through search.

The deciding factor is not whether search-and-run is “more secure” in the abstract. It is whether the system benefits more from reducing ambient tool visibility than from minimizing selection friction. Where the long tail dominates, the balance usually shifts toward search-and-run.

Risk and Threat Considerations

Exposing every tool directly increases the chance of accidental invocation, excessive reach, and misuse of privileged functions. Search-and-run lowers that exposure, but it also creates a new control point: if search, ranking, or metadata is manipulated, the agent may surface the wrong capability or ignore a safer one.

Failure mechanism: Over-broad tool visibility expands the effective attack surface, while weak search governance can be used to steer the agent toward unsafe, overprivileged, or misleading actions.

Impact: The result can be unauthorized actions, broader blast radius from a compromised workflow, or poor operator visibility into what the agent was able to reach and execute.

Practitioner Guidance

What to prioritise: Classify tools into a small always-available core and a searchable long tail. Reserve direct exposure for low-risk, high-frequency actions and push the rest behind discovery and approval boundaries.

What to verify: Confirm that searchable tools still inherit the right execution controls, approval checks, and audit trail. A hidden tool is not safer if it can still be run with the wrong privilege once found.

Common mistake: Treating search-and-run as a user-experience feature only. The important decision is governance of reachability, not just how the catalog is displayed.

Practitioner takeaway: Use search-and-run when tool breadth creates more exposure than convenience, but keep the execution path as tightly controlled as if every surfaced tool were already privileged.

Related resources from NHI Mgmt Group

• Why do organisations use multiple LLMs instead of a single model for every task?
• When should organisations use a hybrid approach instead of a single tool for agent data access?
• When should organisations use EDR for threat hunting instead of treating it only as an alerting tool?
• When should organisations use a sandbox instead of moving a financial health startup directly into production?