Bidirectional tool calls

Expanded Definition

Bidirectional tool calls describe a proposed Model Context Protocol capability in which an MCP server can initiate work, request tool execution, or otherwise drive interaction back toward the client or model. That differs from the more familiar one-way pattern where the model asks and the server only answers. In NHI governance, the key issue is not just whether the call is technically possible, but who is authorised to trigger downstream actions, under what policy, and with what auditability. The concept is still evolving, and definitions vary across vendors and implementations because MCP itself is a developing standard rather than a fixed operational model. For governance teams, the closest analogue is shared control over execution authority, which brings the problem into the same risk space as privileged automation and delegated credentials. A useful reference point is the NIST Cybersecurity Framework 2.0, especially where access control and logging must reflect tool-initiated actions as well as user-initiated ones. The most common misapplication is treating server-initiated tool use as a harmless messaging feature, which occurs when teams ignore that the server may now be capable of triggering privileged downstream work.

Examples and Use Cases

Implementing bidirectional tool calls rigorously often introduces policy complexity, requiring organisations to weigh automation reach against control over who can initiate sensitive actions.

• An MCP server requests a log export from a SIEM so an agent can summarize incidents without a human manually relaying each step.
• A workflow server triggers a ticketing or approval tool after detecting a failed rotation event, creating a closed-loop remediation path.
• An internal assistant server asks a secrets management tool to validate token status before the model continues a deployment sequence.
• A federated agent runtime uses server-initiated prompts to ask for additional context, but only within an approved execution boundary.

These patterns are useful only when the request path is authenticated, authorised, and recorded. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why tool-triggered actions should be treated as security-relevant control events, not as simple application callbacks. The governance implications are easier to evaluate when paired with the Ultimate Guide to NHIs — 2025 Outlook and Predictions and with NIST Cybersecurity Framework 2.0 for mapping workflow events to security outcomes.

Why It Matters in NHI Security

Bidirectional tool calls change the trust boundary. Once a server can initiate actions, it can also become a path for privilege amplification, workflow abuse, and hidden dependency chains across agents, tools, and secrets. That matters because NHI environments already struggle with visibility and control: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, according to NHI Management Group in the Ultimate Guide to NHIs. In practice, a server that can call tools may need equivalent scrutiny to a privileged service account, including scoped entitlements, event logging, and explicit approval logic. The concept also intersects with NIST Cybersecurity Framework 2.0 because detect, protect, and respond controls must account for non-human initiation paths. Organisations typically encounter the operational impact only after an unexpected action, failed audit, or incident review reveals that a server could trigger downstream work without the guardrails they assumed were already in place.

Related resources from NHI Mgmt Group

• How should security teams govern agent tool calls in production?
• Why do valid tool calls still create risk in agentic applications?
• When should organizations consider adopting advanced tool discovery for AI agents?
• How can organizations mitigate tool misuse in agentic deployments?