Skip to content

Conversation

@JAORMX
Copy link
Contributor

@JAORMX JAORMX commented Jan 12, 2026

Summary

Port proposal from toolhive PR #2300.

Introduces a dynamic webhook middleware system for ToolHive that enables external services to participate in the MCP request pipeline, inspired by Kubernetes admission webhooks.

Problem

Organizations need to integrate ToolHive with existing enterprise systems (policy engines, SIEM, ticketing, HR, CMDB) but currently require forking ToolHive and maintaining custom builds to add new middleware functionality.

Solution

Two new webhook types:

  • Validating webhooks: Accept/deny requests based on external policy decisions
  • Mutating webhooks: Transform requests (enrich with context, redact PII, etc.)

Key Features

  • Multiple webhooks with sequential execution (pipeline pattern)
  • File-based CLI configuration (--webhook-config webhook.yaml)
  • Kubernetes MCPWebhookConfig CRD for operator
  • TLS/mTLS support with file-based certificates
  • Configurable failure policies (fail-open/fail-closed)
  • Full observability (Prometheus metrics, audit logs, OpenTelemetry tracing)
  • Versioned protocol (version: v0.1.0) for evolution

Use Cases

  1. External Policy Engine Integration - Use OPA or custom policy engines
  2. Request Enrichment - Add context from HR/CMDB systems
  3. Approval Workflows - Require manager approval for high-risk operations
  4. SIEM Integration - Send custom-formatted logs to enterprise SIEM
  5. Rate Limiting - Enforce limits using external rate limiters
  6. PII Redaction - Remove sensitive data before processing

Architecture

Webhooks integrate into existing middleware chain:

  1. Authentication -> 2. Token Exchange -> 3. MCP Parser -> 4. Tool Filter -> 5. Mutating Webhooks -> 6. Validating Webhooks -> 7. Telemetry -> 8. Authorization -> 9. Audit

Multiple webhooks execute sequentially in configuration order.

jhrozek
jhrozek previously approved these changes Jan 15, 2026
Copy link
Contributor

@jhrozek jhrozek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is great, I left some questions inline, but I'd love to see this along with some example webhooks implemented.

JAORMX and others added 3 commits January 16, 2026 14:12
Port proposal from toolhive PR #2300. This RFC introduces a dynamic
webhook middleware system inspired by Kubernetes admission webhooks,
enabling external services to participate in the MCP request pipeline.

Signed-off-by: Juan Antonio Osorio <ozz@stacklok.com>
Signed-off-by: Juan Antonio Osorio <ozz@stacklok.com>
- Add HMAC payload signing to Security section (defense-in-depth)
- Wrap MCP payload in mcp_request container for mutating webhooks
- Add mcp_version field to webhook request formats
- Clarify vMCP context fields (server_name vs backend_server)
- Add signing_secret_ref to configuration examples
- Promote HMAC signing to Phase 1, remove from Phase 3

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@JAORMX JAORMX force-pushed the rfc/dynamic-webhook-middleware branch from 1b8ba30 to 0d6157b Compare January 16, 2026 12:46
@JAORMX
Copy link
Contributor Author

JAORMX commented Jan 16, 2026

Addressed all the feedback! Here's a quick summary:

  • HMAC Signing: Added payload signing with X-ToolHive-Signature header, promoted to Phase 1
  • mcp_request container: Wrapped MCP payload so mutations can't touch principal/context
  • MCP version: Added mcp_version field to both request formats
  • vMCP context: Split into server_name (vMCP instance) and backend_server (actual MCP server)
  • signing_secret_ref: Added to config examples

Thanks for the thorough review @jhrozek!

@JAORMX JAORMX merged commit 8458f38 into main Jan 19, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants