AI Agents und MCP – Warum autonome Agenten oft scheitern und wie Sie das Ruder übernehmen

„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 Stichwort autonome Agenten im 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.

1. Was sind AI Agents und was hat das mit MCP zu tun?

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.

2. Der technische Ablauf – vom Prompt zum Systemaufruf

Erklärung: Der klassische Flow sieht so aus:

1. Der Nutzer gibt einen Prompt (z. B. "Erstelle ein Backup von /etc") ein.
2. Das LLM interpretiert die Absicht und generiert ein MCP‑Payload.
3. Der MCP‑Daemon validiert das Payload gegen ein Policy‑Set.
4. Der Daemon führt den Befehl aus und leitet die Ausgabe zurück.

Beispiel‑Code (Python‑Agent + MCP‑Client):

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.

3. Beispiel 1 – Ein CLI‑Tool per Subprocess starten

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.

4. Beispiel 2 – REST‑API‑Aufruf über MCP

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.

5. Beispiel 3 – Kombination aus LangChain, lokalem LLM und Tool‑Orchestrierung

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):

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:

1. df -h
2. 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.

6. Typische Fehler – Warum viele Projekte im Chaos enden

Kurz‑Checkliste:

1. Definieren Sie eine Whitelist aller erlaubten Aktionen.
2. Setzen Sie Timeouts und Memory‑Limits im MCP‑Daemon.
3. Verwenden Sie Vault‑ähnliche Mechanismen für Secrets.
4. Loggen Sie jedes MCP‑Payload + Response für Auditing.

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.

7. Best Practices – So halten Sie die Kontrolle wieder zurück

1. Policy‑First‑Ansatz – Schreiben Sie das Policy‑File bevor Sie einen Agenten bauen.
2. Sandbox‑Umgebung – Führen Sie MCP zunächst in einem isolierten Container (--security-opt=no-new-privileges) aus.
3. Auditable Logging – Integrieren Sie structured-logging (JSON) und schicken Sie die Logs an Elastic Stack.
4. Fail‑Open vs. Fail‑Secure – Standardmäßig fail‑secure: Wenn ein Payload nicht eindeutig ist, wird es verworfen.
5. Versionierung – Taggen Sie sowohl das LLM‑Modell als auch das MCP‑Binary, damit Sie bei Rollbacks exakt dieselben Versionen wiederherstellen können.

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.

8. Fazit und konkreter nächster Schritt

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:

• Trust but verify – Vertrauen Sie dem LLM, prüfen Sie aber jedes generierte Payload.
• Policy First – Lassen Sie das Policy‑File das Herzstück Ihrer Sicherheitsstrategie sein.
• Iteratives Testing – Beginnen Sie mit einem Minimal‑Set an Befehlen, erweitern Sie schrittweise und beobachten Sie das Logging.

Konkreter nächster Schritt für Sie:

1. Erstellen Sie eine policy.yaml mit einer White‑List der wirklich benötigten Befehle.
2. Deployen Sie den MCP‑Daemon in einem isolierten Docker‑Container (Beispiel‑Befehl oben).
3. Implementieren Sie einen einfachen Python‑Agenten, der das Policy‑File nutzt, und testen Sie ihn mit dem dig‑Beispiel.
4. Analysieren Sie die Logs, passen Sie Timeout‑ und Rate‑Limits an und erweitern Sie die Whitelist nur nach Bedarf.

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.