Tool Selection Broker

Expanded Definition

A tool selection broker is an orchestration control that decides which tool or server an AI assistant should use for a given task, rather than exposing every available integration at once. In an agentic environment, that means the broker evaluates the prompt, available capabilities, policy constraints, and sometimes the current trust context before routing execution.

This matters because tool access is part of the identity and authorization surface for an AI agent. A broker can reduce context bloat, limit unnecessary tool discovery, and enforce narrower execution paths, which is closer to Zero Trust thinking than a broad “all tools are visible” model. Definitions vary across vendors, and no single standard governs this yet, so implementations may be called a router, selector, dispatcher, or capability broker. For governance purposes, the key question is whether the layer merely recommends tools or actually constrains execution.

Practitioners often compare this idea to tool registries and protocol-mediated integrations such as the Model Context Protocol, but the broker is the decision layer that sits above simple exposure of endpoints. The most common misapplication is treating a tool catalog as a broker, which occurs when every connected capability is still exposed to the agent and only post-selection filtering is applied.

Examples and Use Cases

Implementing a tool selection broker rigorously often introduces routing latency and policy complexity, requiring organisations to weigh tighter control against faster agent execution.

• An internal assistant receives a request to update a ticket and the broker routes it only to the approved ITSM connector, rather than revealing finance, HR, and engineering tools in the same session.
• A support agent uses the broker to choose between a read-only knowledge base query and a privileged incident-response action, based on task intent and current authorisation.
• A developer assistant is allowed to select a deployment tool only after policy checks confirm that the request is within change window and environment scope.
• An enterprise agent relies on brokered routing to choose the least-privileged server for a data retrieval request, reducing accidental exposure of high-impact integrations.
• Teams designing agent controls often pair broker logic with identity guidance from the NIST Cybersecurity Framework 2.0 and operational lessons in the Ultimate Guide to NHIs.

Why It Matters in NHI Security

Tool selection brokers sit at the junction of agent identity, privilege control, and tool exposure. If the broker is weak, an AI agent may see too many capabilities, select a higher-risk path than necessary, or inherit permissions that were never meant for broad discovery. That creates a practical NHI problem because tools often depend on API keys, service accounts, and other machine identities that should be tightly scoped, monitored, and rotated. NHI Management Group notes that 97% of NHIs carry excessive privileges, which makes over-broad tool access especially dangerous when agents can invoke actions automatically.

A broker also supports reduction of attack surface when paired with governance and logging. If it is absent, security teams often discover the issue only after an agent performs an unintended action, a secret is overused, or a connector is exposed during incident review. The operational lesson is that tool access must be constrained before the agent can reason over it, not merely after the fact.

Organisations typically encounter privilege creep, unexpected data exposure, or connector abuse only after a tool misuse event, at which point brokered selection becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when an AI agent can call tools but tool selection and invocation are not measured separately?
• How do security teams decide whether to prioritise tool governance or model selection for agentic AI risk?
• Runtime tool selection
• Tool Selection Accuracy