Notifications
Clear all
Topic starter
20/08/2026 5:30 pm
TL;DR: MCP filtering adds content-level inspection, modification, and blocking to AI tool calls, addressing the black-box gap left by access control alone, according to Obot. The governance issue is not just who can call a tool, but what data and instructions are allowed to flow through authorised MCP sessions.
NHIMG editorial — based on content published by Obot: MCP filtering for enterprise AI tool calls and the webhook filter system
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
Questions worth separating out
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools.
Q: Why do authorised MCP sessions still create data security risk?
A: Because approval to call a tool does not guarantee the payload is safe.
Q: What breaks when MCP filtering is missing from enterprise AI gateways?
A: The organisation loses visibility into the content layer of AI tool use.
Practitioner guidance
- Separate access control from payload inspection Define one control for who may call MCP tools and another for what data may pass through the call.
- Use a shim or proxy as the policy enforcement point Place filtering between the client and the MCP server so redaction, blocking, and logging happen before tool execution or response release.
- Log both request and response content decisions Record which payloads were modified, which were blocked, and which policy rule triggered the outcome.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Webhook filter configuration steps for MCP Server Shim deployments
- Examples of request and response payload transformation before tool execution
- How existing HTTP webhooks are adapted into MCP server-side filters
- Console-level attachment workflow for enabling filters on specific MCP servers
👉 Read Obot's analysis of MCP filtering for enterprise AI tool calls →
MCP filtering and enterprise AI tool calls: are controls keeping up?
Explore further
20/08/2026 6:17 pm
Content-level control is now mandatory for enterprise MCP governance. Access control alone cannot govern what an AI client decides to send inside an authorised session, and that gap becomes more dangerous as tool use scales. MCP filtering addresses the transaction itself, which is where policy violations, sensitive data exposure, and unsafe prompt-derived arguments actually occur. Practitioners should treat this as a separate control domain, not a feature request.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how immature baseline MCP governance still is.
A question worth separating out:
Q: How do teams decide whether to use filtering, access control, or both for MCP?
A: Use both. Access control prevents unauthorised connections and tool use, while filtering governs the data flowing through approved sessions. If either control is missing, enterprise MCP security remains incomplete because identity approval and content governance solve different problems.
👉 Read our full editorial: MCP filtering closes the content gap in enterprise AI tool calls
