What breaks when MCP activity is not inspected before and after execution?

Why This Matters for Security Teams

MCP is powerful precisely because it lets an agent or developer tool hand off work to external systems, but that same flexibility turns every request into a potential trust boundary. If activity is not inspected before execution, malicious prompts, unsafe tool parameters, and hidden instructions can reach the server unchecked. If output is not inspected after execution, the response itself can carry credentials, policy violations, or data the caller should never receive.

This is not a theoretical gap. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same operational issue: tool use must be governed as a live security decision, not a passive logging exercise. In NHIMG research on the Analysis of Claude Code Security, inspection failures are closely tied to unsafe automation paths that move too quickly for manual review. In practice, many security teams discover MCP abuse only after a workflow has already executed and the data has already moved.

How It Works in Practice

Effective MCP inspection requires controls on both sides of execution. Before the request reaches the server, inspect the tool call, parameters, embedded instructions, and requested scope. After execution, inspect the response for sensitive data, overbroad output, unexpected tool chaining, or content that violates policy. The goal is to make each call observable, enforceable, and attributable.

That usually means combining policy-as-code with runtime enforcement. Teams are increasingly evaluating requests against context-aware rules rather than static allowlists alone. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls supports this direction through access control, audit logging, and information flow enforcement. For MCP, the practical pattern is to treat the server as a broker that can reject, redact, or quarantine requests and responses before they continue downstream.

A workable inspection stack often includes:

• Pre-execution validation of prompt content, tool arguments, and identity context.
• Detection of prompt injection, command abuse, and attempts to expand scope.
• Post-execution filtering for secrets, tokens, credentials, and regulated data.
• Logging that preserves who requested the action, what tool was used, and what changed.
• Escalation paths for high-risk outputs that require human review or auto-blocking.

NHIMG’s Schneider Electric credentials breach is a useful reminder that exposed secrets are often discovered only after sensitive material has already crossed a boundary. These controls tend to break down when MCP servers are embedded inside fast-moving CI/CD pipelines because the automation is optimized for speed, not for inspection latency.

Common Variations and Edge Cases

Tighter inspection often increases latency and operational overhead, so organisations must balance security depth against developer throughput. That tradeoff becomes sharper when MCP is used for code generation, incident response, or chained agent workflows, where even small delays can affect usability.

Best practice is evolving for where inspection should happen. Some teams enforce controls at the client, some at the MCP gateway, and some at the server itself. The most resilient design usually uses all three layers, but there is no universal standard for this yet. The key is that inspection must be able to block both malicious inputs and unsafe outputs, not merely record them for later review.

Edge cases matter. A benign request can still become risky if the server response includes environment variables, API keys, or adjacent data the caller did not explicitly ask for. Likewise, a harmless prompt can trigger dangerous behavior when paired with stale credentials or overly broad tool permissions. This is why the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s agentic research treat tool mediation as a live control point, not a documentation exercise.

Inspection also weakens in environments with opaque vendor-hosted MCP implementations, where teams cannot reliably see request handling, response transformation, or logging fidelity. In those cases, the safest assumption is that anything not explicitly inspected may bypass policy.

Related resources from NHI Mgmt Group

• What breaks when IAM only logs AI agent activity after execution?
• What breaks when sensitive data is not inspected before an MCP tool response reaches an AI model?
• What breaks when MCP traffic is not inspected before AI agents receive financial data?
• What breaks when AI agents trust MCP tools after a single approval?