Join our Newsletter — 33% off our NHI Course

Bidirectional capability exposure

A condition where both the client and server can initiate meaningful actions, not just exchange requests and responses. In MCP, that can let a server consume model resources or shape prompts, which expands the security boundary beyond a simple API call.

Expanded Definition

Bidirectional capability exposure describes a protocol or integration pattern where both sides can take meaningful action, not merely exchange data. In model-driven systems such as Model Context Protocol-style deployments, that means a server can influence prompts, request additional context, or trigger downstream actions while the client can also initiate tool use and state changes. Definitions vary across vendors when they describe this as “two-way,” “interactive,” or “agentic,” but the security meaning is consistent: the boundary is no longer a simple request-response API. The practical distinction is that exposed capability can create hidden trust paths, especially when a model, agent, or middleware component can act on outputs as if they were safe instructions. NHI Management Group treats this as a governance issue as much as a technical one because it affects identity boundaries, authorization scope, and data handling. The most common misapplication is treating a bidirectional interface like a one-way API, which occurs when teams review only inbound requests and ignore server-initiated actions, prompt influence, and tool invocation paths.

For related governance context, the Ultimate Guide to NHIs — Why NHI Security Matters Now frames why expanded machine-to-machine trust paths have become a core risk area, and the NIST Cybersecurity Framework helps anchor the operational controls that should wrap them.

Examples and Use Cases

Implementing bidirectional capability exposure rigorously often introduces governance overhead, because every “helpful” server action must be reviewed for authorization, logging, and blast radius before it is allowed in production.

  • An MCP server returns content to a model and also requests follow-up retrieval from internal systems, creating a path where server-side instructions can shape model behavior.
  • An AI agent invokes a ticketing tool, then receives a server-driven workflow update that changes the next step, requiring both sides of the interaction to be authenticated and bounded.
  • A support automation platform lets the client ask questions while the server can push policy guidance or remediation steps, which must be checked against approved trust policy.
  • A workflow bridge exposes database read access in one direction and webhook-triggered actions in the other, raising the need for explicit scoping and audit trails.
  • The Guide to the Secret Sprawl Challenge is relevant when either side can reach tokens or API keys that were never meant to be reused across trust domains, and the OAuth 2.0 Authorization Framework remains a useful reference point for separating delegated access from implicit trust.

Why It Matters in NHI Security

Bidirectional exposure matters because it widens the attack surface beyond the credential itself. When a server can prompt, steer, or trigger behavior, an attacker who compromises that server can exploit the client’s trust in ways that are harder to detect than a simple API abuse case. This is especially important for NHI governance because service accounts, API keys, and agent credentials often carry excessive privilege; NHI Management Group reports that 97% of NHIs carry excessive privileges, which magnifies the damage when bidirectional trust is left unbounded. The right control response is to treat each direction separately: authenticate both endpoints, constrain tool execution, validate server-originated instructions, and log all capability escalations. This is also where Zero Trust becomes operational rather than theoretical, because each action path must be re-authorized instead of assumed safe. Organisationally, this risk is often only recognised after prompt injection, unintended tool execution, or secret exposure has already occurred, at which point bidirectional capability exposure becomes operationally unavoidable to address.

For broader incident context, see the The 52 NHI breaches Report and the Anthropic — first AI-orchestrated cyber espionage campaign report, both of which underscore how agentic trust paths can be abused when capability boundaries are too loose.

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 Zero Trust (SP 800-207), NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 A2 Agent tool use and prompt influence are the core risk when capability flows in both directions.
OWASP Non-Human Identity Top 10 NHI-03 Bidirectional exposure expands NHI trust boundaries and authorization scope.
NIST Zero Trust (SP 800-207) SA Zero Trust requires continuous verification for each action path, not assumed trust.
NIST CSF 2.0 PR.AC-4 Least-privilege access and authorization review directly apply to bidirectional endpoints.
NIST AI RMF MAP This term is an AI system risk because the system can alter behavior through interactive pathways.

Restrict both client and server actions to the minimum authorized scope and review regularly.