The process by which an AI system chooses which external tool to invoke during execution rather than following a fixed, pre-approved script. This matters because the effective privilege set can change during use, which makes static entitlement reviews less complete.
Expanded Definition
Runtime tool selection is the moment an agent, model, or autonomous workflow decides which tool to call after execution has already begun. In NHI security, that is not just a routing choice. It can expand or narrow effective privilege in real time, especially when tools expose secrets, data, or side effects. The concept is still evolving across vendors, so governance teams should treat it as a control point rather than a purely application-design detail. NIST Cybersecurity Framework 2.0 frames this kind of dynamic exposure under governance and access control expectations, even if it does not name the pattern directly NIST Cybersecurity Framework 2.0.
For NHI programs, runtime tool selection matters because the agent may invoke APIs, internal services, or privileged automations that were not obvious during initial review. NHI Management Group notes that 97% of NHIs carry excessive privileges, which makes dynamic tool choice especially risky when privilege boundaries are unclear Ultimate Guide to NHIs. The most common misapplication is assuming a model is safe because its prompt or workflow was approved, which occurs when the tool catalog and downstream permissions are allowed to change during execution.
Examples and Use Cases
Implementing runtime tool selection rigorously often introduces policy overhead, requiring organisations to balance flexibility and automation speed against tighter authorization checks and auditability.
- An agent chooses between a read-only search tool and a ticketing API based on the user’s request, but the ticketing API can trigger workflow changes, so the selection must be logged and constrained.
- A support assistant routes to different internal knowledge bases at runtime, where one source contains sensitive incident data and another is public, requiring context-aware access filtering.
- A code-generation agent calls a deployment tool only when confidence is high, but the deployment identity must still be separately governed as an NHI with scoped approval.
- A finance workflow selects a payment reconciliation API during execution, and the tool’s entitlement must be evaluated independently of the model’s general prompt permissions.
- In agentic systems, policy engines may allow a narrower tool subset for a high-risk task, similar to the tool-boundary discipline discussed in the Ultimate Guide to NHIs and in implementation patterns aligned to zero trust.
Runtime selection also appears in standards-oriented designs that separate orchestration from authorization, so the calling identity is verified before a tool can act on behalf of the agent.
Why It Matters in NHI Security
Runtime tool selection becomes a security issue because it can turn a seemingly low-risk agent into a privileged actor mid-session. If the selected tool can read secrets, modify records, or trigger downstream automations, then the real attack surface is the decision path, not just the model endpoint. That is why NHI governance needs visibility into which tools were chosen, why they were chosen, and which identity executed the call. The problem is magnified by poor visibility into service accounts, since only 5.7% of organisations have full visibility into their service accounts according to NHI Management Group Ultimate Guide to NHIs.
For defenders, runtime tool selection should be mapped to least privilege, explicit approval boundaries, and per-tool telemetry. It also aligns with NIST Cybersecurity Framework 2.0 functions for govern, protect, and detect when operationalised through NHI controls NIST Cybersecurity Framework 2.0. Organisations typically encounter the failure mode only after an agent has already invoked the wrong tool, at which point runtime tool selection becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic systems must constrain tool choice to prevent unsafe action escalation. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Dynamic tool calls can expose secrets and privileged NHI credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control applies to tool choice and execution rights. |
Restrict tool catalogs, require policy checks, and log every agent tool invocation.
Related resources from NHI Mgmt Group
- Why do AI agents and tool-connected LLMs need runtime controls as well as testing?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between code scanning and runtime identity monitoring?
- When should organizations consider adopting advanced tool discovery for AI agents?
