Block responses when the payload contains data that should never reach an LLM context, such as health records or financial account numbers. Redaction is better when the workflow still needs the record but not the sensitive fields. The decision should be based on data class and use case.
How to choose between blocking and redacting MCP tool responses
The right control depends on whether the model needs the record at all. If the entire response would expose secrets, personal data, regulated data, or other content that should never enter model context, blocking is safer. If the workflow still needs the record for reasoning or completion, but only certain fields are sensitive, redaction preserves utility while reducing exposure.
The practical distinction is that blocking removes the whole payload from the LLM path, while redaction changes the payload so the model can continue with a safer version. That means the decision is not about preference, it is about whether any safe version of the response still exists for the task.
This matters in MCP because tool responses can carry downstream trust into agentic workflows. When tool output is fed into an assistant, a coding agent, or an orchestration layer, the response may influence follow-on actions, so the safety boundary has to be placed before the data reaches the model context. Guidance on MCP authorization and token handling in the MCP authorization specification is relevant here because the transport and token model affect what should be passed through at all.
What makes a payload a block candidate instead of a redaction candidate?
Block the response when the payload is inherently unsafe for model consumption, not merely inconvenient. Common examples include full health records, financial account numbers, authentication material, session tokens, or other data where any exposure to the model creates unacceptable confidentiality or compliance risk. In those cases, redaction may still leave enough structure to be useful, but it does not solve the core problem if the sensitive content itself is the substance of the record.
Redaction fits when the model needs the object, transaction, or status, but not the sensitive fields inside it. For example, a support workflow may need the case history, timestamps, and error codes, while removing customer identifiers or payment details. The key test is whether the remaining data still supports the use case without forcing the model to see the protected fields.
The choice also depends on whether the tool output is a direct source of truth or just a transient input to a larger process. If the response is likely to be cached, logged, summarised, or reused by downstream agents, blocking becomes more attractive because the exposure surface expands beyond the immediate prompt. That is especially important for MCP environments where multiple tools and agent steps can chain together.
How to operationalise the decision at the boundary
Classify the response before it reaches the model, not after it has already been parsed by the assistant. If the tool result belongs to a prohibited data class, terminate the exchange or substitute a safe failure message. If the response is partially sensitive, redact at the source or at a trusted gateway so the model only ever receives the least sensitive representation needed for the task.
It also helps to separate “needs the record” from “needs the values.” Many teams over-redact and break the workflow, then reintroduce risk through manual workarounds. A better pattern is to preserve identifiers, state, and metadata where they are operationally necessary, while suppressing fields that would expand the blast radius if exposed.
Where MCP tools touch identity or credential material, stronger controls are warranted because a single response can become a reusable access path. NHIMG’s NHI Authentication Guide is useful for the broader decision around how machine-authenticated systems should handle secrets, and the MCP Security Guide covers the authorisation and token-passthrough issues that often determine whether a response should be forwarded, transformed, or stopped.
Risk and Threat Considerations
Tool responses are a common place for sensitive data to leak into model context, logs, summaries, and follow-on actions. The main risk is not just disclosure to the current LLM, but persistence and propagation across later steps, retrievers, or agent outputs. If the payload contains direct identifiers or credentials, redaction may be insufficient because the original value can still be inferred, cached, or mishandled elsewhere.
Failure mechanism: The tool returns more data than the model needs, and that data is then copied into prompts, traces, memory, or downstream tool calls. In agentic pipelines, the response can also be used as a trigger for an unsafe action if it contains commands, credentials, or trusted business data.
Impact: Organisations can expose regulated data, enable account compromise, or create accidental data propagation across multi-step workflows. Once sensitive content enters model context, the blast radius is often larger than the original tool call.
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 API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool outputs can carry privileged data into agent workflows. |
| ASI02 — Tool Misuse | Blocking versus redaction is a control on unsafe tool output use. | |
| Recommendation — Restrict tool outputs so agents only receive data required for the task. Validate tool responses before they can influence agent actions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP responses often carry tokens or auth-linked data that must not be exposed. |
| Recommendation — Prevent auth material from reaching consumers that do not need it. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Only the minimum necessary data should reach the model context. |
| Recommendation — Limit data exposure to the minimum needed for each workflow step. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Blocking or redaction depends on data class and handling requirements. |
| Recommendation — Classify response data so handling rules match sensitivity. | ||
Practitioner Guidance
Decision rule: If the tool response contains data that would be unacceptable in a prompt, block it; if the workflow can still complete with the sensitive fields removed, redact it. Treat “can the model still do useful work?” as the redaction test, and “would any exposure be unacceptable?” as the blocking test.
What to verify: Confirm that the enforcement point sits before prompt assembly, not after. Also verify that redacted outputs cannot be reconstructed from adjacent fields, error messages, or logs, because partial masking often gives a false sense of safety.
What practitioners underestimate: MCP tool responses are not just content, they are potential trust inputs. The safest implementation is the one that prevents unusable sensitive data from entering model context in the first place, while keeping only the minimum structure needed for the task.
Practitioner takeaway: Block when the content itself is too sensitive to enter the model path; redact only when the remaining record is still operationally sufficient and the sensitive fields can be removed without weakening the workflow.
Related resources from NHI Mgmt Group
- When should organisations block autonomous agent actions instead of monitoring them?
- Should organisations block local MCP servers or govern them differently?
- What breaks when organisations rely on standard DLP controls instead of MCP-layer inspection for AI agent tool calls?
- How do organisations decide whether to block, redact, or allow MCP responses from AI agents?