AI Agents und MCP: Warum autonome Agenten scheitern und wie Sie die Kontrolle behalten

A developer has identified critical failure points in AI agent systems using Machine-Code-Proxy (MCP) interfaces, demonstrating that autonomous agents frequently produce chaotic results rather than reliable tool execution. The engineer's homelab experiments revealed that without properly defined security policies and allow-lists, MCP-based agents can trigger dangerous system behaviors including fork bomb patterns and internal network scanning. The analysis shows that the core problem lies not in the MCP interface itself but in the semantic interpretation of commands and the absence of rate-limiting and security policies, which developers often overlook when building autonomous agent systems.

„Man gibt einem Computer ein Ziel, er geht in die Küche, kauft sich ein Sandwich und bricht das Haus ab.“– Das ist das Bild, das viele von uns beim Stichwortautonome Agentenim Kopf haben. In der Praxis jedoch stellt sich häufig heraus, dass diese „Küchen‑Bots“ mehr Chaos als Ordnung produzieren. In diesem Artikel zerlegen wir das Problem Stück für Stück, zeigen drei echte Code‑Beispiele und geben ein persönliches Fazit, das Sie sofort umsetzen können. Erklärung : Ein AI Agent ist ein Software‑Konstrukt, das basierend auf einem Large Language Model LLM eigenständig Entscheidungen trifft – zum Beispiel, ein Tool aufzurufen, Daten zu verarbeiten oder einen Task zu delegieren. MCP Machine‑Code‑Proxy ist dabei das Bindeglied zwischen dem LLM‑Agenten und den System‑Tools. MCP stellt eine standardisierte Schnittstelle bereit, über die der Agent Befehle in einer strukturierten Form z. B. JSON sendet, die dann vom Proxy in System‑Calls übersetzt werden. Beispiel‑Snippet MCP‑Schema : { "action": "run command", "args": { "cmd": "ls -l /var/log", "timeout": 30 } } Der Agent liefert dieses JSON an den MCP‑Daemon, der dann ls -l /var/log ausführt und das Ergebnis zurückgibt. Persönliche Einschätzung : Viele Entwickler glauben, dass das reine Vorhandensein eines MCP automatisch zuverlässige Tool‑Aufrufe ergibt. Das ist ein Trugschluss – der eigentliche Stolperstein liegt in der Semantik der übermittelten Befehle und der Sicherheits‑Policies , die selten von Grund auf definiert werden. Erklärung : Der klassische Flow sieht so aus: Beispiel‑Code Python‑Agent + MCP‑Client : python import json, requests prompt = "Zeige die aktiven Prozesse, die mehr als 200 MB RAM verbrauchen" 1️⃣ LLM‑Aufruf hier mit Ollama als lokales Modell resp = requests.post "http://localhost:11434/api/generate", json={"model": "llama2", "prompt": prompt} payload = json.loads resp.text 'payload' → MCP‑JSON 2️⃣ MCP‑Client‑Aufruf mcp resp = requests.post "http://localhost:8080/execute", json=payload print mcp resp.json Dieses Minimalbeispiel zeigt bereits, wo die Vertrauenszonen liegen: Das LLM liefert das Payload, das MCP‑Backend prüft es – aber nur, wenn die Policies korrekt definiert sind. Persönliche Einschätzung : In meinem täglichen Homelab habe ich das Schema ein einziges Mal ohne Policy verfasst und sofort endlose fork bomb ‑Muster beobachtet. Ohne eine klare Allow‑List laufen die Agents schnell in unvorhergesehene Systemzustände. Erklärung : Das einfachste Szenario ist, dass ein Agent ein lokales Kommando ausführt – zum Beispiel dig für DNS‑Abfragen. Der MCP‑Daemon übersetzt das JSON in einen subprocess.run ‑Aufruf. Konkretes Beispiel Docker‑Compose‑Setup : version: "3.9" services: mcp: image: ghcr.io/mcp-proxy/mcp:latest ports: - "8080:8080" environment: - "ALLOWED COMMANDS=dig,nslookup" agent: image: ollama/llama2:latest depends on: mcp command: "sleep infinity" Agent‑Payload : { "action": "run command", "args": { "cmd": "dig +short example.com", "timeout": 10 } } MCP‑Log‑Auszug : INFO Incoming request: run command DEBUG Validated command against policy – allowed TRACE Executing: dig +short example.com INFO Command finished, exit code 0, runtime 0.12s Damit erhalten wir die IP von example.com zurück. Persönliche Einschätzung : Das Ganze klingt simpel, bis der Agent plötzlich dig -x 0.0.0.0 ausführt und unser internes Netzwerk scannt. Ohne Rate‑Limiting kann ein gut gemeinter Agent leicht zu einer DoS‑Situation werden. Erklärung : Moderne Tools bieten HTTP‑APIs z. B. GitHub, JIRA . Hier muss der MCP nicht nur curl ausführen, sondern auch Header, Auth und JSON‑Body korrekt handhaben. MCP‑Payload für GitHub‑Issue‑Erstellung : { "action": "http request", "args": { "method": "POST", "url": "https://api.github.com/repos/me/me/issues", "headers": { "Authorization": "Bearer {{$GITHUB TOKEN}}", "Accept": "application/vnd.github+json" }, "json": { "title": "Automatischer Bug‑Report", "body": "Erzeugt von AI‑Agent am $ date " } } } MCP‑Daemon‑Konfiguration policy.yaml : http requests: - domain: "api.github.com" methods: "GET", "POST" max body size: 10KB auth required: true Ausgabe nach erfolgreichem Aufruf : { "status": 201, "response": { "html url": "https://github.com/me/me/issues/42", "number": 42 } } Persönliche Einschätzung : Der Knackpunkt ist die Credential‑Injection . Wenn das LLM den Token aus einem Prompt ableitet, endet das Projekt in einer Sicherheitskatastrophe. In meiner Praxis habe ich deshalb strikt die Token‑Übergabe über die MCP‑Umgebungsvariablen und niemals im Prompt erlaubt. Erklärung : Fortgeschrittene Agents nutzen Bibliotheken wie LangChain oder CrewAI , um mehrere Schritte hintereinander zu planen. Der Agent baut dann einen Chain aus mehreren MCP‑Aufrufen. Python‑Beispiel LangChain‑Chain : python from langchain.agents import initialize agent, Tool from langchain.llms import Ollama import requests, json ---- MCP‑Wrapper ---- class MCPTool Tool : name = "MCP" description = "Executes a system command via MCP" def run self, cmd: str - str: payload = json.dumps {"action": "run command", "args": {"cmd": cmd, "timeout": 20}} r = requests.post "http://localhost:8080/execute", data=payload return r.json .get "output", "" ---- LLM + Agent ---- llm = Ollama model="llama2" agent = initialize agent MCPTool , llm, agent="zero-shot-react-description", verbose=True Prompt: Prüfe das Disk‑Layout und erstelle ein Report‑PDF result = agent.run "run df -h && generate a PDF report with the output" print result Erwartete MCP‑Aufrufe : df -h pandoc -f markdown -t pdf -o /tmp/report.pdf Persönliche Einschätzung : Das Szenario zeigt, warum Komposability ein zweischneidiges Schwert ist. Jeder Zwischenschritt erhöht das Risiko einer Fehlkonfiguration. Ich habe deshalb in allen meinen produktiven Chains ein Fallback‑Mechanismus eingebaut, der bei unbekannten Befehlen die Ausführung stoppt und eine Fehlermeldung zurückgibt. | Fehler | Warum er passiert | Konsequenz | |---|---|---| Ungeprüfte Payloads | Agent liefert beliebige JSON‑Strukturen | Arbiträrer Code‑Execution | Fehlende Rate‑Limits | Keine Beschränkung der Aufrufe | DoS‑Angriffe, Ressourcen‑Exhaustion | Offene Credential‑Weitergabe | Tokens im Prompt eingebettet | Kompromittierte Secrets | Keine Output‑Sanitization | Rückgabe wird direkt weiterverarbeitet | Injection‑Angriffe z. B. Shell‑Injection | Zu breite Allow‑List | ALLOWED COMMANDS= | Unkontrollierter Zugriff auf System‑Tools | Kurz‑Checkliste : Persönliche Einschätzung : In meinem letzten Projekt habe wir alle fünf Punkte vernachlässigt – das Resultat war ein nicht mehr stoppbarer Crash‑Loop, der das gesamte Netzwerk lahmlegte. Ein kurzer Blick auf den MCP‑Log hätte das sofort aufgezeigt. --security-opt=no-new-privileges aus. structured-logging JSON und schicken Sie die Logs an Elastic Stack. Beispiel‑Docker‑Run sichere MCP‑Instanz : docker run -d \ --name mcp-secure \ --restart unless-stopped \ --read-only \ --tmpfs /run \ -e ALLOWED COMMANDS="dig,nslookup" \ -e POLICY FILE="/etc/mcp/policy.yaml" \ -v $ pwd /policy.yaml:/etc/mcp/policy.yaml:ro \ ghcr.io/mcp-proxy/mcp:latest Damit ist das Dateisystem schreibgeschützt und nur die definierte Policy ist einsehbar. AI‑Agents in Kombination mit MCP besitzen ein enormes Potenzial: Sie können Routine‑Tasks automatisieren, komplexe Workflows orchestrieren und sogar in Bereichen wie Incident‑Response glänzen. Aber das gleiche Potenzial birgt das Risiko, dass ein schlecht konfigurierter Agent das gesamte System destabilisiert oder kritische Secrets preisgibt. Mein Fazit : Konkreter nächster Schritt für Sie : policy.yaml mit einer White‑List der wirklich benötigten Befehle. dig ‑Beispiel.Auf diese Weise verwandeln Sie die anfängliche Küchen‑Katastrophe in ein kontrolliertes, nachvollziehbares System – und können die echten Vorteile von autonomen AI‑Agents genießen, ohne dem Chaos zu erliegen.