MCP-Tool-Governance: Wer welches Tool aufrufen darf, in einer Berechtigungsebene
Bündeln Sie externe MCP-Server hinter einem Gateway-/mcp-Endpunkt — Tool-Allow/Deny und Label-Filter je Key-Gruppe, mit vollständig auditierten Aufrufen / Verstößen / Sitzungen.
Worüber die Community tatsächlich klagt
Sobald ein Agenten-Framework an eine Reihe von MCP-Servern angebunden ist, sprießen Berechtigungen: Es gibt keine einheitliche Kontrolle darüber, wer welches Tool aufrufen darf, und keinen Audit-Trail, wenn etwas schiefgeht. Jeden Agenten separat zu konfigurieren verstreut Zugangsdaten und lässt Richtlinien auseinanderdriften.
„Wie beschränke ich Claude Code auf genau diese MCP-Tools“ ist eine wiederkehrende Frage für Plattformteams.
Wie GateLLM es macht
GateLLM liefert einen integrierten MCP-Proxy: Mehrere externe MCP-Tool-Server (streamable HTTP / SSE) werden hinter einem /mcp-Endpunkt gebündelt, wobei Endpunkt, Auth-Header (wortgetreu weitergeleitet), Labels, Priorität und Lazy Loading einmalig konfiguriert werden. Key-Gruppen governen Tools mit Allow-/Deny-Listen (Deny gewinnt) und Label-Filtern — dieselbe ACL-Ebene, die auch Modelle governiert.
Wenn die Tool-Liste lang wird, kürzen Kontextbudgets sie, und integriertes BM25-Retrieval findet die relevanten Tools. MCP-Tool-Aufrufe, Verstöße gegen Zugriffsregeln und Sitzungsaufbau landen alle im Audit-Log.
MCP-Server-Zugangsdaten erreichen den Agenten nie: Tool-Zugriff wird mit der Gateway-Key-Gruppe gewährt und widerrufen.
5 Hebel, die tatsächlich wirken
- Server-Bündelung: streamable-HTTP-/SSE-MCP-Server hinter einem /mcp-Endpunkt
- Lazy Loading: Tools werden bei der ersten Nutzung entdeckt, was Startkosten und Angriffsfläche senkt
- Tool-ACL: Allow/Deny je Key-Gruppe, Deny überstimmt Allow, Label-Filter in großen Mengen
- Kontextbudget + BM25: lange Tool-Listen werden auf das Budget gekürzt, relevante Tools per Suche gefunden
- Vollständiges Audit: Tool-Aufrufe / Zugriffsverstöße / Sitzungsaufbau protokolliert und exportierbar