AM

abluva/mcp-trust-plane

Developer tools

Эта страница переведена автоматически. Технические детали смотрите в оригинале. Открыть оригинал

101 stars 26 forks Качество 67 Тренд 19Apache-2.0

abluva/mcp-trust-plane — это кандидат на MCP-сервер, импортированный из https://github.com/abluva/mcp-trust-plane.

Обзор

abluva/mcp-trust-plane — это кандидат на MCP-сервер, импортированный из https://github.com/abluva/mcp-trust-plane.

Обзор (машинный перевод)

Подключаемый, независимый от языка фильтрующий фреймворк для протокола Model Context Protocol (MCP) трафик. Каждый фильтр — это крошечный HTTP-сервис, который решает, Вызов инструмента должен быть разрешен, заблокирован, изменён или усечен.

Почему

MCP предоставляет агентам прямой доступ к инструментам и источникам данных. Это мощно и опасные в равной степени. Фильтры дают место для контроля ограничители — блокируют разрушительный SQL, редактируют PII до того, как они достигнут модели, агенты, злоупотребляющие дросселью, размеры отклика лимита, колонки редактирования — без изменения восходящего MCP-сервера или времени выполнения агентов.

Как это работает

  • MCP-шлюз расположен перед восходящим MCP-сервером.
  • Для каждого tools/call шлюз спрашивает движок «что мне делать для цели X в execution_point Y?».
  • Движок ищет политики, назначенные этой цели, и для каждой фильтруйте эти политики, вызывает POST {filter_url}/filter.
  • Фильтры — это полностью независимые процессы. Их можно записывать в на любом языке. Они не разделяют состояние ни с шлюзом, ни с движком.

В родительском репозитории находятся эталонный движок и шлюз (secure-ai-plane-x/mcp-filter-gateway). Этот подпроект выпускает только реализации фильтров и контракта.

Эта страница переведена автоматически. Технические детали смотрите в оригинале.

README

Показан фрагмент оригинального README. Открыть оригинал.

MCP Trust Plane

A pluggable, language-agnostic filter framework for Model Context Protocol (MCP) traffic. Each filter is a tiny HTTP service that decides whether a tool call should be allowed, blocked, modified, or truncated.

Why

MCP gives agents direct access to tools and data sources. That’s powerful and dangerous in equal measure. Filters give you a place to enforce guardrails — block destructive SQL, redact PII before it reaches the model, throttle abusive agents, cap response sizes, redact columns — without modifying the upstream MCP server or the agent runtime.

How it works

                    pre-request                       post-response
   Client ─▶ MCP Gateway ─────────▶ Engine ─▶ filter ─┐
                │     ◀────────────────── allow/block ┘
                │
                ▼ (forward)
            MCP Server
                │
                ▼
   Client ◀ MCP Gateway ◀──── Engine ─▶ filter ─┐
                                ◀───── allow/truncate/modify ┘
  • An MCP gateway sits in front of the upstream MCP server.
  • For every tools/call, the gateway asks an engine “what should I do for target X at execution_point Y?”.
  • The engine looks up the policies assigned to that target and, for each filter in those policies, calls POST {filter_url}/filter.
  • Filters are completely independent processes. They can be written in any language. They share no state with the gateway or the engine.

A reference engine and gateway live in the parent repo (secure-ai-plane-x/mcp-filter-gateway). This sub-project ships only the filter implementations and the contract.

The Filter Contract

Every filter MUST expose two HTTP endpoints:

POST /filter

Request body:

{
  "config":    { "max_rows": 1000 },
  "arguments": {
    "sql": "SELECT * FROM employees",
    "response_count": 8000,
    "response_rows": ["row-1", "row-2", "..."]
  },
  "metadata": {
    "agent_id":   "demo_agent",
    "agent_name": "demo_agent",
    "member_id":  "f5d9e4ec-…",
    "project_id": "b0000000-…",
    "tool_name":  "run_sql"
  }
}

Response body:

{
  "action": "allow | block | truncate | modify",
  "reason": "human-readable string surfaced to the user and audit log",
  "modified_response": { "...optional..." },
  "original_count":    8000,
  "truncated_to":      1000
}
  • allow — let the request through unchanged.
  • block — reject. The gateway returns an MCP error using reason.
  • truncate — return a smaller payload (modified_response) and an audit notice. Used by post-response filters like Row Limiter.
  • modify — replace the payload with modified_response. Used by redactors and maskers.

Filters MUST be idempotent and side-effect free with respect to the agent’s behaviour (with the obvious exception of audit / rate limiter state). Filter execution time should stay under 50ms p95; the engine treats slow filters as allow to fail-open.

GET /health

Открыть полный README на GitHub

Установка

This server does not publish a one-line install command.

Open the repository installation guide Новичок в MCP? Начните с руководства на mcpskill.org →