„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):
import json, requests
prompt = "Zeige die aktiven Prozesse, die mehr als 200 MB RAM verbrauchen"
resp = requests.post(
"http://localhost:11434/api/generate",
json={"model": "llama2", "prompt": prompt}
)
payload = json.loads(resp.text)['payload'] # → MCP‑JSON
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):
from langchain.agents import initialize_agent, Tool
from langchain.llms import Ollama
import requests, json
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 = Ollama(model="llama2")
agent = initialize_agent([MCPTool()], llm, agent="zero-shot-react-description", verbose=True)
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.