Kapitel 12 — Protokoll-Härtung und Verteidigungen

Zwölfter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: jede Bedrohung aus dem vorherigen Kapitel bekommt eine Verteidigung, keine der Verteidigungen ist eine Silberkugel, und ihre Komposition ist das einzige, was eine tatsächlich deploybare Haltung ergibt.

Warum dieses Kapitel existiert

Das Protokoll wird nicht sicher, indem es deployt wird. Es wird sicher, indem es in einem Stack deployt wird, der die Annahmen, die das nackte Protokoll macht, kompensiert. Kapitel 11 katalogisierte die Bedrohungen; dieses Kapitel geht die Verteidigungen in Engineering-Tiefe durch. Kryptographische Capability-Attestation schließt die Discovery- und Capability-Eskalationsklassen. OAuth-2.1-Scope-Disziplin mit nutzerdelegierten Tokens schließt die Deputy- und Passthrough-Klassen. Begrenzte Sessionlebzeiten schließen die Session-Hijack-Klasse. Sandboxing fängt die Kompromittierungen ab, die Prävention verfehlt. Human-in-the-Loop-Approval fängt die destruktiven Operationen, die der Rest des Stacks automatisieren müsste, um nützlich zu sein. Jede Verteidigung hinterlässt Restrisiko; die Komposition macht die Reste klein genug, um in der Praxis verteidigt zu werden.

In einem Satz: eine verteidigungsfähige MCP-Haltung ist nicht eine Verteidigung, sondern vier — Attestation, Scope-Disziplin, Sandboxing und HITL — bewusst komponiert, weil keine einzelne Schicht ausreicht und kein Modell verlässlich genug ist, um eine von ihnen zu ersetzen.

12.1 AttestMCP: kryptographische Capability-Attestation

Die erste Verteidigung adressiert ein Problem, das durch fast jede Bedrohung läuft: der Host hat keinen Weg zu verifizieren, dass der Server, mit dem er spricht, der ist, der er zu sein behauptet. AttestMCP — auch MCPSec oder signed capability manifests genannt — legt eine Schicht kryptographischer Attestation über die Nachrichtenstruktur des Protokolls. Ein Publisher hält einen langlebigen Signaturschlüssel, registriert in einem Directory oder Transparenz-Log. Das vollständige Capability-Manifest wird zur Release-Zeit gehasht und signiert. Der Host verifiziert die Signatur beim initialize gegen den Publisher-Schlüssel in der Datei und lässt den Server entweder rein, sperrt ihn in Quarantäne oder verweigert die Verbindung.

Die Vorteile sind real. Typosquats können keine gültige Signatur des legitimen Publishers erzeugen. Capability-Eskalation über list_changed-Notifications wird erkennbar, weil ein neues Manifest eine neue Signatur erfordert. Feingranulare Policy — „vertraue GitHub-publizierten Servern für Repositories, aber nicht für E-Mail" — wird durchsetzbar, weil Publisher-Identität nun verifizierbar ist statt behauptet. Die Kosten sind ebenfalls real: Publisher müssen Signier-Infrastruktur betreiben, Transparenz-Logs brauchen einen vertrauenswürdigen Betreiber, und die Policy-Schicht des Hosts muss Revocation verstehen. Die ehrliche Rahmung ist, dass AttestMCP substantielles Engineering ist, kein Checkbox. Und es hat eine Lücke, die benannt gehört: das Manifest signiert was der Server über sich sagt, nicht was er zur Laufzeit tut. Eine signierte Deklaration eines harmlosen Tools kann immer noch eine exfiltrierende Implementierung ausliefern. Attestation ist notwendig, aber nicht hinreichend, weshalb es den Rest des Kapitels gibt.

12.2 OAuth-2.1-Scopes und begrenzte Sessionlebzeiten

Das zweite Cluster zieht das Credential- und Sessionmodell enger. Die Flows von OAuth 2.1 sind reif; die Ingenieurkunst liegt darin, sie richtig zu nutzen. Die erste Disziplin sind schmale Scopes — verlange nur, was die deklarierte Tool-Oberfläche braucht. Je enger der Scope, desto kleiner der Schaden im Fall des Falls. Die Disziplin ist schwerer, als sie klingt, weil nachgelagerte Dienste Scopes oft grob definieren und der schmale Weg mühsam ist; breite Scopes funktionieren beim ersten Versuch und fühlen sich nach Fortschritt an. Die Kosten schmaler Scopes zahlt die Entwicklerin; die Kosten breiter Scopes zahlt die Nutzerin, wenn etwas schiefgeht.

Die Verteidigung gegen Confused Deputy, die Scope-Disziplin allein nicht bietet, sind nutzerdelegierte Tokens. Wo der Upstream das unterstützt, schließt jede Nutzerin ihren eigenen OAuth-Flow ab, und der Server handelt auf dem Token der Nutzerin statt auf seiner eigenen Dienstidentität. Der Deputy verschwindet, weil der Server nicht mehr auf eigene Autorität handelt. Token-Passthrough hat eine andere Lösung: Tokens nicht durchreichen. Der Server hält eigene Credentials, etabliert zur Registrierungszeit, und die Grenze zwischen Host und Server trägt nie ein Token. Begrenzte Sessionlebzeiten adressieren Hijack: Minuten für hochriskante Operationen, Stunden für Routine, mit dauerhafter Workflow-Identität darübergelegt, damit eine mehrstündige Aufgabe Transport-Sessions erneuern kann, ohne die Nutzerin alle fünfzehn Minuten zu fragen. Per-Session-Capability-Binding und Capability-Rekonfirmation bei Session-Erneuerung vervollständigen die Disziplin — beide sind Zustandsverwaltungsarbeit, die der Host explizit machen muss, und viele Implementierungen tun es nicht.

12.3 Sandboxing und Laufzeit-Isolation

Das dritte Cluster anerkennt, dass nicht jede Bedrohung verhindert werden kann und dass eine verteidigbare Haltung Schaden eindämmen muss, wenn Prävention versagt. Prozess-Sandboxing für lokale Server — seccomp auf Linux, App Sandbox auf macOS, AppContainer auf Windows, gVisor für stärkere Isolation — verweigert Dateisystem-, Netzwerk- und Prozesszugriffe standardmäßig und gewährt nur die spezifischen, die der Server braucht. Ein kompromittierter Server, der versucht, eine Passwortdatei zu lesen oder zu einem Angreifer-Endpunkt zu exfiltrieren, findet die Operation auf OS-Ebene abgelehnt, nicht weil sein Code zurückhielt, sondern weil die Sandbox es tat. Netzwerk-Policy für Remote-Server — gegenseitiges TLS, allowlisted Endpunkte, Egress-Filterung — engt die Fläche ein, die ein kompromittierter Remote-Server erreichen kann. Inhalts-Isolation im Host behandelt zurückgelieferten Inhalt mit angemessener Skepsis, bevor er im Kontext des Modells landet: untrusted-Markierungen, HTML-Sanitization, Weigerung, eingebetteten URLs zu folgen. Tool-Call-Sandboxing über capability-bewusste Policies lässt den Host Call-Argumente prüfen und entscheiden, ob er erlaubt, verweigert oder zur Nutzer-Approval eskaliert. Ein spezifisches Risiko, das Namen verdient, ist Seitenkanal-Exfiltration über legitime Tools — ein bösartiges Modell, das Credentials in einer Suchanfrage kodiert — das die Policy-Schicht durch Inspektion von Argumenten statt Endpunkten fängt. Supply-Chain-Isolation schließt die Schleife: der Hash des Binärs wird bei Installation und Update gegen einen signierten Wert im Transparenz-Log verifiziert, sodass ein manipuliertes Binär nicht läuft, selbst wenn das Manifest stimmt.

12.4 Human-in-the-Loop-Approval-Gates

Das vierte Cluster anerkennt, dass manche Operationen niemals automatisiert werden sollten. Destruktive, irreversible oder hochwirksame Aufrufe — Geld senden, Dateien löschen, Produktion verändern — verdienen eine explizite menschliche Entscheidung im Moment, in dem sie passieren. Der Mechanismus ist das HITL-Gate, und die Ingenieurkunst liegt darin, es wirksam zu machen, ohne das System unbenutzbar zu machen. Kategorisiere nach Reversibilität: read-only-Operationen laufen automatisch; zustandsändernde gaten. Präsentiere sinnvoll: ein Modal „Tool-Ausführung erlauben?" ist ein Stempel; ein nützliches Gate zeigt das Tool, die vollen Argumente, die Konsequenz in Klartext und die Herkunft. Vermeide Approval-Müdigkeit mit kontextueller Batch-Approval, in der eine Nutzerin, die „sende Rechnungen an die Kunden des letzten Quartals" anstößt, den Batch einmal genehmigt, statt jede E-Mail zwanzigmal. Lege hochriskante Operationen auf einen Out-of-Band-Kanal — Hardware-Token, Zweitgerät, Step-Up-Authentication, geliehen aus der Finanzindustrie. Halte Operationen sichtbar, auditierbar, rückgängigmachbar. Sampling-getriebene Aufrufe laufen durch dieselben Gates wie agent-initiierte; der Seitenkanal server-initiierter Inferenz darf nicht in einer Nebenwirkung enden, ohne dass die Nutzerin es merkt.

Wert, das festzuhalten: die vier Verteidigungs-Cluster sind nicht austauschbar, und keines reicht für sich. Attestation sagt dir, wer der Server ist; Scope-Disziplin begrenzt, was seine Credentials tun dürfen; Sandboxing dämmt sein Laufzeitverhalten ein; HITL fängt die Operationen, die die anderen drei automatisieren müssten. Ein Team, das nur eine schiff, schifft Sicherheitstheater. Ein Team, das alle vier schiff, hat eine Haltung, die nicht davon abhängt, dass sich das Modell unter adversariellen Bedingungen korrekt verhält — was die einzige Art von Haltung ist, die zu schiffen lohnt, weil kein Modell sich so verhält.

Was Kapitel 12 vorbereitet

Die Sicherheitshälfte des Engineering-Bilds ist nun vollständig. Die andere Hälfte — Frameworks, Deployment-Muster, Performance-Charakteristik und das Testen, das bestätigt, dass das System in Produktion funktioniert — nehmen die verbleibenden Kapitel auf. Kapitel 13 öffnet den Bogen mit den Frameworks und Cloud-Integrationen, die 2025 und 2026 gelandet sind: Strands mit Amazon Bedrock, die AWS-State-Layer-Muster, das Microsoft Agent Framework, LangChain und Semantic Kernel. Die Frameworks zählen, weil niemand produktives MCP aus rohem Protokoll baut, und die Wahl unter ihnen prägt die Engineering- und Sicherheitshaltung in einer Weise, die die Protokollschicht allein nicht festlegt.

Als Nächstes — Kapitel 13: Frameworks und Cloud-Integration. Strands mit Bedrock, die AWS-State-Schicht, Microsofts Agent Framework, LangChain, Semantic Kernel und die drei produktiven Integrationsmuster, auf die Teams unabhängig immer wieder kommen.

Möchtest du das ganze Bild? Das Buch geht jede Verteidigung mit ihren Kosten und verbleibenden Lücken ehrlich benannt durch, behandelt die AttestMCP-Signier-Infrastruktur und die Transparenz-Log-Trade-offs tief und gibt ein durchgearbeitetes Beispiel, wie ein abgestufter Approval-Kontext einen langen Multi-Step-Workflow überlebt. LLM Primer IV auf Amazon →