Du hast alles richtig gemacht. Du hast deine MCP-Server (Model Context Protocol — ein universeller Steckstandard für KI-Tools, quasi USB für Daten) geprüft, Berechtigungen eingeschränkt, Schema-Versionen gepinnt, damit dein AI Agent — ein Programm, das eigenständig Tools benutzt — nur das aufruft, was du freigibst. Deine Agent-Infrastruktur fühlt sich produktionsreif an. Du schläfst gut.

Solltest du nicht.

Denn jedes Tool, das dein Agent aufruft, schickt eine Antwort zurück. Und Stand 25. April 2026 validiert praktisch niemand in der Branche, was in dieser Antwort steckt, bevor sie im Context Window des Agents landet — dem Arbeitsspeicher, in dem das KI-Modell vertrauenswürdige Instruktionen nicht von dem Müll unterscheiden kann, den ein Tool gerade ausgespuckt hat.

Drei Plattformen, derselbe blinde Fleck

Seit Anfang April haben die drei größten KI-Unternehmen Sicherheitsfeatures für Agents ausgeliefert — und alle bewachen die falsche Tür.

Am 8. April hat Anthropic Managed Agents gelauncht — mit scoped Permissions und Credential Storage. Es kontrolliert, welche Tools der Agent aufrufen darf. Was diese Tools antworten? Nicht deren Problem.

Am 16. April hat OpenAI sein Agents SDK aktualisiert — mit automatischem Tracing, einem Logging-System, das jeden Tool Call, jede Übergabe und jedes Guardrail-Event aufzeichnet. Es beobachtet Antworten. Es bereinigt sie nicht. Das ist, als würdest du eine Überwachungskamera installieren, die zusieht, wie jemand mit einem Messer reinkommt, und es brav aufschreibt.

Am 22. April hat Google auf der Cloud Next Agent Gateway ausgeliefert — mit Model Armor, das tatsächlich sowohl Tool Calls als auch Responses bereinigt: Screening auf Prompt Injection, bösartige URLs und Datenabfluss. Google ist, man muss es anerkennen, die einzige große Plattform, die explizit die Response-Seite absichert. Es ist in Preview.

Warum das wichtig ist: Die Tür steht sperrangelweit offen

Die MCP-Spezifikation definiert inputSchema — ein striktes Format für das, was du an ein Tool sendest. Es gibt kein outputSchema. Tool-Responses sind beliebiger Text oder JSON, der ungefiltert ins Reasoning des Modells fließt. Die Spec hat buchstäblich kein Feld für "validiere, was zurückkommt".

Das erzeugt drei Angriffsvektoren, die dir den Schlaf rauben sollten:

Indirect Prompt Injection — ein Tool liefert Content mit eingebetteten versteckten Anweisungen zurück. Der PipeLab State of MCP Security 2026 Report (veröffentlicht im April 2026) dokumentiert einen realen Fall: Ein Angreifer präparierte ein GitHub Issue so, dass die Response den Agent anwies, private Repository-Inhalte zu exfiltrieren, als ein MCP-Server das Issue abrief. "Die Tool-Beschreibungen waren sauber. Das Gift steckte in den Daten, die das Tool zurückgab."

Context Flooding — ein Tool gibt so viele Daten zurück, dass es den Arbeitsspeicher des Agents flutet und kritische Instruktionen aus dem Context Window verdrängt.

Data Exfiltration Chains — eine vergiftete Response weist den Agent an, sensiblen Kontext an ein anderes Tool weiterzuleiten. Das Log-To-Leak Research Paper (veröffentlicht im März 2026) hat das mit GPT-5, Claude Sonnet 4 und anderen demonstriert — mit einer 100%igen Erfolgsrate bei GPT-5 angebunden an einen PayPal MCP-Server und 94,6% Genauigkeit beim Datenabfluss.

Derweil hat am 16. April OX Security 11 CVEs offengelegt, die rund 200.000 MCP-Server-Instanzen betreffen. Anthropics offizielle Antwort: Sanitization sei "Verantwortung der Entwickler". Selbst die OWASP MCP Top 10 (erschienen im April 2026) — der erste Branchenversuch eines MCP-Sicherheitsframeworks — haben keine eigene Kategorie für unvalidierte Tool-Responses. Die Lücke ist so normalisiert, dass die Leute, die die Sicherheitsstandards schreiben, ihr noch keinen Namen gegeben haben.

Der Preis der Lösung

Response Validation einzubauen killt genau die Einfachheit, die MCP überhaupt erfolgreich gemacht hat. Tools bräuchten Output Schemas. Agents bräuchten eine Sanitization-Schicht — etwas wie Microsofts Agent Governance Toolkit (Open-Source seit 2. April), das ein MCP Security Gateway mit Response Inspection enthält. Jeder Call bekommt Parsing-Overhead. Das "einfach Tools einstecken"-Erlebnis stirbt.

Aber die Alternative ist schlimmer.

Was das für dich bedeutet

Bis Response-seitige Validierung überall Standard ist, ist jeder MCP-Server, den du anbindest, eine ungefilterte Pipeline ins Hirn deines Agents. Dein ganzes Security-Budget für Input Gates schützt das falsche Ende des Calls. Wenn du heute Agents in Produktion betreibst, brauchst du entweder Googles Model Armor (Preview), Microsofts AGT oder deine eigene Response-Sanitization-Middleware. "Vertrau dem Tool" ist keine Sicherheitsstrategie.

Du hast die Vordertür verriegelt. Die Hintertür hat kein Schloss. Sie hat nicht mal eine Tür.

Der nächste große Agent-Sicherheitsvorfall wird nicht von einem schlechten Tool Call kommen. Er wird von der Antwort eines Tools kommen.