MCP Gateway Security: Kontrollen und Fehlertests
Sichern Sie ein MCP-Gateway gegen Token-Verwirrung, Werkzeugvergiftung, Argument-Mutation, prompte Injektion, Wiederholung, Mieter-Crossover und Durchsetzung Bypass.
MCP-Gateway-Sicherheit hängt von erzwungener Identität, Serverherkunft, Tool-Richtlinie, Argumentautorisierung, Anmeldeinformationen und Bypass-Widerstand ab. Das Sanieren einer Eingabeaufforderung oder das Ausblenden eines Tools vor Entdeckung hindert einen Client nicht daran, es direkt aufzurufen. Der geschützte Server muss weiterhin unbefugte Anfragen ablehnen.
Die MCP Gateway Guide Der folgende Testplan geht davon aus, dass ein Gateway bereits ausgewählt wurde und fragt, ob seine Steuerungen unter feindlichen Eingaben und unterbrochenen Abhängigkeiten bleiben.
Erstellen Sie die Threat Map
| Bedrohung | Präventive Kontrolle | Test |
|---|---|---|
| Token auf falschem Server verwendet | Ressourcen- und Zielgruppenvalidierung | Replay-Server A-Token auf Server B |
| Schadhafte Serverregistrierung | Eigentümer, Erlaubnisliste, Herkunft und Überprüfung | nicht genehmigter Endpunkt registrieren |
| Änderungen der Werkzeugbeschreibung | signierte oder angeheftete Metadaten digesten | Änderung der Beschreibung nach der Genehmigung |
| Argumentsubstitution | Canonic Request Digest | Änderungsbetrag vor dem Versand |
| prompte Injektion Triggers Werkzeug | externe deterministische Richtlinie | Einbetten von Anweisungen in ein abgerufenes Dokument |
| Angabe der Anmeldeinformationen | vermittelte vorgelagerte Anmeldeinformationen | Inspect Modell und Client Kontext |
| Doppelte Nebenwirkung | Replay Claim plus Domain-Idempotenz | Rennen zwei identische Anrufe |
| Mieter-Crossover | mietergebundenes Routing und Speicherung | Wiederverwendung von IDs über zwei Mieter hinweg |
| Gateway Bypass | Netzwerkpolitik und Dienstidentität | Upstream direkt |
OWASP Agentische Sicherheitsinitiative Das Gateway kann einige dieser Risiken mindern, aber nur, wenn es sich um den obligatorischen Ausführungspfad handelt.
Validierung von Token und Metadaten
Für den HTTP-Transport folgen Sie dem MCP-Berechtigungsspezifikation. Suchen Sie Metadaten mit geschützten Ressourcen durch kontrolliertes HTTP-Verhalten ab, validieren Sie HTTPS- und Issuer-Richtlinien und Cache mit begrenzter Stallheit. Akzeptieren Sie niemals einen Autorisierungsserver nur, weil ein nicht vertrauenswürdiger MCP-Server ihn benannt hat.
function validateMcpAccess(ctx: RequestContext) {
assertApprovedServer(ctx.serverUri);
assertTrustedIssuer(ctx.token.issuer, ctx.serverUri);
assertAudience(ctx.token, ctx.serverUri);
assertNotExpired(ctx.token);
assertScopes(ctx.token, ctx.requiredScopes);
assertTenantBinding(ctx.token, ctx.tenantId);
}
RFC 9728 Behandeln Sie Metadaten als Sicherheitsinput und nicht als harmlosen Discovery-Text.
Autorisieren Sie genaue Tool-Argumente
Die JSON-RPC-Anfrage mit dem deklarierten Schema vergleichen, unerwartete Felder nach Möglichkeit ablehnen, Werte normalisieren und den vollständigen geschützten Umschlag hashen. Der Umschlag sollte Server-Audience, Werkzeugname, Argumente, Auftraggeber, Agent, Grant, Transaktions-ID, Nonce und Ablauf enthalten.
Ein Tool namens send_email kann ein geringes Risiko für einen Bestimmungsort und ein hohes Risiko für eine externe Massenliste sein. execute_sql Lösen Sie Domain-Identifier und den aktuellen Status auf, bevor Policy-Returns dies zulassen.
Drift für die Genehmigung:
{
"approved": { "tool": "issue_refund", "order": "9182", "amount_minor": 4500 },
"submitted": { "tool": "issue_refund", "order": "9182", "amount_minor": 45000 },
"expected": "REQUEST_DIGEST_MISMATCH"
}
Bauteilfehler proben
Geben Sie nicht das gesamte Gateway failOpen Verhalten nach Aktionsrisiko und fehlender Abhängigkeit definieren. Eine öffentliche Lektüre kann ein Limited-Stale-Policy-Bundle verwenden. Eine Lieferantenzahlung sollte beendet werden, wenn ein Widerruf, eine Replay-Reservierung oder ein aktueller Lieferantenzustand nicht festgestellt werden können.
Notieren Sie mindestens Autorisierungsergebnis, Grundcode, Request Digest, Server, Tool, Policy Digest, Trace ID, Versandstatus und Upstream-Referenz.
Überprüfung der MCP Gateway Architektur und MCP Tool-Call Autorisierung Details zur Umsetzung. Der live Intelliger Übersicht über die Plattform ist der relevante Produktpfad.
Das öffentliche Gateway und die OATI-Komponenten von Intelliger bleiben die Entwickler-Vorschau-Technologie.
Fragen zur Sicherheitsüberprüfung
Filtert die Tool-Liste eine Sicherheitskontrolle?
Es reduziert die Exposition und hilft Kunden, versehentliche Anrufe zu vermeiden, aber es ist keine ausreichende Autorisierung. tools/call direkt. Erzwingen Sie die gleiche Client-, Tool- und Argumentierungsrichtlinie im Call-Pfad und, wo möglich, erneut beim geschützten Dienst. Testen Sie den Aufruf eines versteckten Tools, ohne vorher eine Entdeckung durchzuführen.
Wie sollten Tool Metadaten vertrauenswürdig sein?
Behandeln Sie Namen, Beschreibungen und Schemata als Input für die Lieferkette, binden Sie die Zulassung zur Serveridentität, zum Endpunkt und zu den überprüften Metadaten. Entscheiden Sie, welche Änderungen Quarantäne erfordern. Eine reine Beschreibungsänderung kann ein Modell auch dann noch manipulieren, wenn das Eingabeschema konstant bleibt.
Was schützt vor verwirrten Abgeordneten?
Bind Caller, vertreten als Principal, Mandant, Zielserver und exakte Aktion. Lassen Sie niemals einen Client ein Token für einen anderen Server präsentieren oder bitten Sie das Gateway, seinen eigenen breiten Service Credential ohne Downstream-Richtlinie weiterzuleiten. Der geschützte Server validiert die Zielgruppe und authentifizierte Gateway-Identität und überprüft dann die anforderungsgebundene Entscheidung oder seine eigene Domain-Richtlinie.
Wie werden Outputs kontrolliert?
Regeln für Größe, Typ und Empfindlichkeit von Tool-Antworten anwenden; verhindern, dass Anmeldeinformationen und interne Fehler in den Modellkontext zurückkehren; nicht vertrauenswürdige Inhalte markieren, bevor sie wieder in die Planung eingehen, so dass sie sich nicht als Systemanweisung ausgeben können; Ausgabekontrollen machen den Inhalt nicht wahr; Quelle und Serverherkunft für spätere Entscheidungen beibehalten.
Welche Leugnungsereignisse verdienen Warnungen?
Warnung bei Falschaudienz-Tokens, wiederholten Anrufen mit versteckten Instrumenten, mieterübergreifenden Identifikatoren, Fehlanpassungen bei der Genehmigungsverdauung, Wiederholungskonflikten, Metadatendrift und Direktroutenversuchen; eine normale Ablehnung der Richtlinien kann erwartet und für Produktfeedback nützlich sein; getrennte angriffsähnliche Signale von gewöhnlichen Geschäftsbeschränkungen, damit Betreiber die lauten Kontrollen nicht deaktivieren.
Was beweist ein Gateway-Empfang?
Es kann bestätigen, dass das Gateway eine benannte Anfrage ausgewertet und einen Versand oder eine Antwort unter einer angegebenen Policy-Version beobachtet hat. Es kann nicht nachweisen, dass der Server keine alternative Route hatte, dass eine vorgelagerte Antwort wahrheitsgemäß war oder dass das spätere Geschäftsergebnis abgeschlossen wurde.
Halten Sie eine bösartige Vorrichtung absichtlich langweilig. Verwenden Sie einen gültigen Benutzer, einen genehmigten Server, einen gewöhnlichen Werkzeugnamen und plausible Argumente, aber ändern Sie eine geschützte Ziel- oder Mandantenkennung. Sicherheitsdemonstrationen konzentrieren sich oft auf offensichtliche Injektionszeichenfolgen, während der teuerste Fehler eine gut geformte Anfrage ist, die eine Geschäftsgrenze überschreitet. Das erwartete Ergebnis sollte die fehlgeschlagene Einschränkung benennen und beweisen, dass der Upstream keinen Anruf erhalten hat.
Eine permissive Region oder ein vergessener direkter Endpunkt reicht aus, um die Richtlinie optional zu machen.