MCP Gateway vs API Gateway: Was Enterprise Agents tatsächlich brauchen

Rezensiert 11. August 2026 · 13 Minuten gelesen

Ein API-Gateway und ein MCP-Gateway sind nicht austauschbar. Ein API-Gateway steuert Netzwerkanforderungen an Dienste. Ein Enterprise-MCP-Gateway muss auch Agent-Tool-Aufrufe verstehen, die genauen Argumente an delegierte Autoritäten binden, den aktuellen Mandats- und Widerrufsstatus überprüfen, Wiederholungen verhindern, Tool-Ergebnisse filtern und Beweise für die Aktion erstellen. Die stärkste Architektur besteht aus ihnen: ausgereifte Verkehrssteuerungen beibehalten und dann eine agentenbewusste Autorisierungsschicht hinzufügen.

Dieser Artikel richtet sich an Plattform- und Sicherheitsingenieure, die entscheiden, ob ein bestehendes Gateway konsequente MCP-Tools sicher vorführen kann. Das Ergebnis ist eine konkrete Aufteilung der Verantwortlichkeiten und eine Testvorrichtung, gegen die Sie beide Designs ausführen können.

Für die Produktauswahl und eine reproduzierbare Bewertungsvorrichtung verwenden Sie die Enterprise MCP Gateway GuideFür das breitere Autorisierungsmodell verwenden Sie die AI Agent Authorization GuideFür das MCP-spezifische Autoritätsmodell hinter diesem Vergleich lesen Sie MCP Autorisierung für Enterprise Tools.

MCP Gateway vs API Gateway in einer Tabelle

Ein API-Gateway kann viele Steuerelemente erzwingen, die eine MCP-Bereitstellung benötigt.

Die Tabelle bedeutet nicht, dass jedes Produkt, das als MCP-Gateway vermarktet wird, die rechte Spalte implementiert. "MCP-bewusst" kann Protokollübersetzung oder Werkzeugerkennung bedeuten.

API-Gateways besitzen immer noch wichtige Kontrollen

Bauen Sie keine TLS-Terminierung, Routing, Verbindungslimits, Anforderungsgrößendurchsetzung, Ratenbegrenzung, WAF-Integration und Service-Beobachtung innerhalb eines Agentenprodukts neu auf.

Der externe Autorisierungsfilter von Envoy kann beispielsweise Anforderungskontext an einen HTTP- oder gRPC-Autorisierungsdienst senden und die Anforderung ablehnen, bevor sie den Upstream erreicht. failure_mode_allow ist falsch, und die Dokumentation warnt, dass Route-Cache-Änderungen nach der Autorisierung einen Bypass verursachen können. Dokumentation des Beauftragten ext authz ist ein nützliches modell, um einen agentenautorisierer im verkehrspfad zu platzieren, ohne vorzugeben, dass der filter selbst mandate versteht.

Ein API-Gateway kann auch OAuth-Zugriffstoken validieren. Die Autorisierungsspezifikation von MCP verwendet OAuth-Konventionen und erfordert eine Ressourcen- oder Publikumsbindung, so dass ein für einen MCP-Server ausgegebenes Token von einem anderen nicht akzeptiert wird. Die MCP Authorization Specification Dies authentifiziert den Zugriff auf den MCP-Ressourcenserver und beweist nicht, dass der Agent die Bestellung erstatten kann. 8421 für 480 EUR.

MCP ändert das Policy-Thema

Eine herkömmliche Routenpolitik könnte sagen:

principal.role == "support" && route == POST /refunds

Eine Agent-Transaktion benötigt mehr Kontext:

type AgentTransaction = {
  agentId: string;
  organisationId: string;
  sponsor: string;
  mandateId: string;
  action: 'refund.create';
  resource: `order:${string}`;
  purpose: string;
  amount: string;
  currency: string;
  destination: 'original_payment_method';
  audience: string;
  requestDigest: `sha256:${string}`;
  nonce: string;
};

Bei der Richtlinie handelt es sich nicht nur um den OAuth-Client, sondern um den Agenten unter einer bestimmten Delegation einer verantwortlichen Organisation. Das Gateway muss die Identität von Mandanten und Agenten aus verifizierten Anmeldeinformationen und nicht aus von Anrufern ausgewählten Headern ableiten.

MCP-Tools sind modellgesteuerte Operationen mit Schemata. Die offizielle Tools-Spezifikation verlangt, dass Server Eingaben validieren und Zugriffskontrollen implementieren, und sie weist Clients an, Tool-Annotationen als nicht vertrauenswürdig zu behandeln, es sei denn, sie kommen von vertrauenswürdigen Servern. MCP-Tools definiert die Drahtobjekte, nicht die Semantik der Geschäftsbehörde des Unternehmens.

Binden Sie den Tool Call durch jede Transformation

Die meisten MCP-Server rufen schließlich ein HTTP-, gRPC- oder Queue-basiertes Backend auf. Eine Autorisierungsentscheidung über die MCP-Argumente kann irrelevant werden, wenn die Übersetzung ihre Bedeutung ändert.

Verwenden Sie einen kanonischen Digest über den Tool Call:

const normalized = canonicalJson({
  tool: 'issue_refund',
  arguments: {
    order_id: 'ord_8421',
    amount: '480.00',
    currency: 'EUR',
    destination: 'original_payment_method',
  },
  audience: 'mcp://support.example/tools',
});

const requestDigest = sha256(normalized);

Wenn MCP Middleware 48 EUR autorisiert hat, aber der Adapter 480 EUR sendet, verweigern Sie dies vor der Ausführung.

Dies bedeutet, dass das Gateway eine explizite Zuordnung vom Werkzeugschema zu stabilen Aktions- und Ressourcenkennungen benötigt:

tools:
  issue_refund:
    action: refund.create
    resource: 'order:{arguments.order_id}'
    protected_arguments:
      - amount
      - currency
      - destination
      - reason
    max_body_bytes: 16384

Ein Produktionsmapper muss unbekannte Argumente, mehrdeutige Zahlenformate und Schemaversionen zurückweisen, die er nicht versteht.

Autorisierungsauftrag Angelegenheiten

Die agentenbewusste Schicht sollte eine deterministische Verifizierungsreihenfolge verwenden:

1. Erzwingen Sie Transport- und Objektgrößenbeschränkungen.
2. Parse MCP JSON-RPC und validieren Sie das Eingabeschema des Tools.
3. Authentifizierung des Laufzeit-Tokens oder des Proof- und Pin-Mieters und des Publikums.
4. Beheben Sie Emittenten, Schlüssel, Pass und aktuellen Widerrufsstatus.
5. Überprüfen Sie die Mandatssignatur, das Zeitfenster und den Betreff.
6. Canonicalize den Anruf und vergleichen Sie die Anfrage Digest.
7. Fordern Sie die Beweis-Nonce in einem freigegebenen Replay-Store an.
8. Bewerten Sie Aktion, Ressourcen, Zweck, Ziel und Budget.
9. Atomisch reserviert einmalige oder kumulative Mandatsnutzung.
10. Führen Sie mit einem Downstream-spezifischen Credential aus.
11. Filtern Sie das Ergebnis und senden Sie einen Aktionsbeleg aus.

Eine gewöhnliche API-Richtlinie kann die Schritte 1 bis 3 ausführen und Schritt 8 an einen externen Autorisierenden weiterleiten, sie erfasst die verbleibende Semantik nicht nur, weil der vorgeschaltete MCP spricht.

Replay und Retry sind separate Probleme

Eine Proof-Nonce verhindert, dass der gleiche signierte Beweis zweimal akzeptiert wird. Ein Idempotenzschlüssel verhindert, dass eine absichtlich wiederholte Geschäftsaktion zweimal ausgeführt wird.

const replayKey = `${verificationMethod}\0${audience}\0${proofNonce}`;
const claimed = await replayStore.claimOnce(replayKey, proofExpiresAt);
if (!claimed) return deny('REPLAY_DETECTED');

const operation = await idempotencyStore.getOrCreate({
  tenantId,
  key: businessIdempotencyKey,
  requestDigest,
});
if (operation.digestConflict) return deny('IDEMPOTENCY_CONFLICT');

Wenn der Replay-Store nicht verfügbar ist, sollten materielle Aktionen fehlschlagen geschlossen. Low-Risk-Reads haben möglicherweise eine explizit andere Richtlinie. Eine generische Gateway-Einstellung, die alle Anfragen erlaubt, wenn die Autorisierung nicht verfügbar ist, ist zu breit für irreversible Tools.

Widerruf muss die Datenebene erreichen

Ein Unternehmen kann einen Agentenschlüssel, einen Pass, ein Mandat oder ein übergeordnetes Mandat vor seinem natürlichen Ablauf widerrufen.

Cache nach Ziel-ID und Record observed_at. Ein zwischengespeichertes "aktives" Ergebnis ist nicht dauerhaft. Für eine Rückerstattung oder Zahlung, ablehnen, wenn der Widerrufszustand älter ist, als es die Aktionsrichtlinie zulässt. Für einen öffentlichen Katalog kann ein längeres Fenster sinnvoll sein.

Die Kundendatenebene sollte während eines Ausfalls der Steuerungsebene weiterhin die signierte lokale Richtlinie bewerten, jedoch nur solange ihre Vertrauenseingaben gültig bleiben.

Beweise gehen über ein Access Log hinaus

Ein API Access Log zeigt möglicherweise eine 200 für tools/callEine Aktionsquittung kann den Agenten, die Organisation, das Mandat, den Anforderungsverdau, die politische Entscheidung, den Werkzeugergebnisverdau und die nachgelagerte Referenz binden.

Diese Quittung beweist, was der Emittent unterschrieben und aufgezeichnet hat, sie beweist nicht, dass der Kunde die Rückerstattung verdient hat oder dass der Zahlungsabwickler die Wahrheit gesagt hat.

Für eine vollständige Transaktion Walkthrough, siehe vom MCP-Toolaufruf zur auditierbaren UnternehmenstransaktionFür Log- und Quittungsunterschiede siehe AI Agent Audit-Trail-Leitfaden.

Reproduzierbare Gateway-Bewertung

Führen Sie das gleiche Fixture gegen den API-only-Pfad und den agentenbewussten Pfad aus:

{
  "tool": "issue_refund",
  "arguments": {
    "order_id": "ord_8421",
    "amount": "480.00",
    "currency": "EUR",
    "destination": "original_payment_method"
  },
  "expected_action": "refund.create",
  "expected_resource": "order:ord_8421"
}

Ein Feld pro Test mutieren:

Erfassen von Entscheidungscodes, Anzahl der vorgelagerten Anrufe und Quittungen: Ein bestandener Test bedeutet, dass verweigerte Varianten niemals das Backend erreichen und die gültige idempotente Wiederholung einen einzigen Geschäftsvorgang erzeugt.

Aktueller Intelliger und OATI Grenze

OATI bietet derzeit ein Entwickler-Preview-Framework mit Schemata, kanonischer Signatur, Vertrauensauflösung, deterministischer Mandatsbewertung, Wiederholungsprüfungen, Quittungen und TypeScript-Middleware. Das öffentliche Repository enthält einen Referenz-Envoy, Authorizer, Valkey und Lookup-Integrationstest.

Dabei handelt es sich nicht um eine vollständig betriebene Kunden-Gateway-Flotte. Produktionsausfallübungen, verlängerte Parallelitätstests, dauerhafte Evidenz-Workflows und unabhängige kryptographische und Protokollprüfungen bleiben unvollständig. Das breitere Enterprise Agent Gateway-Produkt, der Richtlinieneditor, die Genehmigungswarteschlange und der verwaltete Lebenszyklus sind Ziel- oder MVP-Komponenten, keine ausgelieferten Produktionsansprüche.

Intelliger baut KI-Systeme, die Folgearbeit sicher ausführen können. Agent Trust Architektur erklärt, wie das Enterprise Agent Gateway und OATI zu dieser Unternehmensdefinition passen.

Checkliste der Durchführung

• Behalten Sie das API-Gateway für Transport, Routing und Netzwerkrichtlinien.
• Fügen Sie einen MCP-bewussten Normalizer für Tool, Aktion, Ressource und Argumente hinzu.
• Ableiten von Agenten- und Mieteridentität aus verifizierten Anmeldeinformationen.
• Binden Sie kanonische Tool-Argumente durch die endgültige Ausführungsanforderung.
• Bewerten Sie kurzlebige delegierte Autorität in deterministischem Code.
• Separate Beweiswiederholung von Business-Idempotenz.
• Verbreiten Sie den Widerruf mit aktionsspezifischen Frischegrenzen.
• Reserve Einmal- und Budgetstaat atomar.
• Filtern von Tool-Ausgaben unter Ziel- und Datenrichtlinie.
• Emittieren Sie überprüfbare Beweise, ohne Geheimnisse in Quittungen zu speichern.
• Test-Bypass, Mutation, Wiederholung, Ausfall und unsichere Ausführung.

Expertenüberprüfung vor der Veröffentlichung erforderlich: Ein Sicherheits- und MCP-Protokoll-Reviewer sollte die Autorisierungsreihenfolge, das OAuth-Audience-Handling, die Route-Bypass-Analyse, die Replay-Semantik und alle Ansprüche auf Produktionsbereitschaft überprüfen.

Bereit, die Grenze zu testen? Dokumentation der OATI-Entwickler und Prüfer bevor Sie ein Managed Gateway Design auswählen.