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

> Source: <https://dev.to/uhltak/ai-agents-und-mcp-warum-autonome-agenten-scheitern-und-wie-sie-die-kontrolle-behalten-516m>
> Published: 2026-05-29 18:00:04+00:00

„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.
