MCP tool-call exposure is the risk that an AI agent retrieves or forwards sensitive content, including secrets, through connected tools and places it into model context. It matters because the AI layer can bypass traditional DLP paths while still handling live credentials.
Expanded Definition
MCP tool-call exposure describes a failure mode in Model Context Protocol deployments where an AI agent, through a connected tool, retrieves secrets or other sensitive data and places that material into model context. The exposure is not limited to data at rest. It can occur during live tool execution, response chaining, or intermediary logging, which makes the risk distinct from conventional application leakage.
In practice, the concern is not just that a tool can read data, but that the agent can carry that data into prompts, memory, traces, or downstream tool calls. That creates a control gap between traditional DLP and agent execution paths, which is why the industry’s guidance is still evolving. For a standards-oriented view of tool permissions and least privilege, the OWASP Top 10 for Agentic Applications 2026 is the closest external reference point today, even though no single standard governs MCP tool-call exposure yet. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly credentials become difficult to govern once they are replicated across systems and workflows.
The most common misapplication is assuming that if a tool is “internal,” any secret it returns is safe to pass into model context, which occurs when teams treat agent execution like a normal backend integration.
Examples and Use Cases
Implementing MCP tooling rigorously often introduces friction, because every tool response must be evaluated for sensitivity before the agent is allowed to continue, forcing organisations to weigh agent capability against context hygiene.
- An incident-response agent queries a configuration store and pulls an API key into the conversation transcript, where it becomes visible to later prompts and logs.
- A support copilot uses an MCP connector to retrieve customer metadata, then forwards a tokenized record into another tool that was never meant to see privileged values.
- A developer-assist agent inspects a secret manager, but the tool wrapper returns raw credentials instead of redacted metadata, creating avoidable exposure in model context.
- A workflow agent chains multiple tools and accidentally propagates a certificate private key from one step into a summarization step, which is then archived in traces.
- Research into MCP server security by The State of MCP Server Security 2025 found that only 18% of deployments implement any form of access scoping for tool permissions, which explains why exposure often begins with over-broad tool design.
These patterns align with broader agentic risk described in the OWASP Agentic AI Top 10, especially where tool output is not filtered before it enters model memory.
Why It Matters in NHI Security
MCP tool-call exposure turns a working automation layer into a credential distribution channel. Once secrets enter model context, they may be reused by the agent, echoed into logs, captured in telemetry, or forwarded into additional tools that were never part of the original trust decision. That breaks the assumptions behind secret scoping, zero standing privilege, and classic DLP boundaries.
The governance impact is immediate because accountability becomes murky after the fact. NHIMG research on AI agent risk reports that only 52% of companies can track and audit the data their agents access, leaving 48% with a blind spot for compliance and breach investigation, and 33% say their agents have already accessed inappropriate or sensitive data beyond intended scope. The same pattern appears in NHIMG’s 52 NHI Breaches Analysis, where identity misuse repeatedly follows weak containment around privileged workflows. For implementation context, the Anthropic cyber espionage report illustrates how agentic systems can be operationalized in ways that multiply downstream risk when tool boundaries are loose.
Organisations typically encounter MCP tool-call exposure only after a secret is replayed, exfiltrated, or misused in an audit trail, at which point the exposure path 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 Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses secret exposure and improper handling in non-human identity workflows. |
| OWASP Agentic AI Top 10 | Covers agent tool abuse and unsafe context propagation risks. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is directly implicated by MCP tool permissions. |
| NIST Zero Trust (SP 800-207) | SC-1 | Zero Trust requires explicit trust decisions for each tool-mediated access path. |
| NIST AI RMF | AI risk management covers leakage through model inputs, outputs, and orchestration paths. |
Redact tool outputs, scope permissions, and prevent secrets from entering model context.
Related resources from NHI Mgmt Group
- How should security teams govern OpenAPI-to-MCP tool exposure?
- Who is accountable when an MCP tool call is authorised through a gateway and fails downstream?
- What is the difference between RAG access and MCP tool access?
- How should security teams handle tool discovery for AI agents in MCP environments?
