Feature Request: Runtime Verification for MCP Pipelines in Haystack

[Correctover]

Background

I have analyzed security patterns across 53+ MCP server implementations and found recurring vulnerabilities: command injection, missing auth, path traversal, SSRF, and credential leakage. Many MCP servers expose tools without input/output validation.

Haystack has integrated MCP via Hayhooks (deepset-ai/hayhooks) which runs as an MCP Server exposing pipelines as tools. The typed Pipeline architecture is excellent for data flow validation, but MCP tool execution lacks a runtime verification layer.

Problem Statement

When Haystack pipelines are exposed as MCP tools via Hayhooks:

• Tool inputs from external MCP clients are not verified against pipeline parameter constraints before execution
• Pipeline outputs sent back to MCP clients are not validated
• There is no middleware to enforce security policies on MCP pipeline invocations

This creates risk for enterprise deployments where Haystack pipelines are publicly accessible via MCP.

Proposed Solution

A runtime verification middleware for MCP pipeline execution:

1. Define verification rules per pipeline (input validation, output sanitization, execution constraints)
2. Hook into Hayhooks MCP server to intercept tool calls before/after pipeline execution
3. Log violations and optionally reject non-compliant invocations

Integration points:

• A Hayhooks middleware wrapping pipeline execution
• A custom Haystack Component for MCP security validation
• Integration with Haystack's existing Pipeline.connect() validation at runtime

Implementation Effort

Minimal — adapter layer connecting verification rules to Haystack's pipeline abstraction.

I have published runtime verification on npm (correctover) and would contribute a PR.

Questions

1. Is runtime security for MCP-exposed pipelines on the roadmap?
2. What is the preferred extension point in Hayhooks for this?

Thank you for the excellent framework.

[Correctover]

Hi @haystack maintainers,

Following up on this feature request after 8 days. I understand you're busy, so let me provide additional context to help with prioritization:

Security Impact Demonstration

We've been building Correctover, a runtime verification layer for MCP tools, and found that Haystack's MCP pipeline has several attack vectors that runtime verification can catch:

1. Tool parameter injection: MCP servers returning crafted tool definitions that inject additional parameters
2. Result poisoning: Malicious MCP servers returning payloads that exploit downstream tool consumers
3. Schema bypass: Tools that bypass declared schemas through dynamic type coercion

Minimal Reproduction

Here's a concrete example we've verified against MCP-compatible servers:

# Malicious MCP server returning a tool that injects extra parameters
@server.tool()
async def vulnerable_tool(input: str) -> str:
    return input

# The tool result gets injected into Haystack's pipeline without validation
# An attacker can return crafted results that trigger downstream vulnerabilities

Questions for maintainers:

1. Would you be open to a community contribution for a MCPToolValidator component that verifies tool results against declared schemas?
2. Is there a preferred approach for integrating runtime verification into Haystack's existing pipeline architecture?
3. Should this be a separate component or integrated into the existing MCPTool wrapper?

We're happy to contribute a PR if there's alignment on the approach. The Correctover SDK (DOI: 10.5281/zenodo.21234580) provides the underlying verification primitives that could be adapted for Haystack's architecture.

Thanks for your time.