AgentShield: Runtime security guard for Haystack pipeline tool calls

[hidearmoon]

Hi Haystack community!

We've open-sourced AgentShield, a runtime security layer for AI agents that intercepts tool calls before execution. We think it's a natural fit for Haystack pipelines where agents invoke tools.

The problem

When a Haystack agent processes external data (emails, web pages, RAG documents) and has access to tools, a prompt injection hidden in that data can trick the agent into misusing tools — sending unauthorized emails, exfiltrating data, or executing malicious code.

How AgentShield helps

Every tool call passes through a multi-layer security pipeline:

1. Trust-aware data flow — External data gets tagged with lower trust levels. Sensitive tools are automatically restricted when the agent is processing untrusted data.
2. 3-layer intent consistency — Rule Engine (μs) → Anomaly Detector (μs) → Semantic Checker (ms). Most checks complete in microseconds without any LLM call.
3. 22 built-in security rules — Covering injection defense, data exfiltration, privilege escalation.
4. Policy DSL — Define custom rules in YAML.

Integration with Haystack

AgentShield can integrate as a pipeline component that wraps tool-calling nodes:

from agentshield import Shield

shield = Shield(api_key="your-key")

@shield.guard
async def my_tool(query: str) -> str:
    return db.execute(query)

Or as a pre-execution guard in custom components that checks tool name + params against policy before forwarding to the actual tool.

We also have a transparent sidecar proxy mode that requires zero code changes — it intercepts HTTP traffic between the agent and tool services.

Links

• GitHub (Apache 2.0, 342 tests including 92 security tests)
• Python SDK with LangChain, CrewAI, AutoGen integrations
• Existing integrations for OpenClaw, MCP, Dify, AutoGPT, n8n

Would love to hear from Haystack users about your security concerns with agent tool execution. Happy to build a dedicated Haystack component if there's interest.

[musaabhasan]

For Haystack, the most useful integration pattern would probably be a first-class pre-tool component rather than only a decorator around individual tools.

The reason is that the guard needs context beyond the function call itself. A good decision normally depends on:

• the current pipeline state,
• whether the retrieved/input content came from an external or trusted source,
• the proposed tool name and parameters,
• the user/session identity,
• the data classification of both input and output,
• whether the action is read-only or has an external side effect.

I would model the guard as producing a structured decision object, for example allow, block, require_approval, or redact_then_allow, with a reason code and evidence fields. That makes it much easier to test, log, and review than a boolean wrapper.

One design point I would be careful with is fail-open behavior. It is acceptable for low-risk read-only tools, but for tools that send email, modify records, call external APIs, execute code, or access confidential data, the default should be configurable and preferably fail-closed or require human approval.

A dedicated Haystack component could also make trust labels explicit in document metadata. For example, retrieved documents from web/email uploads could carry trust_level=external, while curated internal policy docs carry trust_level=approved. The tool guard can then enforce different policies without relying only on semantic intent detection.

In short: this is a valuable control point, but I would make the integration policy-driven, context-aware, auditable, and risk-tiered by tool impact.