MCP Security: Bedrohungen, Kontrollen und Verifizierung
MCP-Sicherheitskontrollen für Token, Tools, Discovery, Sessions und Ausführung, mit einer Bedrohungsmatrix und lauffähigen Referenztests für anforderungsgebundene Autorisierung.
MCP-Sicherheit schützt die Grenzen zwischen einem Client, seinem Modellkontext, MCP-Servern und den Systemen, die diese Server erreichen können. Beginnen Sie mit der Authentifizierung des beabsichtigten Anrufers, der Validierung der beabsichtigten Ressource des Tokens, der Einschränkung der verfügbaren Tools und der Überprüfung jeder Folgeaktion vor der Ausführung. Fügen Sie Steuerelemente für Such-URLs, nicht vertrauenswürdige Werkzeuginhalte, Sitzungen, Anmeldeinformationen und unsichere Ergebnisse hinzu. Eine erfolgreiche MCP-Verbindung stellt nicht die Berechtigung für jede Geschäftsaktion her.
Dieser Leitfaden richtet sich an Ingenieure, die MCP-Verbindungen implementieren oder bewerten. MCP Gateway Guide umfasst Gateway-Architektur und Auswahl, während die AI Agent Authorization Guide Verwenden Sie die drei zusammen, ohne eine einzelne Komponente als vollständige Sicherheitsgrenze zu behandeln.
MCP Sicherheitsgrenzen und Bedrohungsmodell
Inventarisierung der Komponenten, die Daten einführen, Zugriff gewähren oder einen externen Effekt verursachen können; lokale Server, die als Prozesse gestartet werden, Remote-Server, die über HTTP erreicht werden, Identitätsanbieter, Gateway-Betreiber, Tool-Register und nachgelagerte APIs; eine Serverbeschreibung, eine Tool-Antwort oder ein abgerufenes Dokument ist eine Eingabe, die bewertet werden muss, nicht eine Befugnis, die Berechtigungen des Agenten zu erweitern.
Untrusted documents and tool descriptions
| data, never permission
v
Client and model -> authenticated MCP boundary -> approved server
| |
exact tool/action policy separate downstream access
| v
approval and reservation -> protected business system
|
outcome and reconciliation evidence
Der Beamte MCP-Sicherheit Die folgenden Steuerelemente kombinieren diese Protokollbedenken mit einem ursprünglichen Enterprise-Action-Design. Das Business Approval and Operation-State-Modell ist keine zusätzliche Anforderung der MCP-Spezifikation.
Bedrohungs- und Kontrollmatrix
| Bedrohung | Durchsetzungsstelle | Akzeptanztest | Einziehungsberechtigter |
|---|---|---|---|
| Token für eine andere Ressource | Ressourcenserver-Authentifizierung | Ablehnen vor Werkzeugversand | Identitätsteam |
| Geschmiedeter oder fehlender Hauptkontext | Authentifizierungsadapter | Kein Werkzeugzugriff mit nicht verifizierter Identität | Identitätsteam |
| Tool-Aufruf übersteigt genehmigten Zweck | Handlungsermächtigung | Denied Call erreicht niemals Upstream | Security und Process Owner |
| Tool-Argumente ändern sich nach Genehmigung | Standardisierung und Genehmigungsbindung anfordern | Geänderte Nutzlast macht Genehmigung ungültig | Prozessüberprüfer |
| Discovery oder Redirect erreicht private Dienste | Grenze des ausgehenden Netzes | Block nicht erlaubtes Ziel auf jedem Hopfen | Plattformteam |
| Sitzungskennung, die von einem anderen Anrufer wiederverwendet wird | Sitzung und Hauptbindung | Andere Anrufer können keinen Zugriff erben | Serverbetreiber |
| Tool Output versucht Autorität zu erweitern | Agent Runtime und externe Durchsetzung | Unzuverlässige Anweisungen können kein neues Tool freischalten | Anwendungsteam |
| Ergebnis nach dem Versand verloren | Dauerhafter Betriebszustand | Retry versöhnt sich, anstatt sich blind zu wiederholen | Einsatzteam |
Weisen Sie jede Zeile einer tatsächlichen Komponente zu. Ein Produktname in einem Diagramm ist unzureichend: Identifizieren Sie die Konfiguration, den Eigentümer, wie sie bereitgestellt wird und was passiert, wenn die Abhängigkeit nicht verfügbar ist. Überprüfen Sie auch direkte Routen um den Durchsetzungspunkt. Ein eng konfigurierter Proxy kann keine Anmeldeinformationen einschränken, die es dem Agenten ermöglichen, das vorgelagerte System unabhängig zu kontaktieren.
Token und Downstream Credential Separation
Verwendung der MCP-Genehmigungsspezifikation, Version 2025-11-25, für HTTP-Transportberechtigungsanforderungen. Validieren Sie, dass der Zugriff für die Ressource bestimmt ist, die ihn empfängt. Akzeptieren Sie kein Token, nur weil es gut ausgebildet ist oder weil ein vertrauenswürdiger Emittent es signiert hat. Emittent, Empfänger, Ablauf und erforderliche Berechtigungen haben separate Bedeutungen.
Für einen Proxy, der eine nachgelagerte API aufruft, ist der nachgelagerte Zugriff unabhängig zu gestalten. Die offizielle Sicherheitsanleitung verbietet das von ihr beschriebene Token-Passthrough-Muster. Ein an einer Grenze akzeptierter Anmeldenachweis darf nicht stillschweigend zu einem allgemeinen Anmeldenachweis für jeden dahinter stehenden Dienst werden. Wiederverwendbare Geheimnisse außerhalb von Modelleingaben, generierten Text- und Werkzeugergebnissen aufbewahren.
Das herunterladbare Labor unten beginnt bewusst nach der Identitätsprüfung. verified Ein Feld ist eine injizierte Testprämisse, keine kryptographische Überprüfung. In einer echten Integration leiten Sie den Hauptkontext von einem validierten Anmeldeinformationen und vertrauenswürdigen serverseitigen Zustand ab. Akzeptieren Sie niemals die Behauptung eines Clients, dass seine eigene Identität oder Genehmigung bereits verifiziert wurde.
Eine geprüfte Referenzkonfiguration
Download der Agent Control Lab 1.0.0. Es enthält eine kleine Policy-Engine, Tests, einen synthetischen signierten Beleg und einen Verifier. Extrahieren Sie das Archiv und führen Sie die Befehle mit Node.js 20 oder höher aus. Es gibt keine Abhängigkeiten oder Netzwerkaufrufe.
node --test lab.test.mjs
node verify.mjs evidence.json demo-public-key.pem
Die Referenzpolitik in control.mjs erlaubt ein Werkzeug, einen Mandanten, einen Agenten und ein Ziel.
const policy = {
audience: 'https://gateway.example.test/mcp',
tenant: 'example-lab',
agent: 'evidence-worker',
tool: 'publish_evidence_draft',
destination: 'https://records.example.test/drafts',
maxBytes: 4096,
};
Die Richtlinie ist ausführbare Konfiguration für den Referenzsimulator, nicht Konfiguration für Kong, Portkey oder einen anderen Anbieter. Sie zeigt, wie eine autorisierte Aktion eine kleine, explizite Oberfläche haben kann. Der Request Digest bindet ein festes Tupel von Mandanten, Agenten, Werkzeug, Ziel, Körper und Idempotenzschlüssel. Die Kodierung ist spezifisch für dieses Beispiel und ist kein OATI- oder JCS-Profil.
Die Suite testet einen zulässigen Entwurf, einen übereinstimmenden Wiederholungsversuch, geänderte Inhalte, den mieterübergreifenden Zugriff, verbotene Tools, ungültige Genehmigung, Ausfälle und einen Timeout nach dem Versand. Ausgeblendete Geräte geben null simulierte vorgelagerte Sendungen an. Der Timeout-Fall bleibt unsicher und ein Wiederholungsversuch ruft den Stub nicht erneut auf. Diese Eigenschaften sind nützliche Akzeptanzkriterien, die in einen Integrationstest mit dem echten Gateway und dem geschützten System aufgenommen werden können.
Discovery, Sessions und lokale Server benötigen separate Tests
Das Labor implementiert keine Netzwerkerkennung, einen DNS-Resolver, HTTP-Weiterleitungen, OAuth, einen MCP-Transport oder eine Prozessisolierung. Fügen Sie Tests für diese Oberflächen hinzu, anstatt einen bestandenen Policy Unit-Test als End-to-End-MCP-Sicherheit zu beschreiben.
Zum Auffinden zähle jede URL auf, die deine Implementierung abruft. Überprüfen Sie erlaubte Schemata und Ziele, aufgelöste Adressen, Umleitungen und das Verhalten der Verbindungszeit. Eine Hostnamenprüfung vor der DNS-Auflösung stellt nicht von selbst fest, dass die eventuelle Verbindung sicher ist. Beschränken Sie die Netzwerkerreichbarkeit sowie die Anwendungskonfiguration. Zeichnen Sie blockierte Versuche auf, ohne Anmeldeinformationen in der angeforderten URL zu protokollieren.
Bei Sitzungen binden Sie den Sitzungszustand an den authentifizierten Anrufer und den erforderlichen Ressourcenkontext. Üben Sie Wiederverbindung, Ablauf, Identitätsänderung und gleichzeitige Clients aus. Vermeiden Sie es, den Besitz einer Sitzungskennung als unabhängige Berechtigung zur Verwendung von Tools zu behandeln.
Fehlerverhalten und Freigabenachweise
Notieren Sie den sicheren Zustand für jeden Abhängigkeitsfehler. Ein fehlendes Policy-Ergebnis sollte nicht in die Erlaubnis für ein Folgeschreiben übersetzt werden. Wenn eine vorgelagerte Antwort verloren geht, bewahren Sie die Operations-Kennung und unterscheiden Sie ein unbekanntes Ergebnis von einer abgelehnten Anforderung. Abgleichen mit dem geschützten System, bevor Sie entscheiden, ob eine andere Ausführung sicher ist.
Speichern Sie genügend Beweise, um die Entscheidung und die anschließende Beobachtung zu erklären: Hauptreferenz, normalisierter Request Digest, Richtlinienversion, Genehmigungsreferenz, Betriebskennung, Versandstatus und beobachtetes Ergebnis. Leitfaden für den Audit-Trail erklärt, warum eine gültige Signatur die Integrität unter einem Schlüssel festlegt, aber nicht feststellt, dass jede signierte Behauptung wahr ist.
Vor der Veröffentlichung die Tests nach Änderungen des Werkzeugschemas, der Authentifizierungsbibliothek oder der Richtlinien wiederholen; das geschützte System direkt in abgelehnten Fällen beobachten; Umgehungsrouten und Bedienerzugriff in die Überprüfung einbeziehen; der Referenzsimulator verwendet eine In-Memory-Karte in einem synchronen Prozess; er weist keine verteilte Atomität, Crash-Wiederherstellung, dauerhafte Beweissicherung oder Produktionsbereitschaft nach.
Aktuelle Umsetzungsgrenze und nächste Maßnahme
Die Agent-Trust-Architektur von Intelliger trennt die Argumentation von Autorisierung und Ausführung. OATI bleibt eine Entwicklervorschau. Das Referenzlabor ist Schulungsmaterial, nicht der bereitgestellte OATI-Service oder eine zertifizierte Implementierung. Unabhängige Sicherheitsüberprüfungen und Tests Ihrer tatsächlichen Umgebung bleiben vor einer Produktionsfreigabe erforderlich.
Beginnen Sie mit dem herunterladbaren Labor und ordnen Sie dann jedes Akzeptanzkriterium der Komponente zu, die es durchsetzt. AI Agent Sicherheit. Die Guide Library und Agent Trust Übersicht bieten die umgebende Architektur und den Implementierungskontext.