MCP-Gateways reichen nicht aus: KI-Agenten benötigen Identität, Autorisierung und kryptografischen Beweis

MCP-Gateways sind allgegenwärtig (und das ist gut so)

Das Model Context Protocol (MCP) hat sich rasch zur Standardmethode entwickelt, mit der Agenten die Außenwelt erreichen: das gängige Protokoll für die Verbindung eines Agenten mit Datenbanken, SaaS-Plattformen, Code-Runners, Zahlungssystemen und internen Diensten. Wenn Ihre Agenten etwas Nützliches tun, tun sie dies mit ziemlicher Sicherheit über MCP.

Natürlich nehmen MCP-Gateways rasant zu. Jeder Infrastrukturanbieter, jedes Service-Mesh-Unternehmen und eine wachsende Zahl von Open-Source-Projekten und Start-ups bieten MCP-Gateway-Lösungen an. Und sie bieten echten Mehrwert: zentralisiertes Routing, Service Discovery, Anmeldedatenverwaltung und grundlegende Zugriffskontrolle für MCP-Serververbindungen.

Das ist die Grundvoraussetzung. Es ist jedoch noch kein vollständiges Sicherheitsmodell.

Wenn Ihr Unternehmen KI-Agenten von Prototypen in die Produktion überführt, in denen sie APIs aufrufen, Code ausführen, sensible Daten abfragen und im Namen Ihres Unternehmens mit anderen Agenten interagieren, sind Routing und Zugriffskontrolle zwar notwendig, aber bei weitem nicht ausreichend. Die zentralen Sicherheitsprobleme sind Identität, Autorisierung und kryptografischer Beweis. Und MCP-Gateways lösen keines davon.

Die drei Lücken, die MCP-Gateways offen lassen

Der Einsatz von KI-Agenten in Unternehmen muss drei Fragen beantworten, bevor sie in die Produktion gehen können. MCP-Gateways lassen alle drei unbeantwortet.

Lücke 1: Identität. “Wer ist dieser Agent?”

MCP-Gateways authentifizieren auf Verbindungsebene. Eine Anfrage trifft mit einem gültigen API-Schlüssel oder OAuth-Token ein, das Gateway gleicht sie mit einer Liste ab, und die Anfrage wird durchgelassen. Das sagt Ihnen, dass die Anmeldedaten gültig sind. Es sagt Ihnen nicht, wer anruft.

In der Praxis arbeiten die meisten KI-Agenten mit fest programmierten API-Schlüsseln oder gemeinsam genutzten Service-Account-Tokens. Wenn Agent A und Agent B beide dieselben Service-Anmeldedaten verwenden, um einen MCP-Server zu erreichen, sieht das Gateway zwei identische Anrufer. Es gibt keinen Mechanismus, mit dem der Agent seine Identität kryptografisch nachweisen kann, keine zertifikatsgestützte Bestätigung, die ein nachgelagerter Dienst unabhängig überprüfen kann.

Dies ist ein Problem, das die Microservices-Welt bereits vor Jahren mit SPIFFE und mTLS gelöst hat. Jeder Dienst erhält eine überprüfbare, kryptografische Identität. Wenn Dienst A Dienst B aufruft, weiß der empfangende Dienst genau, wer anruft, und kann dies nachweisen. KI-Agenten, die heute mit Frameworks geschrieben werden, verfügen über nichts dergleichen. Sie arbeiten in einem Identitätsvakuum, und MCP-Gateways tun nichts, um dies zu ändern.

Der Unterschied wird in der Praxis deutlich. Heute kommen die meisten Agentenanrufe wie folgt bei einem Tool-Server an:

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Ein Token. Möglicherweise von mehreren Agenten gemeinsam genutzt. Möglicherweise langlebig. Ohne Informationen darüber, welche Workload es erzeugt hat, in welchem Kontext es operierte oder ob es seit seiner letzten Ausstellung rotiert wurde. Der Tool-Server akzeptiert es oder lehnt es ab. Damit endet die gesamte Identitätsprüfung.

Bei der SPIFFE-basierten Workload-Identität kommt derselbe Aufruf mit einem zertifikatsgestützten SVID an, einer kryptografisch signierten Assertion, die wie folgt aussieht:

spiffe://diagrid.io/ns/payments/fraud-detection-agent

Diese URI ist kein Geheimnis. Das muss sie auch nicht sein. Es handelt sich um eine überprüfbare Angabe, die von der Plattform ausgestellt wurde, an die spezifische Workload gebunden ist, die in einem bestimmten Namespace in einer bestimmten Vertrauensdomäne läuft, automatisch rotiert wird und von jedem Dienst nachweisbar ist, der derselben Vertrauensdomäne vertraut. Der empfangende Tool-Server prüft nicht nur: “Befindet sich diese Anmeldeinformation auf meiner Zulassungsliste?” Er überprüft: Um welche Workload handelt es sich, wo läuft sie und ist es die Workload, die diesen Aufruf eigentlich ausführen sollte?

Das erste Modell validiert die Anmeldeinformationen. Das zweite Modell sichert die Identität. Für KI-Agenten, die autonom über Dienste, Datenbanken und Zahlungssysteme hinweg operieren, ist diese Unterscheidung der Unterschied zwischen Zugriffskontrolle und Zero Trust.

Aus Sicht der Standardisierung wird die Verwendung von SPIFFE für die Workload-Identität derzeit in der IETF-Arbeitsgruppe WIMSE und der AAIF-Arbeitsgruppe “Identity & Trust” intensiv diskutiert.

Für einen tieferen Einblick in das Thema Identität lesen Sie “Agent Identity: The Foundational Layer that AI Is Still Missing”

Lücke 2: Autorisierung über das Routing hinaus. “Was darf dieser Agent tun?”

Stellen Sie sich einen Agenten vor, der Zugriff auf einen MCP-Server mit einer Kundendatenbank hat. Das Gateway lässt die Verbindung zu, der Agent verfügt über gültige Anmeldedaten und die Routing-Regel erlaubt dies. Der Agent befindet sich mitten im Workflow, als das LLM aufgrund einer mehrdeutigen Anweisung einen Aufruf konstruiert, der Datensätze löscht, die einem weit gefassten Filter entsprechen. Nichts im Gateway hält dies auf. Die Routing-Regel besagte, dass der Agent den Server erreichen darf. Sie sagte nichts darüber aus, was der Agent tun darf, sobald er dort angekommen ist.

Dies ist die Autorisierungslücke, die MCP-Gateways offen lassen. Sie kontrollieren den Zugriff: Welche Anrufer können welche Server erreichen? Sie kontrollieren nicht das Verhalten: Welche Aktionen darf eine bestimmte Agentenidentität ausführen, in welchen Workflow-Kontexten und unter welchen Bedingungen? Bei deterministischer Software spielt diese Unterscheidung kaum eine Rolle; man kann den Aufrufgraphen im Voraus durchdenken. Bei KI-Agenten, deren Verhalten von Natur aus emergent und nicht-deterministisch ist, ist dies der Unterschied zwischen einem Sicherheitsmodell und der Illusion eines solchen.

Was die Produktion erfordert, ist eine “Deny-by-Default”-Autorisierung auf Workflow-Ebene: deklarative Richtlinien, die genau festlegen, welche Agentenidentitäten welche Workflows und Tools aufrufen dürfen, und die auf der Plattformebene durchgesetzt werden, unabhängig davon, was das LLM beschließt. Diese Richtlinien müssen in der Infrastrukturkonfiguration verankert sein, im Besitz der Plattform- und Sicherheitsteams liegen, versionskontrolliert und überprüfbar sein. Nicht im Anwendungscode, wo sie übersprungen, überschrieben oder einfach vergessen werden können.

Lücke 3: Kryptografischer Beweis. “Was hat dieser Agent getan, und können wir es beweisen?”

MCP-Gateways erzeugen Protokolle. Protokolle sind nützlich. Protokolle sind kein Beweis.

Die Protokollierungsinfrastruktur in Unternehmen hat sich erheblich verbessert. Moderne SIEM-Plattformen können Protokollpipelines manipulationssicher machen, und mit den richtigen Tools lassen sich unveränderliche Prüfpfade erstellen. Aber selbst ein perfekt erhaltenes Protokoll beantwortet die falsche Frage. Wenn ein Compliance-Team fragt: “Können Sie nachweisen, dass ein Mensch diesen Tool-Aufruf genehmigt hat, bevor der Agent ihn ausgeführt hat?”, ist ein Log-Eintrag mit dem Inhalt tool: transfer_funds, status: approved, user: alice keine Antwort. Er bietet keine kryptografische Garantie dafür, dass die aufgezeichneten Ereignisse tatsächlich in der aufgezeichneten Reihenfolge stattgefunden haben.

In Multi-Agent-Systemen verschärft sich dieses Problem. Wenn Agent C einen destruktiven Tool-Aufruf auslöst, wurde dieser von Agent B autorisiert, der wiederum von Agent A autorisiert wurde, der von einem Menschen ausgelöst wurde? Ohne eine signierte Kontrollkette, die sich über alle Agent-Grenzen hinweg erstreckt, gibt es keine Möglichkeit, die Entscheidungskette zu rekonstruieren oder zu verifizieren.

Ein signierter Eintrag in der Nachweiskette ist kein Protokolleintrag. Es handelt sich um ein strukturiertes, kryptografisch überprüfbares Objekt, das den Workflow begleitet. Ein vereinfachter Eintrag sieht wie folgt aus:

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "timestamp": "2025-04-18T14:23:11Z",
  "result": "approved",
  "signature": "eyJhbGciOiJFUzI1NiJ9..."
}

Jeder Eintrag wird von der Identität signiert, die ihn erstellt hat. Wenn die Kette einen nachgelagerten Tool-Server erreicht, enthält sie den vollständigen Verlauf: wer den Workflow initiiert hat, welche Validierungsschritte ausgeführt wurden, ob eine Person die Genehmigung erteilt hat und welcher Agent den jeweiligen Eintrag erstellt hat. Der Tool-Server überprüft jede Signatur, bevor er tätig wird. Ein Eintrag, der nicht verifiziert werden kann, weil die signierende Identität unbekannt ist, die Signatur nicht übereinstimmt oder der erwartete Schritt fehlt, führt dazu, dass der Aufruf vor der Ausführung abgelehnt wird.

Das EU-KI-Gesetz, die sich abzeichnenden SEC-Leitlinien und die sich weiterentwickelnden SOC2-Anforderungen laufen alle auf eine klare Erwartung hinaus: Unternehmen müssen eine nachprüfbare Kontrolle über ihre KI-Systeme sowie die Rechenschaftspflicht dafür nachweisen.

Was Unternehmen benötigen, ist eine manipulationssichere, kryptografisch signierte Aufzeichnung jedes Schritts in jedem Agenten-Workflow – kein Protokoll, das jemand nachträglich überprüft, sondern ein Nachweis, den nachgelagerte Dienste in Echtzeit verifizieren, bevor sie handeln. Ein Tool-Server sollte in der Lage sein, einen destruktiven Tool-Aufruf abzulehnen, es sei denn, die signierte Historie belegt, dass ein Mensch ihn genehmigt hat, ein Validierungsschritt bestanden wurde und der aufrufende Agent autorisiert ist. MCP-Gateways kennen dieses Konzept nicht.

Wie eine KI-fähige Infrastruktur aussieht

Um die drei Lücken zu schließen, sind drei Funktionen erforderlich, die auf der Ebene der KI-Plattform arbeiten – unterhalb des Agenten- oder Anwendungscodes und oberhalb des Netzwerks/der Rechenleistung.

Kryptografische Agentenidentität

Jeder Agent benötigt eine SPIFFE-basierte kryptografische Identität, ein Zertifikat, das von der Plattform automatisch ausgestellt und rotiert wird. Wenn ein Agent ein Tool oder einen anderen Agenten aufruft, überprüft der empfangende Dienst die Identität über Standard-mTLS. Dabei handelt es sich nicht um ein Token in einem Header. Es ist eine zertifikatsgestützte Bestätigung, die in einer Vertrauenskette verwurzelt ist, die jeder Teilnehmer unabhängig überprüfen kann. Derselbe praxiserprobte Ansatz, der die Kommunikation zwischen Microservices sichert, wurde auf die besonderen Herausforderungen nicht-deterministischer, autonomer Agenten ausgeweitet.

Zero-Trust-Workflow-Autorisierung

Identität ohne Autorisierung ist bedeutungslos. Plattform- und Sicherheitsteams benötigen deklarative, GitOps-freundliche Richtlinien, die festlegen, welche Agentenidentitäten welche Workflows und Tools aufrufen dürfen. Die Standardhaltung muss “alles verweigern”, also Deny-All, sein: Alles, was nicht ausdrücklich erlaubt ist, wird blockiert. Diese Richtlinien müssen auf der Plattformebene durchsetzbar sein.

Dies ist der Unterschied zwischen “dieser Agent kann diesen Server erreichen” (was Gateways tun) und “diese spezifische Agentenidentität kann diesen spezifischen Workflow auf diesem spezifischen Ziel aufrufen und nichts anderes” (was die Produktion erfordert).

Policy-as-Code auf Basis signierter Historie

Grobe Regeln zur Zuordnung von Identitäten zu Workflows sind notwendig, aber nicht ausreichend. Die interessanteren Fragen zur Autorisierung sind kontextabhängig: Ging diesem Tool-Aufruf ein Schritt zur Betrugserkennung voraus? Hat ein Mensch ihn innerhalb der letzten 30 Sekunden genehmigt? Ist der Agent, der diesen Aufruf tätigt, derselbe, der die ursprüngliche Benutzeranfrage erhalten hat, oder wurde die Kette gekapert?

Diese Fragen lassen sich nicht allein anhand der Anfrage beantworten. Sie erfordern eine Auswertung der Historie des Workflows, der zu dem Aufruf geführt hat. Mit einer kryptografisch signierten Ausführungshistorie, die sich über jeden Schritt erstreckt, kann eine Policy-Engine im Stil eines Open Policy Agent (OPA) Rego (oder jede andere Policy-Sprache) im Moment der Entscheidung anhand der gesamten Kette auswerten:

allow_tool_call {
    input.history[_].step == "human_approval"
    input.history[_].step == "fraud_check_passed"
    input.history[_].agent == input.calling_agent
}

Die Richtlinie wird beim Empfänger und nicht beim Aufrufer ausgeführt. Agenten können den Verlauf nicht fälschen, da jeder Eintrag von der Identität signiert ist, die ihn erstellt hat. Dadurch wird der Workflow-Verlauf selbst zu einer überprüfbaren Eingabe für die Autorisierung – genau so, wie OPA bereits JWT-Claims und den Anforderungskontext für HTTP-APIs auswertet, nun jedoch durchgängig über Ausführungs-Ketten mit mehreren Agenten und Tools hinweg.

Kryptografische Nachweiskette

Wenn Agenten über Dienstgrenzen hinweg zusammenarbeiten, muss jeder Schritt signiert werden. Jeder Dienst signiert die gesammelte Ausführungshistorie mit seinem eigenen Identitätszertifikat und erstellt so eine manipulationssichere Kette. Ein nachgelagertes Tool prüft nicht nur: “Hat dieser Aufrufer die Berechtigung?”. Es verifiziert den gesamten Verlauf: Wer den Workflow initiiert hat, welche Genehmigungen erteilt wurden, welche Validierungsschritte bestanden wurden und ob jede Identität in der Kette autorisiert ist.

Dies ist kein Protokoll, das jemand später überprüft. Es handelt sich um einen kryptografischen Nachweis, der vor jedem Toolaufruf verifiziert wird. Dies ermöglicht Durchsetzungsmuster, die mit Routing allein nicht möglich sind: ein Zahlungs-MCP-Tool, das die Ausführung verweigert, sofern der signierte Verlauf nicht belegt, dass ein Workflow zur Betrugserkennung erfolgreich war und ein Mensch die Transaktion genehmigt hat.

So funktioniert das in der Praxis

Dies sind keine theoretischen Anforderungen. Diagrid Catalyst, die verwaltete Plattform für den Betrieb von Dapr-basierten Anwendungen und KI-Agenten in der Produktion, bietet all dies bereits heute.

MCP als Infrastruktur. MCP-Serververbindungen werden als Kubernetes-CRDs mit Verbindungsdetails, Anmeldedaten und Zugriffsbereichen deklariert. Keine fest codierte Verbindungslogik im Anwendungscode. Anmeldedaten werden zur Laufzeit aus Secret-Speichern aufgelöst und niemals dem Agenten-Code offengelegt.

Dauerhafte MCP-Toolaufrufe. Jeder MCP-Toolaufruf läuft als Workflow innerhalb des Dapr-Sidecars. Wenn ein Prozess während des Aufrufs abstürzt, wird die Ausführung ab dem letzten Checkpoint fortgesetzt. Lang andauernde Toolaufrufe (Datenbankmigrationen, externe API-Sequenzen, Codeausführung) überstehen Prozess- und Knotenausfälle automatisch.

Middleware-Hooks. Vor und nach jedem Tool-Aufruf ermöglichen konfigurierbare Workflow-Hooks eine tool-spezifische Autorisierung, Audit-Protokollierung, Ratenbegrenzung, Eingabevalidierung und Kostenkontrolle, ohne den Agent-Code zu ändern. Dabei handelt es sich um eigenständige Workflows, die kombinierbar und unabhängig bereitstellbar sind. Hier können Sie OPA oder eine andere Policy-Engine einbinden, um die signierte Historie zu bewerten, bevor ein Tool tatsächlich ausgeführt wird.

Deklarative Workflow-Zugriffsrichtlinie. Ein Kubernetes-CRD, das steuert, welche App-Identitäten bestimmte Workflows und Aktivitäten in einer Zielanwendung starten dürfen. Verwendet SPIFFE/mTLS-basierte Identitäten zur Anruferüberprüfung. Unterstützt Glob-Muster, Regeln pro Anrufer und namespace-weite “Deny-All”-Richtlinien. Wenn eine Richtlinie existiert, wird alles abgelehnt, was nicht ausdrücklich erlaubt ist.

Weitergabe der signierten Historie. Workflows können sich dafür entscheiden, ihre vollständige Ausführungshistorie an untergeordnete Workflows und Aktivitäten zu senden. Jede Identität, die mit einem Workflow in Berührung kommt, signiert die gesammelte Historie mit ihrem Identitätszertifikat. Nachgelagerte Dienste überprüfen die gesamte Kette, bevor sie handeln, und Policy-Engines können diese auswerten.

Human-in-the-Loop mit Nachweis. Agenten können über dauerhafte Workflow-Ereignisse für eine menschliche Genehmigung pausieren. Wenn ein nachgelagertes Tool den signierten Verlauf erhält, kann es kryptografisch überprüfen, ob die Genehmigung tatsächlich stattgefunden hat, und nicht nur, ob ein Protokoll dies angibt.

Stellen Sie sich einen Agenten vor, der eine Kundenrückerstattungsanfrage über einem definierten Schwellenwert bearbeitet. Anstatt sofort ausgeführt zu werden oder zu scheitern, pausiert der Workflow und sendet ein Genehmigungsereignis aus:

Rückerstattungsagent erreicht Schwellenwert von 10.000 $
        │
        ▼
Workflow wird unterbrochen – sendet Genehmigungsanfrage
  — sendet eine Slack-Nachricht an den Kanal „payments-approvals"
  — Aufzeichnungen, deren Genehmigung noch aussteht, im Verlauf der Signaturen
  — legt eine Zeitüberschreitung von 30 Minuten fest
        │
   Manuelle Überprüfungen in Slack
        │
        ├── Genehmigt → Workflow wird fortgesetzt
        │             Genehmigungsschritt unterzeichnet und dem Verlauf hinzugefügt
        │
        └── Ablehnung / Zeitüberschreitung → Workflow wird beendet
                              Ablehnung wird im signierten Verlauf vermerkt
        │
        ▼
Rückerstattungs-Tool erhält Aufruf
  — überprüft, ob der signierte Verlauf den Schritt „human_approval" enthält
  — bestätigt, dass der Zeitstempel der Genehmigung innerhalb des in der Richtlinie festgelegten Zeitfensters liegt
  — bestätigt, dass die genehmigende Identität ein autorisierter Genehmiger ist
  — führt den Vorgang nur aus, wenn alle Prüfungen erfolgreich sind

Die Genehmigung ist kein nachträglich hinzugefügter Protokolleintrag. Es handelt sich um einen signierten Schritt im Ausführungsverlauf, den der Tool-Server überprüft, bevor er tätig wird. Fehlt der Genehmigungsschritt, ist er abgelaufen oder von einer nicht erkannten Identität signiert, wird der Tool-Aufruf abgelehnt und nicht erst nach entstandenen Schäden geprüft.

Die Frage, die sich Unternehmen stellen sollten

Die Frage lautet nicht: “Brauchen wir ein MCP-Gateway?” Wahrscheinlich brauchen Sie eines, und diese sollten auf jeden Fall Teil Ihres Managements für eingehende Verbindungen sein. MCP ist das Protokoll, und Sie benötigen eine Infrastruktur, um Verbindungen zu MCP-Servern in großem Maßstab zu verwalten, das Routing durchzuführen und eine gewisse Ratenbegrenzung vorzunehmen.

Die Frage lautet: Bietet Ihre MCP-Infrastruktur Ihnen Identität, Autorisierung und kryptografischen Beweis?

Kann Ihre KI-Plattform Ihnen genau sagen, welcher Agent einen Aufruf getätigt hat – nicht welche Anmeldedaten verwendet wurden, sondern welche kryptografisch verifizierte Identität? Kann sie Zero-Trust- und “Deny-by-Default”-Richtlinien darüber durchsetzen, was jeder Agent tun darf, verwaltet von Ihrem Plattformteam und unabhängig von den Entscheidungen des LLM durchgesetzt? Kann sie eine manipulationssichere, signierte Nachverfolgungskette erstellen, die jeden Schritt in jedem Agenten-Workflow belegt und von nachgelagerten Diensten in Echtzeit überprüft werden kann, bevor diese handeln?

Wenn die Antwort “Nein” lautet, verfügen Sie nicht über eine Sicherheitsschicht für KI-Agenten. Sie haben einen Router.

Und Router reichen nicht aus.

Erfahren Sie mehr über Catalyst.

Mit einem Experten sprechen