KI-Agenten entwickeln sich rasant von Forschungsdemos zu echten Unternehmensanwendungen, die große Sprachmodelle (LLMs) mit Unternehmensdaten und -diensten verbinden. Ein gängiger Ansatz ist der Einsatz von Tools oder Plugins, um einem LLM Kontext abzurufen oder Aktionen auszuführen – manche bezeichnen diese jedoch abfällig als bloße „glorifizierte API-Aufrufe“. In Wahrheit ist die sichere Integration von KI in Geschäftssysteme weitaus komplexer. Hier kommt das Model Context Protocol (MCP) ins Spiel, und genau deshalb ist eine robuste Proxy-Architektur mit OpenID Connect (OIDC)-Identität für Enterprise-Deployments unverzichtbar. Wer sich mit Anpassungsprimitiven für Agenten beschäftigt, findet in meinem umfassenderen Leitfaden zu Claude Skills vs MCP einen guten Einstieg.
\ngraph TB\n User[User] --> |interacts with| AIAgent[AI Agent]\n AIAgent --> |MCP requests| Proxy[API Gateway/Proxy]\n Proxy --> |authenticates via| OIDC[Identity Provider/OIDC]\n Proxy --> |routes to| Tools[MCP Tools/Servers]\n Tools --> |access| Backend[Backend Systems]\n \n subgraph \"Security Perimeter\"\n Proxy\n OIDC\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,OIDC security;\nDas obige Diagramm zeigt die Architektur einer sicheren MCP-Implementierung auf hoher Ebene. Im Kern positioniert diese Architektur ein API-Gateway/Proxy als zentralen Sicherheitskontrollpunkt zwischen KI-Agenten und MCP-Tools. Der Proxy arbeitet zusammen mit einem Identity Provider, der OIDC unterstützt, um einen Sicherheitsperimeter zu schaffen, der Authentifizierung, Autorisierung und Zugriffskontrollen durchsetzt. Dadurch wird sichergestellt, dass alle MCP-Anfragen von KI-Agenten ordnungsgemäß authentifiziert und autorisiert werden, bevor sie die eigentlichen MCP-Tools erreichen, die wiederum auf verschiedene Backend-Systeme zugreifen.
\nMCP ist ein offener Standard (ursprünglich von Anthropic eingeführt), der KI-Assistenten eine konsistente Möglichkeit bietet, mit externen Datenquellen und Tools zu interagieren. Statt maßgeschneiderter Integrationen für jedes System fungiert MCP wie ein universeller Konnektor, der es KI-Modellen ermöglicht, Kontext abzurufen oder Aufgaben über eine standardisierte JSON-RPC-Schnittstelle auszuführen. Wichtig ist, dass MCP von Grund auf mit Sicherheit im Blick entwickelt wurde – nichts wird der KI standardmäßig offengelegt, sie erhält nur Zugriff auf das, was explizit erlaubt wird. In der Praxis erfordert die Einhaltung dieses „Allow-List“-Prinzips über viele Tools und Benutzer hinweg jedoch sorgfältige Infrastruktur. Ein produktionsreifes API-Gateway (Proxy) kann als Torwächter zwischen KI-Agenten (MCP-Clients) und den Tools oder Datenquellen (MCP-Servern) dienen und dabei Authentifizierung, Autorisierung und Routing-Regeln durchsetzen.
\nBevor wir zur Lösung kommen, ein kurzer Hinweis zu Envoy: Es gibt aktive Vorschläge, Envoy Proxy als Referenzimplementierung eines MCP-Gateways zu nutzen. Envoys umfangreiches L7-Routing und seine Erweiterbarkeit machen ihn zu einem starken Kandidaten, und möglicherweise wird er bald eine erstklassige MCP-Unterstützung bieten. Dennoch ist das hier diskutierte Muster Proxy-agnostisch – jeder moderne HTTP-Reverse-Proxy oder API-Gateway (Envoy, NGINX, HAProxy, Kong usw.), der ähnliche Fähigkeiten bietet, kann verwendet werden. Ziel ist es, eine sichere Architektur für MCP zu skizzieren, nicht die Details der Envoy-Konfiguration.
\nAuf den ersten Blick mag die Nutzung eines KI-Tools über MCP so einfach erscheinen wie ein Web-API-Aufruf. In einer einfachen Demo könnte ein LLM-Agent einen REST-Endpunkt aufrufen, etwas JSON erhalten, und das war's. In einem echten Unternehmensszenario geschieht jedoch weitaus mehr im Hintergrund:
\ngraph LR\n subgraph \"Simple API Call\"\n A[Client] -->|Request| B[API]\n B -->|Response| A\n end\n \n subgraph \"Enterprise MCP Reality\"\n C[User] -->|Interacts| D[AI Agent]\n D -->|MCP Request with Identity| E[API Gateway]\n E -->|Validate Token| F[Identity Provider]\n E -->|Route Request| G[Tool Registry]\n E -->|Authorized Request| H[MCP Tool]\n H -->|Query with User Context| I[Backend System]\n I -->|Data| H\n H -->|Response| E\n E -->|Filtered Response| D\n D -->|Result| C\n \n J[Security Monitoring] -.->|Audit| E\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class E,F,G,J security;\nDieses Diagramm stellt einen einfachen API-Aufruf der komplexen Realität einer Enterprise-MCP-Implementierung gegenüber. Im einfachen Fall stellt ein Client eine direkte Anfrage an eine API und erhält eine Antwort. In der Enterprise-MCP-Realität ist der Ablauf jedoch wesentlich komplexer:
\nWährend dieses gesamten Prozesses überwachen Sicherheitsüberwachungssysteme die Interaktionen auf Gateway-Ebene. Dieser umfassende Ablauf stellt sicher, dass Benutzeridentität, Berechtigungen und Sicherheitsrichtlinien in jedem Schritt durchgesetzt werden – weit über das hinaus, was ein einfacher API-Aufruf beinhaltet.
\nKurz gesagt: Ein Unternehmen muss KI-Tool-Integrationen mit der gleichen Strenge behandeln wie jede andere Produktionsdienst-Integration – wenn nicht noch strenger. Eine ordnungsgemäße Gateway-Schicht hilft, diese Bedenken zu adressieren, indem sie als zentraler Kontrollpunkt fungiert. Anstatt Vertrauen in jeden KI-Agenten oder jedes Tool hart zu codieren, erzwingt der Proxy unternehmensweite Sicherheitsrichtlinien. Dieser Ansatz führt uns jenseits der „einfach eine API aufrufen“-Mentalität zu einem strukturierten Modell, in dem jeder MCP-Aufruf authentifiziert, autorisiert, überwacht und auditiert wird.
\nLassen Sie uns einige spezifische Sicherheitsherausforderungen betrachten, die beim MCP-Deployment im großen Maßstab entstehen, und warum sie wichtig sind:
\ngraph TD\n A[Context Poisoning] --> |mitigated by| B[Content Filtering]\n A --> |mitigated by| C[Tool Verification]\n \n D[Identity Propagation] --> |solved with| E[Token-based Auth]\n D --> |solved with| F[Delegation Chains]\n \n G[Dynamic Tool Provisioning] --> |managed by| H[Tool Registry]\n G --> |managed by| I[Approval Workflows]\n G --> |managed by| J[Version Tracking]\n \n K[Remote MCP Changes] --> |controlled by| L[Proxy Governance]\n \n subgraph \"Proxy Security Controls\"\n B\n C\n E\n F\n H\n I\n J\n L\n end\n \n classDef challenge fill:#f66,stroke:#333,stroke-width:2px;\n classDef solution fill:#6f6,stroke:#333,stroke-width:2px;\n \n class A,D,G,K challenge;\n class B,C,E,F,H,I,J,L solution;\nDieses Diagramm ordnet die zentralen Sicherheitsherausforderungen in MCP-Workflows (in Rot dargestellt) den entsprechenden Lösungen (in Grün dargestellt) zu, die innerhalb der Proxy-Sicherheitskontrollen implementiert werden können. Das Diagramm veranschaulicht, wie:
\nDurch die Implementierung dieser Kontrollen innerhalb der Proxy-Schicht können Organisationen diese Sicherheitsherausforderungen zentralisiert und konsistent angehen, anstatt sie für jedes Tool oder jeden Agenten individuell lösen zu müssen.
\nsequenceDiagram\n participant User\n participant AIAgent as AI Agent\n participant Proxy as API Gateway\n participant IdP as Identity Provider\n participant Tool as MCP Tool\n participant Backend as Backend System\n \n User->>IdP: 1. Authenticate (username/password)\n IdP->>User: 2. Issue OIDC token\n User->>AIAgent: 3. Interact with AI (token attached)\n AIAgent->>Proxy: 4. MCP request with token\n Proxy->>IdP: 5. Validate token\n IdP->>Proxy: 6. Token valid, contains claims/scopes\n \n alt Token Valid with Required Permissions\n Proxy->>Tool: 7. Forward request with user context\n Tool->>Backend: 8. Query with delegated auth\n Backend->>Tool: 9. Return data (filtered by user permissions)\n Tool->>Proxy: 10. Return result\n Proxy->>AIAgent: 11. Return authorized response\n AIAgent->>User: 12. Present result\n else Token Invalid or Insufficient Permissions\n Proxy->>AIAgent: 7. Reject request (401/403)\n AIAgent->>User: 8. Report access denied\n end\nDieses Sequenzdiagramm veranschaulicht den Authentifizierungs- und Autorisierungsablauf in einem MCP-System unter Verwendung von OIDC. Der Prozess beginnt damit, dass sich der Benutzer beim Identity Provider authentifiziert und ein OIDC-Token erhält. Dieses Token wird dann an die Interaktionen des Benutzers mit dem KI-Agenten angehängt. Wenn der Agent eine MCP-Anfrage stellt, enthält er dieses Token, das das API-Gateway beim Identity Provider validiert.
\nWenn das Token gültig ist und die erforderlichen Berechtigungen (Claims/Scopes) enthält, wird die Anfrage zusammen mit dem Benutzerkontext an das entsprechende MCP-Tool weitergeleitet. Das Tool kann dann Backend-Systeme unter Verwendung delegierter Authentifizierung abfragen und stellt so sicher, dass die zurückgegebenen Daten gemäß den Benutzerberechtigungen gefiltert werden. Das Ergebnis fließt zurück durch das System zum Benutzer.
\nWenn das Token ungültig ist oder unzureichende Berechtigungen hat, wird die Anfrage auf Gateway-Ebene mit einem entsprechenden Fehlercode (401 Unauthorized oder 403 Forbidden) abgelehnt, und der KI-Agent meldet diese Zugriffsverweigerung dem Benutzer.
\nDieser Ablauf stellt sicher, dass Benutzeridentität und Berechtigungen durch die gesamte Interaktionskette hinweg konsistent durchgesetzt werden und unautorisierter Zugriff auf sensible Daten oder Operationen verhindert wird.
\nsequenceDiagram\n participant Admin\n participant Registry as Tool Registry\n participant Proxy as API Gateway\n participant Tool as New MCP Tool\n participant AIAgent as AI Agent\n \n Admin->>Tool: 1. Develop new MCP tool\n Admin->>Registry: 2. Register tool (metadata, endpoints, auth requirements)\n Registry->>Registry: 3. Validate tool configuration\n Registry->>Proxy: 4. Update routing configuration\n \n Note over Registry,Proxy: Tool is now registered but not yet approved\n \n Admin->>Registry: 5. Approve tool for specific user groups\n Registry->>Proxy: 6. Update access policies\n \n Note over AIAgent,Proxy: Tool is now available to authorized users\n \n AIAgent->>Proxy: 7. Discover available tools\n Proxy->>AIAgent: 8. Return approved tools for user\n AIAgent->>Proxy: 9. Call new tool\n Proxy->>Tool: 10. Route request if authorized\nDieses Sequenzdiagramm veranschaulicht den Workflow zur Tool-Registrierung und -Genehmigung in einer sicheren MCP-Umgebung. Der Prozess beginnt damit, dass ein Administrator ein neues MCP-Tool entwickelt und es in der Tool Registry registriert, wobei Metadaten, Endpunkte und Authentifizierungsanforderungen bereitgestellt werden. Die Registry validiert die Tool-Konfiguration und aktualisiert die Routing-Konfiguration im API-Gateway.
\nZu diesem Zeitpunkt ist das Tool registriert, aber noch nicht zur Nutzung freigegeben. Der Administrator muss das Tool explizit für bestimmte Benutzergruppen genehmigen, was eine Aktualisierung der Zugriffsrichtlinien im API-Gateway auslöst. Erst dann wird das Tool für autorisierte Benutzer verfügbar.
\nWenn ein KI-Agent über den Proxy verfügbare Tools entdeckt, erhält er nur Informationen über Tools, die für den aktuellen Benutzer genehmigt wurden. Wenn der Agent das neue Tool aufruft, leitet der Proxy die Anfrage nur dann an das Tool weiter, wenn der Benutzer autorisiert ist, darauf zuzugreifen.
\nDieser Workflow stellt sicher, dass neue Tools eine ordnungsgemäße Prüfung und Genehmigung durchlaufen, bevor sie genutzt werden können, und dass der Zugriff auf autorisierte Benutzer beschränkt ist. Er zentralisiert auch den Tool-Governance-Prozess und erleichtert die sichere Verwaltung des Lebenszyklus von MCP-Tools.
\nDurch das Erkennen dieser Herausforderungen können Sicherheitsingenieure und Architekten Verteidigungsmaßnahmen entwerfen, bevor Probleme auftreten. Als Nächstes betrachten wir, wie ein identitätsbewusster Proxy diese Verteidigungsmaßnahmen auf saubere, zentralisierte Weise bereitstellen kann.
\nEin bewährtes Design in Cloud-Architekturen ist das Platzieren eines Reverse-Proxys (oft als API-Gateway bezeichnet) vor den eigenen Diensten. MCP-basierte KI-Systeme sind da keine Ausnahme. Durch die Einführung eines intelligenten Proxys zwischen KI-Agenten (Clients) und den MCP-Servern (Tools/Backends) schaffen wir einen kontrollierten Trichter, durch den der gesamte KI-Tool-Traffic fließt. Dieser Proxy kann auf Layer 7 (Anwendungsschicht) operieren, was bedeutet, dass er HTTP und sogar JSON-Payloads versteht und so eine feingranulare Kontrolle ermöglicht. Nachfolgend skizzieren wir die zentralen Rollen, die ein solcher Proxy bei der Absicherung von MCP spielt:
\ngraph TB\n subgraph \"Client Side\"\n User[User]\n AIAgent[AI Agent]\n User -->|interacts| AIAgent\n end\n \n subgraph \"Security Layer\"\n Proxy[API Gateway/Proxy]\n Auth[Authentication]\n RBAC[Authorization/RBAC]\n Registry[Tool Registry]\n Audit[Audit Logging]\n \n Proxy -->|uses| Auth\n Proxy -->|enforces| RBAC\n Proxy -->|consults| Registry\n Proxy -->|generates| Audit\n end\n \n subgraph \"MCP Tools\"\n Tool1[Document Search]\n Tool2[Database Query]\n Tool3[File Operations]\n Tool4[External API]\n end\n \n subgraph \"Backend Systems\"\n DB[(Databases)]\n Storage[File Storage]\n APIs[Internal APIs]\n External[External Services]\n end\n \n AIAgent -->|MCP requests| Proxy\n Proxy -->|routes to| Tool1\n Proxy -->|routes to| Tool2\n Proxy -->|routes to| Tool3\n Proxy -->|routes to| Tool4\n \n Tool1 -->|reads| DB\n Tool1 -->|reads| Storage\n Tool2 -->|queries| DB\n Tool3 -->|manages| Storage\n Tool4 -->|calls| APIs\n Tool4 -->|calls| External\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,Auth,RBAC,Registry,Audit security;\nDieses Diagramm bietet eine detaillierte Ansicht des identitätsbewussten Proxy-Musters für MCP. Die Architektur ist in vier Hauptschichten unterteilt:
\nAlle MCP-Anfragen von KI-Agenten müssen durch den Proxy laufen, der die Anfragen authentifiziert, RBAC-Richtlinien durchsetzt, die Tool Registry zur Routenbestimmung konsultiert und Audit-Logs generiert. Der Proxy leitet autorisierte Anfragen dann an die entsprechenden MCP-Tools weiter, die wiederum mit den Backend-Systemen interagieren.
\nDiese zentralisierte Sicherheitsarchitektur stellt eine konsistente Durchsetzung von Sicherheitsrichtlinien über alle MCP-Interaktionen hinweg sicher, unabhängig davon, welche Tools verwendet oder auf welche Backend-Systeme zugegriffen wird.
\nAnders als ein einfacher zustandsloser API-Aufruf können MCP-Sitzungen langlebig sein und Streaming beinhalten (Server-Sent Events für Ausgaben usw.). Der Proxy sollte sicherstellen, dass alle Anfragen und Antworten, die zu einer bestimmten Sitzung oder Konversation gehören, konsistent behandelt werden. Dies bedeutet oft die Implementierung von Session Affinity – wenn mehrere Instanzen eines MCP-Servers laufen, routet der Proxy den Traffic einer bestimmten Sitzung jedes Mal zur gleichen Instanz. Dies verhindert Probleme, bei denen beispielsweise der Zustand von Tool A (In-Memory-Cache, Kontextfenster usw.) verloren geht, weil Anfrage 2 an eine andere Instanz ging als Anfrage 1. Moderne Proxys können sitzungsbewusstes Load Balancing anhand von HTTP-Headern oder Routen durchführen (z. B. durch das Mappen einer Sitzungs-ID oder Client-ID in der URL auf ein bestimmtes Backend). Zusätzlich kann der Proxy SSE-Verbindungen elegant handhaben, sodass Streaming-Antworten nicht versehentlich durch Netzwerk-Zwischenstationen unterbrochen werden. Sollte eine Sitzung fortgesetzt oder übergeben werden müssen, kann das Gateway dies koordinieren (wie in kommenden Envoy-Funktionen für MCP vorgeschlagen). Kurz gesagt: Der Proxy stellt Zuverlässigkeit und Konsistenz für MCPs zustandsbehaftete Interaktionen sicher, was für die Benutzererfahrung und die Aufrechterhaltung des korrekten Kontexts entscheidend ist.
\nsequenceDiagram\n participant User\n participant AIAgent as AI Agent\n participant Proxy as API Gateway\n participant Instance1 as Tool Instance 1\n participant Instance2 as Tool Instance 2\n \n User->>AIAgent: Start conversation\n AIAgent->>Proxy: MCP request 1 (session=abc123)\n \n Note over Proxy: Session affinity routing\n \n Proxy->>Instance1: Route to instance 1\n Instance1->>Proxy: Response with state\n Proxy->>AIAgent: Return response\n \n User->>AIAgent: Continue conversation\n AIAgent->>Proxy: MCP request 2 (session=abc123)\n \n Note over Proxy: Same session ID routes to same instance\n \n Proxy->>Instance1: Route to instance 1 (preserves state)\n Instance1->>Proxy: Response with updated state\n Proxy->>AIAgent: Return response\n \n Note over User,Instance2: Without session affinity, request might go to instance 2 and lose state\nDieses Sequenzdiagramm veranschaulicht, wie Session Affinity in einer MCP-Umgebung funktioniert. Wenn ein Benutzer ein Gespräch mit einem KI-Agenten beginnt, stellt der Agent eine MCP-Anfrage an das API-Gateway mit einer Sitzungskennung (hier „abc123“). Das Gateway verwendet diese Sitzungs-ID, um die Anfrage an eine bestimmte Tool-Instanz (Instanz 1) zu routen.
\nWenn der Benutzer das Gespräch fortsetzt, stellt der Agent eine weitere MCP-Anfrage mit derselben Sitzungs-ID. Da das Gateway Session Affinity implementiert, leitet es diese Anfrage an dieselbe Instanz (Instanz 1) weiter, die den Zustand aus der vorherigen Interaktion bewahrt. Dies stellt eine konsistente und kohärente Erfahrung für den Benutzer sicher.
\nOhne Session Affinity könnte die zweite Anfrage an eine andere Instanz (Instanz 2) geroutet werden, die nicht über die Zustandsinformationen der ersten Anfrage verfügt. Dies würde zu einer unterbrochenen Erfahrung führen, da das Tool den Kontext der vorherigen Interaktion nicht hätte.
\nSession Affinity ist besonders wichtig für MCP, da viele KI-Interaktionen zustandsbehaftet und kontextabhängig sind. Die Fähigkeit des Proxys, diese Sitzungskonsistenz aufrechtzuerhalten, ist ein entscheidender Vorteil gegenüber einfacheren API-Integrationsansätzen.
\nJede Anfrage, die das MCP-Gateway erreicht, sollte ein gültiges Identitätstoken tragen – typischerweise ein JSON Web Token (JWT), das von einem Identity Provider über OIDC (OpenID Connect) ausgestellt wurde. Durch die Anforderung von JWTs lagert der Proxy die Authentifizierung von den Tools selbst aus und stellt sicher, dass nur authentifizierte, autorisierte Aufrufe durchkommen. In der Praxis bedeutet dies, dass der KI-Agent (oder die Benutzersitzung mit dem Agenten) ein OIDC-Token erhalten muss (z. B. ein ID-Token oder Access-Token) und es an jede MCP-Anfrage anhängt (oft in einem HTTP-Header wie Authorization: Bearer <token>). Der Proxy verifiziert dieses Token, prüft Signatur und Claims (Issuer, Audience, Ablauf usw.) und lehnt jede Anfrage ab, die nicht ordnungsgemäß authentifiziert ist. Auf diese Weise sehen Ihre MCP-Server nie einen anonymen Aufruf – sie vertrauen darauf, dass das Gateway die Identität geprüft hat.
sequenceDiagram\n participant User\n participant App as AI Application\n participant IdP as Identity Provider\n participant Proxy as API Gateway\n participant Tool as MCP Tool\n \n User->>App: Access AI application\n App->>IdP: Redirect to login\n User->>IdP: Authenticate\n IdP->>App: Authorization code\n App->>IdP: Exchange code for tokens\n IdP->>App: ID token + access token\n \n Note over App: Store tokens securely\n \n User->>App: Request using AI tool\n App->>Proxy: MCP request with access token\n \n Proxy->>Proxy: Validate token (signature, expiry, audience)\n Proxy->>Proxy: Extract user identity and permissions\n \n alt Token Valid\n Proxy->>Tool: Forward request with user context\n Tool->>Proxy: Response\n Proxy->>App: Return response\n App->>User: Display result\n else Token Invalid\n Proxy->>App: 401 Unauthorized\n App->>User: Session expired, please login again\n end\n \n Note over App,Proxy: Token refresh happens in background\n App->>IdP: Refresh token when needed\n IdP->>App: New access token\nDieses Sequenzdiagramm veranschaulicht den OIDC-Authentifizierungsablauf in einer MCP-Umgebung. Der Prozess beginnt, wenn ein Benutzer auf die KI-Anwendung zugreift, die zur Anmeldung zum Identity Provider weiterleitet. Nach der Authentifizierung des Benutzers stellt der Identity Provider einen Autorisierungscode aus, den die Anwendung gegen ID- und Access-Token eintauscht.
\nDie Anwendung speichert diese Token sicher und verwendet das Access-Token bei MCP-Anfragen über den KI-Agenten. Wenn der Proxy eine Anfrage erhält, validiert er das Token durch Prüfung der Signatur, des Ablaufs, der Audience und anderer Claims. Er extrahiert auch die Benutzeridentität und Berechtigungen aus dem Token.
\nWenn das Token gültig ist, leitet der Proxy die Anfrage zusammen mit dem Benutzerkontext an das entsprechende MCP-Tool weiter. Das Tool verarbeitet die Anfrage und gibt eine Antwort zurück, die über den Proxy durch die Anwendung letztendlich zum Benutzer fließt.
\nWenn das Token ungültig ist (abgelaufen, manipuliert usw.), gibt der Proxy eine 401 Unauthorized-Antwort zurück, und die Anwendung fordert den Benutzer auf, sich erneut anzumelden.
\nIm Hintergrund kann die Anwendung ein Refresh-Token verwenden, um neue Access-Token zu erhalten, wenn nötig, ohne dass der Benutzer sich erneut authentifizieren muss. Dies stellt ein reibungsloses Benutzererlebnis sicher und wahrt gleichzeitig die Sicherheit.
\nDiese OIDC-Integration bietet einen robusten Authentifizierungsmechanismus, der in Enterprise-Umgebungen weit verbreitet ist und sich gut in bestehende Identity-Management-Systeme integriert.
\nWährend die obige Diskussion sich auf die Authentifizierung des menschlichen Benutzers konzentriert, muss ein produktionsreifes MCP-Deployment auch zwei weitere Akteure identifizieren:
\nUnser Begleitartikel „OpenID Connect for Agents (OIDC-A) 1.0 Proposal“ ({{ site.baseurl }}/2025/04/28/oidc-a-proposal/) erweitert OIDC Core 1.0 um einen umfangreichen Satz von Claims für Agentenidentität, Attestierung und Delegationsketten. In der Praxis bedeutet dies:
\nagent_type, agent_model, agent_instance_id, delegator_sub, delegation_chain usw.). Dieses Token reist neben dem Access-Token des Benutzers in jeder MCP-Anfrage mit.agent_capabilities, agent_trust_level, agent_attestation).Die Übernahme von OIDC-A bringt mehrere Vorteile:
\nemail:draft bewerben, das Mail-Tool aufrufen lassen).agent_attestation) ermöglicht dem Gateway, die Integrität und Herkunft sowohl von Agenten als auch von Tools zu verifizieren, bevor Traffic an sie geroutet wird.Für den Rest dieses Artikels gilt: Wann immer wir von einem „Token“ sprechen, das vom Gateway validiert wird, gehen wir davon aus, dass dies nun das Benutzer-Token, das Agenten-OIDC-A-Token und (optional) das Tool-/Resource-Token umfasst – alles in einem einzigen Policy-Decision-Schritt ausgewertet.
\nDieses Muster wird bereits breit in der API-Sicherheit eingesetzt: „Ein API-Gateway kann Authentifizierung sicher und konsistent implementieren… ohne die Anwendungen selbst zu belasten.“ In unserem Kontext könnte der MCP-Proxy mit Ihrem Enterprise-SSO (Azure AD, Okta usw.) über OIDC integriert werden, um Benutzeranmeldeabläufe und Token-Validierung zu handhaben. Viele Gateways unterstützen OIDC nativ, initiieren bei Bedarf Redirects für die Benutzeranmeldung und speichern das resultierende Token dann in einem Cookie für die Sitzungskontinuität. In einem Headless-Agenten-Szenario (wo die KI server-to-server Tools aufruft) könnte das Token out-of-band bereitgestellt werden (z. B. hat sich der Benutzer in der KI-App angemeldet, also injiziert die App das Token für den Agenten). Auf jeden Fall erzwingt das Gateway, dass kein Token = kein Zugriff. Es kann auch Token-Claims auf Rollen oder Scopes mappen, um Autorisierung zu implementieren (z. B. dürfen nur Benutzer mit dem Scope „HR_read“ das „HR Database“-Tool nutzen). Dies passt perfekt zu MCPs Designziel sicherer Verbindungen – die Kombination von MCP mit OIDC und OIDC-A ergibt einen End-to-end authentifizierten Kanal für die Tool-Nutzung.
\nsequenceDiagram\n participant User\n participant Agent as LLM Agent (OIDC-A)\n participant Proxy as API Gateway\n participant Tool as MCP Tool (OIDC-A)\n participant Backend as Backend System\n\n User->>Agent: 1. Interact (chat, form, etc.)\n Agent->>Proxy: 2. MCP request\\nBearer user token + agent OIDC-A token\n Proxy->>Proxy: 3. Validate user token (OIDC) & agent token (OIDC-A)\n Proxy-->>Tool: 4. Forward request plus optional *resource token* for the tool\n Tool->>Backend: 5. Query/act using delegated auth\n Backend-->>Tool: 6. Data / result\n Tool-->>Proxy: 7. Response (may include attestation)\n Proxy-->>Agent: 8. Authorized response\n Agent-->>User: 9. Present result\nEin mächtiger Vorteil des Proxys ist, dass er Routing-Entscheidungen nicht nur anhand von URLs, sondern auch anhand von Metadaten innerhalb der Anfragen treffen kann. Bei MCP sind Anfragen und Antworten im JSON-RPC-Format, das Felder wie den Tool-Methodennamen, Parameter und sogar Tool-Annotationen enthält. Ein identitätsbewusster Proxy kann so konfiguriert werden, dass er diese Details inspiziert und Richtlinienregeln anwendet. Beispielsweise könnten Sie Regeln wie diese konfigurieren:
\ngraph TD\n subgraph \"MCP Request\"\n Request[JSON-RPC Request]\n Method[Tool Method]\n Params[Parameters]\n User[User Identity]\n end\n \n subgraph \"Policy Engine\"\n Rules[Policy Rules]\n RBAC[Role-Based Access]\n Audit[Audit Logging]\n Transform[Response Transformation]\n end\n \n Request --> Method\n Request --> Params\n Request --> User\n \n Method --> Rules\n Params --> Rules\n User --> RBAC\n \n Rules --> Decision{Allow/Deny}\n RBAC --> Decision\n \n Decision -->|Allow| Forward[Forward to Tool]\n Decision -->|Deny| Reject[Reject Request]\n \n Forward --> Audit\n Reject --> Audit\n \n Forward --> Tool[MCP Tool]\n Tool --> Response[Tool Response]\n Response --> Transform\n Transform --> Filtered[Filtered Response]\n \n classDef request fill:#bbf,stroke:#333,stroke-width:1px;\n classDef policy fill:#fbf,stroke:#333,stroke-width:1px;\n classDef action fill:#bfb,stroke:#333,stroke-width:1px;\n \n class Request,Method,Params,User request;\n class Rules,RBAC,Audit,Transform policy;\n class Decision,Forward,Reject,Filtered action;\nDieses Diagramm veranschaulicht, wie Tool-Metadaten-Filtering und Richtliniendurchsetzung in einem MCP-Proxy funktionieren. Der Prozess beginnt mit einer MCP-Anfrage im JSON-RPC-Format, die den Tool-Methodennamen, die Parameter und die Benutzeridentitätsinformationen enthält. Diese Komponenten werden extrahiert und in die Policy Engine eingespeist.
\nDie Policy Engine besteht aus Richtlinienregeln, rollenbasierter Zugriffskontrolle (RBAC), Audit-Logging und Response-Transformation. Tool-Methodenname und Parameter werden gegen die Richtlinienregeln ausgewertet, während die Benutzeridentität gegen RBAC-Berechtigungen geprüft wird.
\nBasierend auf diesen Auswertungen trifft die Policy Engine eine Allow/Deny-Entscheidung. Wenn die Anfrage erlaubt ist, wird sie an das MCP-Tool weitergeleitet; wenn sie abgelehnt wird, wird sie zurückgewiesen. In beiden Fällen wird die Aktion zu Audit-Zwecken protokolliert.
\nWenn eine Anfrage erlaubt und vom Tool verarbeitet wurde, kann die Antwort durch einen Transformationsschritt gehen, bevor sie an den Client zurückgegeben wird. Diese Transformation kann die Antwort auf Basis von Sicherheitsrichtlinien filtern oder modifizieren, z. B. durch Entfernen sensibler Informationen, die der Benutzer nicht sehen sollte.
\nDiese feingranulare Richtliniendurchsetzung auf Metadatenebene ermöglicht ausgefeilte Sicherheitskontrollen, die weit über einfaches URL-basiertes Routing hinausgehen. Beispiele:
\ndelete_file ist und der Benutzer nicht in der IT-Admin-Gruppe ist, die Anfrage ablehnen.“execute_sql nur an Wochentagen zwischen 9 und 17 Uhr erlauben und alle Abfragen protokollieren.“Dies ist vergleichbar mit einer Web Application Firewall (WAF) oder einem API-Gateway, das Content Filtering durchführt, aber zugeschnitten auf die KI-Tool-Nutzung. Im Envoy-MCP-Vorschlag entspricht dies dem Parsen von MCP-Nachrichten und der Verwendung von RBAC-Filtern auf diesen. Der Proxy versteht im Wesentlichen die Absicht jedes Tool-Aufrufs und kann sie entsprechend steuern. Er kann auch Daten bei Bedarf redigieren oder transformieren – beispielsweise bestimmte Felder aus einer Antwort entfernen, die der Benutzer nicht sehen soll, oder personenbezogene Informationen maskieren. Durch die Zentralisierung dieses im Gateway vermeidet man, dass Prüfungen in jedem Tool-Dienst implementiert werden müssen (was inkonsistent oder vergessen werden könnte). Auditing ist ein weiterer Vorteil: Der Proxy kann jeden Tool-Aufruf zusammen mit Benutzeridentität und Parametern protokollieren und in SIEM-Systeme für die Überwachung einspeisen. So haben Sie, falls ein KI-Agent eines Tages etwas tut, was er nicht sollte, eine klare Spur, welcher Tool-Aufruf involviert war und wer ihn ausgelöst hat. Zusammenfassend verwandelt Metadaten-basiertes Filtering den Proxy in einen intelligenten Policy Enforcement Point, der eine Sicherheitsschicht über MCPs Grundfähigkeiten legt.
\nUnternehmen entwickeln ihre Dienste ständig weiter – neue Versionen, A/B-Tests, Staging- vs. Produktions-Deployments usw. Der Proxy kann erheblich vereinfachen, wie KI-Agenten mit diesen Änderungen umgehen. Anstatt dass die KI wissen muss, welche Version eines Tools sie aufrufen soll, kann das Gateway versionsbewusstes Routing implementieren. Beispielsweise könnte der MCP-Endpunkt für ein „Document Search“-Tool für den Agenten gleich bleiben, aber der Proxy könnte 90 % der Anfragen an v1 des Dienstes und 10 % an eine neue v2 routen (für einen Canary-Rollout). Oder interne Benutzer an eine „Beta“-Instanz leiten, während externe Benutzer zur stabilen Version gehen. Dies geschieht durch Abgleich von Anfrageattributen oder durch Routing-Regeln, die Benutzer-Audience und Tool-Identifikatoren berücksichtigen.
\ngraph TB\n AIAgent[AI Agent] -->|MCP Request| Proxy[API Gateway]\n \n Proxy -->|\"90% traffic\"| V1[Tool v1]\n Proxy -->|\"10% traffic\"| V2[Tool v2 - Canary]\n \n Proxy -->|\"Internal Users\"| Beta[Beta Version]\n Proxy -->|\"External Users\"| Stable[Stable Version]\n \n Proxy -->|\"Small Requests\"| Standard[Standard Instance]\n Proxy -->|\"Large Requests\"| HighMem[High-Memory Instance]\n \n Proxy -->|\"US Users\"| US[US Region]\n Proxy -->|\"EU Users\"| EU[EU Region]\n \n classDef proxy fill:#f96,stroke:#333,stroke-width:2px;\n classDef version fill:#bbf,stroke:#333,stroke-width:1px;\n classDef audience fill:#bfb,stroke:#333,stroke-width:1px;\n classDef size fill:#fbf,stroke:#333,stroke-width:1px;\n classDef region fill:#ff9,stroke:#333,stroke-width:1px;\n \n class Proxy proxy;\n class V1,V2 version;\n class Beta,Stable audience;\n class Standard,HighMem size;\n class US,EU region;\nDieses Diagramm veranschaulicht die verschiedenen Routing-Strategien, die ein API-Gateway für MCP-Anfragen implementieren kann. Das Gateway kann Traffic basierend auf mehreren Faktoren routen:
\nDer KI-Agent muss sich dieser Routing-Entscheidungen nicht bewusst sein; er stellt einfach Anfragen an den logischen Tool-Namen, und das Gateway handhabt die Komplexität des Routings zum passenden Backend. Diese Abstraktion vereinfacht die Implementierung des Agenten und bietet gleichzeitig leistungsfähige operative Möglichkeiten.
\nEbenso kann das Routing Kontext berücksichtigen – z. B. Anfragen an den nächstgelegenen regionalen Server für geringere Latenz leiten, wenn der Standort des Benutzers bekannt ist, oder ein anderes Backend wählen, je nach Größe der Anfrage (möglicherweise eine spezielle High-Memory-Instanz für sehr große Dateien). All dies ist auf Proxy-Ebene konfigurierbar. Der KI-Agent ruft einfach den logischen Tool-Namen auf, und das Gateway kümmert sich darum, das richtige Backend zu finden. Dies erleichtert nicht nur den Betrieb (Sie können Backend-Tools upgraden, ohne die KI-Schnittstelle zu brechen), sondern erhöht auch die Sicherheit. Sie könnten bestimmte Versionen für Tests isolieren oder sicherstellen, dass experimentelle Tools nur unter bestimmten Bedingungen zugänglich sind. Durch die Kontrolle des Traffic-Flows hilft der Proxy, das Prinzip der geringsten Berechtigung im Makromaßstab aufrechtzuerhalten – die KI erreicht nur die Backends, die sie erreichen soll, über Routen, die für den aktuellen Kontext angemessen sind.
\nNachdem wir die zentralen Sicherheitsmuster behandelt haben, wollen wir uns einen praktischen Ansatz zur Implementierung der MCP-Sicherheit mit einem identitätsbewussten Proxy ansehen. Dieser Abschnitt skizziert die Schritte zum Aufbau einer sicheren MCP-Umgebung, wobei der Fokus auf den Integrationspunkten zwischen den Komponenten liegt.
\ngraph TB\n subgraph ImplementationSteps[\"Implementation Steps\"]\n Step1[1. Set up Identity Provider]\n Step2[2. Configure API Gateway]\n Step3[3. Implement Tool Registry]\n Step4[4. Define Security Policies]\n Step5[5. Integrate AI Agents]\n Step6[6. Monitor and Audit]\n \n Step1 --> Step2\n Step2 --> Step3\n Step3 --> Step4\n Step4 --> Step5\n Step5 --> Step6\n end\n \n classDef step fill:#beb,stroke:#333,stroke-width:1px\n class Step1,Step2,Step3,Step4,Step5,Step6 step\nDieses Diagramm skizziert die sechs zentralen Schritte zur Implementierung der MCP-Sicherheit mit einem Proxy. Der Prozess folgt einer logischen Abfolge:
\nJeder Schritt baut auf dem vorherigen auf und schafft eine umfassende Sicherheitsimplementierung. Die folgenden Abschnitte werden jeden Schritt im Detail erkunden.
\nDer erste Schritt ist die Konfiguration Ihres Identity Providers (IdP), um die für die MCP-Sicherheit benötigten OIDC-Flows zu unterstützen. Dies umfasst typischerweise:
\nDer IdP ist verantwortlich für die Authentifizierung von Benutzern und die Ausstellung der Token, die zur Absicherung von MCP-Anfragen verwendet werden. Es ist wichtig, die entsprechenden Scopes und Claims zu konfigurieren, um sicherzustellen, dass die Token die für Autorisierungsentscheidungen notwendigen Informationen enthalten.
\nAls Nächstes müssen Sie Ihr API-Gateway so konfigurieren, dass es als MCP-Proxy fungiert. Dies umfasst:
\nsequenceDiagram\n participant Admin\n participant Gateway as API Gateway\n participant IdP as Identity Provider\n \n Admin->>Gateway: 1. Configure OIDC integration\n Gateway->>IdP: 2. Fetch OIDC discovery document\n IdP->>Gateway: 3. Return endpoints and keys\n \n Admin->>Gateway: 4. Set up MCP routing rules\n Admin->>Gateway: 5. Configure security policies\n \n Note over Gateway: Gateway ready to validate tokens and route MCP traffic\nDieses Sequenzdiagramm veranschaulicht den Prozess der Konfiguration eines API-Gateways für die MCP-Sicherheit. Der Prozess beginnt damit, dass ein Administrator die OIDC-Integration im Gateway konfiguriert. Das Gateway ruft dann das OIDC-Discovery-Dokument vom Identity Provider ab, der die notwendigen Endpunkte und Schlüssel für die Token-Validierung zurückgibt.
\nAls Nächstes richtet der Administrator MCP-Routing-Regeln ein, die definieren, wie Anfragen basierend auf verschiedenen Kriterien an verschiedene MCP-Tools weitergeleitet werden sollen. Der Administrator konfiguriert auch Sicherheitsrichtlinien, die festlegen, wer auf welche Tools zugreifen darf und unter welchen Bedingungen.
\nSobald diese Konfigurationen abgeschlossen sind, ist das Gateway bereit, Token zu validieren und MCP-Traffic gemäß den definierten Regeln und Richtlinien zu routen. Dieser Setup-Prozess etabliert das Gateway als zentralen Sicherheitskontrollpunkt für alle MCP-Interaktionen.
\nDie Konfigurationsschritte umfassen:
\nDas Gateway ist verantwortlich für die Validierung der Token, die Durchsetzung der Sicherheitsrichtlinien und das Routing der MCP-Anfragen an die entsprechenden Backends. Es ist wichtig sicherzustellen, dass das Gateway ordnungsgemäß konfiguriert ist, um das MCP-JSON-RPC-Format zu handhaben und die für Policy-Entscheidungen notwendigen Informationen zu extrahieren.
\nEine Tool Registry ist essenziell für die Verwaltung des Lebenszyklus von MCP-Tools in Ihrer Umgebung. Dies umfasst:
\nDie Tool Registry ist verantwortlich für die Pflege der Liste verfügbarer Tools, ihrer Endpunkte und ihrer Zugriffsanforderungen. Sie stellt auch die notwendigen Informationen für das API-Gateway zur Verfügung, um Routing und Richtliniendurchsetzung zu ermöglichen.
\ngraph TB\n subgraph \"Tool Registry\"\n DB[(Tool Database)]\n API[Registry API]\n UI[Admin UI]\n \n UI -->|Manage Tools| API\n API -->|CRUD Operations| DB\n end\n \n subgraph \"Integration Points\"\n Gateway[API Gateway]\n Agents[AI Agents]\n \n API -->|Tool Configurations| Gateway\n API -->|Available Tools| Agents\n end\n \n subgraph \"Tool Lifecycle\"\n Register[Register]\n Approve[Approve]\n Deploy[Deploy]\n Monitor[Monitor]\n Retire[Retire]\n \n Register --> Approve\n Approve --> Deploy\n Deploy --> Monitor\n Monitor --> Retire\n end\n \n classDef registry fill:#bbf,stroke:#333,stroke-width:1px;\n classDef integration fill:#fbf,stroke:#333,stroke-width:1px;\n classDef lifecycle fill:#bfb,stroke:#333,stroke-width:1px;\n \n class DB,API,UI registry;\n class Gateway,Agents integration;\n class Register,Approve,Deploy,Monitor,Retire lifecycle;\nDieses Diagramm veranschaulicht die Komponenten und den Lebenszyklus einer Tool Registry in einer MCP-Umgebung. Die Tool Registry besteht aus drei Hauptkomponenten:
\nDie Tool Registry integriert sich mit zwei zentralen Systemen:
\nDas Diagramm zeigt auch den Lebenszyklus eines MCP-Tools:
\nDieser umfassende Ansatz zur Tool-Verwaltung stellt sicher, dass alle MCP-Tools ordnungsgemäß geprüft, deployed und überwacht werden, was Sicherheitsrisiken und operative Probleme reduziert.
\nSicherheitsrichtlinien sind die Regeln, die den Zugriff auf MCP-Tools regeln. Dies umfasst:
\nDie Sicherheitsrichtlinien werden vom API-Gateway basierend auf der Benutzeridentität und dem aufgerufenen Tool durchgesetzt. Es ist wichtig sicherzustellen, dass die Richtlinien umfassend sind und mit den Sicherheitsanforderungen Ihrer Organisation übereinstimmen.
\nSchließlich müssen Sie Ihre KI-Agenten mit der sicheren MCP-Umgebung integrieren. Dies umfasst:
\nDie KI-Agenten sind verantwortlich für das Erhalten der notwendigen Token und deren Einbindung in MCP-Anfragen. Sie müssen auch Authentifizierungs- und Autorisierungsfehler elegant behandeln und den Benutzern angemessenes Feedback geben.
\nsequenceDiagram\n participant User\n participant Agent as AI Agent\n participant App as Application\n participant IdP as Identity Provider\n participant Gateway as API Gateway\n participant Tool as MCP Tool\n \n User->>App: Access AI application\n App->>IdP: Authenticate user\n IdP->>App: Issue tokens\n \n User->>Agent: Request using AI capabilities\n Agent->>App: Request token for MCP\n App->>Agent: Provide token\n \n Agent->>Gateway: MCP request with token\n Gateway->>Gateway: Validate token & apply policies\n Gateway->>Tool: Forward authorized request\n Tool->>Gateway: Response\n Gateway->>Agent: Return response\n Agent->>User: Present result\n \n Note over App,Gateway: Token refresh cycle\n App->>IdP: Refresh token when needed\n IdP->>App: New access token\nDieses Sequenzdiagramm veranschaulicht die Integration von KI-Agenten in eine sichere MCP-Umgebung. Der Prozess beginnt, wenn ein Benutzer auf die KI-Anwendung zugreift, die den Benutzer beim Identity Provider authentifiziert und Token erhält.
\nWenn der Benutzer eine Anfrage stellt, die KI-Fähigkeiten erfordert, fordert der KI-Agent ein Token von der Anwendung an, die es bereitstellt. Der Agent fügt dieses Token dann seinen MCP-Anfragen an das API-Gateway bei.
\nDas Gateway validiert das Token und wendet Sicherheitsrichtlinien an, um zu bestimmen, ob die Anfrage erlaubt sein sollte. Bei Autorisierung wird die Anfrage an das entsprechende MCP-Tool weitergeleitet, das sie verarbeitet und eine Antwort zurückgibt. Diese Antwort fließt über das Gateway zurück zum Agenten und letztendlich zum Benutzer.
\nIm Hintergrund handhabt die Anwendung Token-Refresh-Zyklen und fordert bei Bedarf neue Access-Token vom Identity Provider an. Dies stellt einen kontinuierlichen Betrieb sicher, ohne dass der Benutzer sich häufig neu authentifizieren muss.
\nDieser Integrationsansatz stellt sicher, dass KI-Agenten innerhalb des durch die Proxy-Architektur etablierten Sicherheitsrahmens operieren, wobei alle Anfragen ordnungsgemäß authentifiziert und autorisiert sind.
\nDurch die Implementierung einer sicheren MCP-Architektur mit einem identitätsbewussten Proxy gehen Sie weit über „glorifizierte API-Aufrufe“ hinaus zu einer robusten, Enterprise-tauglichen Integration zwischen KI-Agenten und Ihren Geschäftssystemen. Dieser Ansatz adressiert die zentralen Sicherheitsherausforderungen von MCP-Deployments, einschließlich:
\nDie Proxy-basierte Architektur bietet einen zentralisierten Kontrollpunkt für die Durchsetzung von Sicherheitsrichtlinien, die Verwaltung des Tool-Zugriffs und die Überwachung der KI-Agenten-Aktivität. Sie vereinfacht auch den Betrieb, indem sie die Komplexität der Backend-Dienste abstrahiert und eine konsistente Schnittstelle für KI-Agenten bietet.
\nMit der weiteren Entwicklung und Verbreitung von MCP werden die in diesem Artikel beschriebenen Sicherheitsmuster für Enterprise-Deployments zunehmend wichtig. Durch die Implementierung dieser Muster jetzt können Sie sicherstellen, dass Ihre KI-Agenten-Infrastruktur sicher, skalierbar und zukunftsfit ist.
\ngraph LR\n A[Glorified API Calls] -->|Evolution| B[Secure MCP Architecture]\n \n subgraph \"Key Benefits\"\n C[Centralized Security]\n D[Identity Propagation]\n E[Policy Enforcement]\n F[Audit & Compliance]\n G[Operational Simplicity]\n end\n \n B --> C\n B --> D\n B --> E\n B --> F\n B --> G\n \n classDef benefit fill:#bfb,stroke:#333,stroke-width:1px;\n class C,D,E,F,G benefit;\nDieses abschließende Diagramm fasst die Evolution von „glorifizierten API-Aufrufen“ zu einer sicheren MCP-Architektur zusammen und hebt die zentralen Vorteile dieses Ansatzes hervor:
\nDurch die Übernahme dieser Architektur können Organisationen KI-Agenten zuversichtlich in Enterprise-Umgebungen deployen, in dem Wissen, dass ihre MCP-Interaktionen sicher, auditierbar und im großen Maßstab handhabbar sind. Dies stellt einen bedeutenden Fortschritt über die vereinfachte Sicht von KI-Tools als bloße API-Aufrufe hinaus dar und erkennt die komplexen Sicherheitsanforderungen produktionsreifer KI-Systeme an.
", "source_hash": "sha256:16841784df04160a9056837800a6ebef3debed4d096d4492fffd8524d0830436", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-06-10T20:42:34.393559+00:00" }