Startseite

KI-Agenten, MCP & Sicherheit

Verteilte Systeme — Vorlesung 3

Prof. Dr. Alexandra Mikityuk · HTW Berlin · Sommersemester 2026

Master Interaktiv Hands-On

Rückblick VL 2 — KI-Grundlagen

LLMs sagen das nächste Token vorher

Transformer: Self-Attention, parallele Verarbeitung

Training: Pre-Training → Fine-Tuning → RLHF

Claude: Coding-stark, langes Kontextfenster

Senior Developer Workflow: Sie designen, KI implementiert

Halluzinationen: Immer testen & verifizieren!

Heute: Was passiert, wenn ein LLM nicht nur antwortet — sondern handelt?

Von Chat zu Agent — Die Evolution

Stufe 1: Chat

Benutzer fragt, KI antwortet. Kein Zugriff auf externe Daten.

"Wie erstelle ich einen Socket-Server?" → Antwort als Text

Stufe 2: Tool Use

KI kann Werkzeuge aufrufen: Dateien lesen, APIs nutzen, Berechnungen durchführen.

"Lies server.py und finde den Bug" → Datei wird gelesen

Stufe 3: Agent

KI plant, entscheidet und handelt autonom. Nutzt mehrere Tools in einer Schleife.

"Fixe alle Bugs in diesem Projekt" → Plant, liest, fixt, testet

Claude Code ist ein Agent — er liest Ihren Code, entscheidet was zu tun ist, schreibt Dateien, führt Tests aus und iteriert bis zur Lösung.

➡️ Aber was steckt eigentlich in so einem Agenten? Schauen wir uns die Bauteile an.

Was sind KI-Agenten?

Agent = LLM + Werkzeuge + Schleife

Chat ANTWORTET nur. Ein Agent HANDELT — und braucht dafür mehrere Schritte.

🧠 LLM = Gehirn (denkt, plant) 🛠️ Tool = Hände (führt aus)

Die Agent-Schleife

# Start: User-Frage als erste Aktion
action = user_prompt

while not done:
    # 🛠️ Tool führt Aktion aus
    observation = tool.execute(action)

    # 🧠 LLM schaut Ergebnis an,
    #    entscheidet nächste Aktion
    action = llm.decide(observation)

Schleife endet, sobald das LLM sagt: „Ich bin fertig".

Konkretes Beispiel

Szenario: Ein Python-Projekt mit zwei Dateien:

📁 main.py · utils.py

Aufgabe: „Finde alle TODO-Kommentare im Code"

#🧠 LLM-Aktion🛠️ Beobachtung
1list_files(".")main.py, utils.py
2read("main.py")(Datei-Inhalt)
3grep "TODO"2 Treffer ✓
4read("utils.py")(Datei-Inhalt)
5grep "TODO"0 Treffer
6FERTIG — Antwort liefern

6 Iterationen — keiner der zwei Akteure könnte das alleine.

Moment — du nutzt schon einen Agenten

In genau diesem Moment, während ihr zuhört, läuft auf euren Rechnern ein KI-Agent — und ihr merkt es nicht mal.
Sein Name: Claude Code.

Die Schichten — wirklich

🏠 Host: Claude Code

VSCode-Extension auf eurem Rechner

🤖 Agent: der Loop

fest in Claude Code eingebaut

🧠 LLM: Claude Opus 4.7

in Anthropic's Cloud, über das Internet

🛠️ Tools: Read · Edit · Write · Bash · Grep · TodoWrite · Agent (für Subagents)

Live-Beispiel: 7 Schritte pro Antwort

Ihr tippt: „Fixe den Bug in main.py"

#WerWas passiert
1Hostschickt Frage + Datei-Liste an Anthropic-API
2LLMdenkt: „brauche Read("main.py")"
3Agentprüft: ist Read erlaubt? → ja
4Hostöffnet die Datei wirklich, liest die Bytes
5LLMfindet Bug, plant: „brauche Edit(…)"
6Agentfragt euch: „Edit OK?" → ihr drückt ja
7Hostschreibt Bytes, zeigt Diff im Editor

Im Lab nutzt ihr genau diese Schleife — jede Anfrage an Claude Code läuft durch dieses Schema. Multi-Agent inklusive: wenn ich (das LLM) sage „Agent(Explore, …)", startet Claude Code einen zweiten Agenten für die Subaufgabe.

➡️ Schauen wir uns die Schleife jetzt im Detail an — auf Code-Ebene.

Agentic Loop im Detail

Wir haben die Schleife jetzt zweimal gesehen — abstrakt (Slide 4) und live in Claude Code (Slide 5).
Jetzt zoomen wir rein — was passiert in jeder einzelnen Iteration auf Code-Ebene?

„Agentic Loop" ist der englische Industrie-Begriff für genau diese Schleife. Seit 2023 das Herzstück von jedem Tool, das wirklich „Agent" heißt.

Vier Phasen pro Iteration

1. Observe — Kontext erfassen (Dateien, Fehler, User-Prompt)

2. Think — Situation analysieren, nächsten Schritt planen

3. Act — Tool aufrufen (Datei lesen, Befehl ausführen, …)

4. Observe — Ergebnis auswerten → zurück zu 2 (oder fertig)

Vollständiger Code

# Agentic Loop
def agent_loop(user_prompt):
    context = user_prompt

    while True:
        # 🧠 Think
        plan = llm.think(context)

        if plan.is_done:
            return plan.answer

        # 🛠️ Act
        result = execute_tool(
            plan.tool, plan.args)

        # 👀 Observe
        context += result

Wo läuft dieser Loop gerade jetzt? In Claude Code, Cursor, GitHub Copilot Agent, ChatGPT mit Tools, Devin — überall derselbe Pattern: Reason · Act · Observe.

➡️ Damit dieser Loop überhaupt funktioniert, braucht ein Agent eine bestimmte Architektur. Die schauen wir uns als Nächstes an.

Agenten-Architektur

Benutzer

Agent (LLM)

Tool 1: Dateisystem

Tool 2: API

Tool 3: Terminal

Drei Bausteine: Benutzer-Anfrage · das LLM als Steuerzentrale · eine Sammlung von Tools. Verbunden durch den Agentic Loop aus Slide 5.

➡️ Aber wie genau ruft der Agent eigentlich ein Tool auf? Das ist subtiler als es aussieht — gleich mehr.

Tool Use: Wie Agenten Werkzeuge nutzen

Der Agent „ruft" kein Programm auf — er erzeugt einen strukturierten JSON-Request, der Agent-Host führt ihn aus.

Was ist der Agent-Host? Das Programm, in dem der Agent läuft — z.B. Claude Code, Claude Desktop, Cursor oder dein eigenes Python-Skript.

1. LLM generiert
(„Ich brauche dieses Tool")

{
  "tool": "read_file",
  "args": {
    "path": "server.py"
  }
}

2. Agent-Host führt aus
(z.B. Claude Code)

# Host liest die Datei
content = read_file(
  "server.py"
)
# Ergebnis → zurück an LLM

3. LLM analysiert
(plant nächsten Schritt)

# LLM sieht den Inhalt
# und entscheidet:
# → Bug auf Zeile 42
# → nächster Schritt:
#   write_file(...)

Wichtig: Das LLM führt nie selbst Code aus! Es schickt nur den Wunsch als JSON. Der Agent-Host entscheidet, ob und wie er ausgeführt wird. Deshalb fragt Claude Code dich um Erlaubnis, bevor er etwas tut.

➡️ Bisher reden wir von einem Agenten. Was, wenn mehrere zusammenarbeiten müssen?

Multi-Agent Systeme

Mehrere KI-Agenten arbeiten zusammen — jeder mit eigener Rolle und eigenen Werkzeugen.

Planer-Agent

Zerlegt komplexe Aufgaben in Teilschritte. Koordiniert andere Agenten.

Coder-Agent

Schreibt Code, erstellt Dateien, implementiert Features.

Tester-Agent

Führt Tests aus, meldet Fehler zurück an den Coder.

Verbindung zu Verteilte Systeme: Multi-Agent = verteiltes System! Mehrere Prozesse, Nachrichtenaustausch, kein gemeinsamer Speicher, Koordination nötig. Genau das lernen wir in diesem Kurs.

➡️ Multi-Agent ist die eine Skalierung. Aber zurück zur Frage von Slide 7: woher kennt ein Agent überhaupt seine Tools? Wer sagt ihm, was sie können? Hier kommt MCP ins Spiel.

Model Context Protocol (MCP)

  • MCP = offener Standard von Anthropic
  • Standardisierte Schnittstelle zwischen KI und externen Werkzeugen
  • Wie eine "USB-Schnittstelle" für KI-Tools
  • MCP-Server stellt Werkzeuge bereit, MCP-Client (Claude) nutzt sie

Beispiele für MCP-Server:

Dateisystem GitHub Datenbank Slack Web Search Docker

MCP — Architektur

Ohne MCP

  • Jede KI-App baut eigene Integrationen
  • N Tools × M Apps = N×M Integrationen
  • Nicht skalierbar!
  • Jede Änderung betrifft alle Apps

😶

Mit MCP

  • Ein standardisiertes Protokoll
  • N Tools + M Apps = N+M Integrationen
  • Wie USB für Hardware!
  • Neue Tools sofort für alle Apps nutzbar

MCP im Detail: Request/Response

1. Tool-Liste abfragen

// Client → Server
{
  "method": "tools/list"
}
// Server → Client
{
  "tools": [
    {"name": "get_weather",
     "description": "...",
     "inputSchema": {...}}
  ]
}

2. Tool aufrufen

// Client → Server
{
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Berlin"
    }
  }
}

3. Ergebnis

// Server → Client
{
  "content": [{
    "type": "text",
    "text": "Wetter in
    Berlin: 18°C,
    bewölkt"
  }]
}

Das ist JSON-RPC über stdio oder HTTP — ein klassisches Client-Server-Protokoll, wie wir es in Verteilte Systeme lernen!

MCP-Session — Lebenszyklus

Wie ein Telefongespräch: erst „Hallo!", dann reden, dann auflegen. Eine MCP-Session läuft immer in dieser Reihenfolge ab.

Client (z.B. Claude)
MCP-Server
1. initialize — „Hallo, ich bin da"
2. capabilities — „Ich kann diese Tools…"
3. tools/list — „Liste mir alle Tools auf"
4. Tool-Liste mit Namen + Beschreibungen
5. tools/call — „Ruf get_weather(city='Berlin') auf"
6. Ergebnis — „18°C, bewölkt"

Schritte 5+6 wiederholen sich: der Client kann beliebig viele Tools aufrufen — die Session bleibt offen, wie ein laufendes Telefongespräch. Am Ende: shutdown.

Wie kommen die Nachrichten an?

MCP sagt nur, was in den Nachrichten steht (das Format).
Wie die Bytes von A nach B kommen, ist eine eigene Frage.

📨 MCP-Nachricht (JSON)  →  🚚 Transport  →  📨 Empfänger

Wie ein Brief: der Inhalt ist das eine, die Postzustellung das andere.

🌐 HTTP — der Standard

Dieselbe Technik, mit der euer Browser Webseiten lädt. MCP-Nachrichten gehen als HTTP-Requests übers Netzwerk.

HTTP im Detail kommt in einer späteren Vorlesung.

… und es gibt mehr

Für spezielle Fälle existieren weitere Transports: schnellere Varianten für lokale Setups, dauerhafte Verbindungen, …

Details, wenn ihr tiefer in Netzwerk-Protokolle einsteigt.

Take-away: MCP ist die Sprache. Der Transport ist die Leitung. Für heute reicht: meistens HTTP, manchmal andere.

MCP im großen Bild — wo passt es hin?

Programme reden auf vier verschiedene Arten miteinander. MCP ist eine davon — speziell für AI:

1. Funktionsaufruf

Im selben Programm: summe = add(2, 3). Schnell, aber alles muss zusammen sein.

2. Datei lesen/schreiben

Programm A schreibt eine Datei, Programm B liest sie später. Einfach, aber asynchron.

3. Web-API

Wie eine Bestellung im Restaurant: Anfrage rein, Antwort raus. (REST, GraphQL, gRPC — kommt später!)

4. MCP

Einheitlicher Stecker zwischen LLM und Tools — egal welche App, egal welches Tool.

USB-Analogie: vor USB hatte jedes Gerät seinen eigenen Stecker. Heute: ein Stecker für alles. MCP ist USB für AI.

Verfügbare MCP-Server

Dateien & Code

  • Filesystem (Dateien lesen/schreiben)
  • GitHub (Repos, Issues, PRs)
  • GitLab
  • Docker

Daten & APIs

  • PostgreSQL / SQLite
  • Web Search (Brave, Google)
  • Fetch (HTTP-Requests)
  • Memory (persistenter Kontext)

Kommunikation

  • Slack
  • Google Drive
  • E-Mail
  • Eigene Server!

Alle verfügbar auf: modelcontextprotocol.io — Open Source, Community-getrieben. Sie können auch Ihren eigenen MCP-Server bauen!

MCP-Server selbst bauen — die Bauteile

Jeder MCP-Server hat dieselben vier Bauteile. Schauen wir uns einen Wetter-Server an:

Code

# ① Server-Objekt
from mcp.server import Server
server = Server("wetter")

# ② Tool-Decorator
@server.tool()
async def get_weather(city: str) -> str:
    """Aktuelles Wetter abrufen."""
    # ③ Tool-Logik
    return f"In {city}: 18°C"

# ④ Server starten
server.run()

Anatomie

① Server-Objekt — die Hülle. Bekommt einen Namen, mit dem er sich bei Clients meldet.

② Tool-Decorator — sagt: „diese Funktion ist ein Tool, das Clients aufrufen dürfen". Name + Typen werden automatisch ins MCP-Schema übersetzt.

③ Tool-Logik — was wirklich passiert, wenn der Tool aufgerufen wird (API-Call, Datei lesen, DB-Query, …).

④ Server starten — wartet auf Verbindungen und MCP-Nachrichten von Clients.

Mehr Tools? Einfach weitere @server.tool()-Funktionen darunter schreiben — der Server stellt sie automatisch allen Clients zur Verfügung.

anthropic SDK — Tool-Use ohne MCP

So gibt man Claude Tools — direkt im Python-Code, ohne MCP:

import anthropic

client = anthropic.Anthropic()

# 1. Wir definieren das Tool selbst (Schema von Hand)
tools = [{
    "name": "get_weather",
    "description": "Aktuelles Wetter abrufen",
    "input_schema": {
        "type": "object",
        "properties": {"city": {"type": "string"}},
        "required": ["city"]
    }
}]

# 2. Tools mit der Anfrage an Claude schicken
response = client.messages.create(
    model="claude-sonnet-4-6",
    tools=tools,
    messages=[{"role": "user",
               "content": "Wie ist das Wetter in Berlin?"}]
)
# Claude antwortet: „Ich brauche get_weather(city='Berlin')"
# → wir müssen die Funktion JETZT selbst aufrufen + Antwort zurückschicken

Problem: Bei jedem neuen Tool müssen wir das Schema schreiben, die Funktion bauen, das Tool ausführen und die Antwort zurückschicken. Bei 50 Tools wird das mühsam.

Lösung: MCP — der Server liefert die Tool-Definitionen automatisch, der Client muss nichts hardcoden.

End-to-End: Claude + MCP-Server zusammen

Mit MCP: Server einmal schreiben — alle Clients (Claude Code, Claude Desktop, dein Python-Programm) nutzen ihn.

Server (einmal schreiben)

from mcp.server import Server

server = Server("wetter")

@server.tool()
async def get_weather(city: str) -> str:
    """Wetter für eine Stadt."""
    return f"In {city}: 18°C"

server.run()  # läuft auf Port 8000

Client (anthropic SDK)

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    mcp_servers=[{
        "name": "wetter",
        "url": "http://localhost:8000"
    }],
    messages=[{"role": "user",
               "content": "Wetter Berlin?"}]
)

Magie: der Client weiß nicht, welche Tools der Server bietet. Er fragt automatisch nach (tools/list aus dem Lebenszyklus!) — Claude entscheidet, welches Tool er braucht.

Derselbe Server funktioniert mit Claude Code, Claude Desktop, deinem eigenen Programm — überall.

Warum muss man Claude Code etwas sagen?

Problem: Claude Code weiß nicht von alleine, welche MCP-Server auf deinem Rechner laufen sollen.

Lösung: eine Config-Datei mit einer Liste der Server, die Claude Code beim Starten automatisch hochfahren soll.

Datei: ~/.claude/settings.json

{
  "mcpServers": {
    "filesystem": {                      // Name den DU vergibst
      "command": "npx",                  // welches Programm starten
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/pfad"]
    },                                  // ↑ Argumente fürs Programm
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_xxx" }    // geheime Daten
    }
  }
}

Pro Server brauchst du drei Dinge: command (welches Programm) + args (Parameter dafür) + optional env (Umgebungsvariablen, z.B. API-Tokens).

Beim Claude-Code-Start: liest die Datei → startet alle Server → ihre Tools sind sofort für Claude verfügbar.

Was ist npx? Ein Tool aus der Node.js-Welt: lädt ein npm-Paket runter, führt es einmal aus, fertig (kein dauerhafter Install). Hier startet es den MCP-Server, der als npm-Paket veröffentlicht ist. command könnte auch python, node oder eine eigene Binary sein.

Lokale vs. Cloud KI

Lokal (Ollama, LM Studio)

  • Daten bleiben auf Ihrem Rechner
  • Kein Internet nötig
  • Kostenlos nach Hardware-Kauf
  • DSGVO-konform by Design

Aber: Langsamer, weniger fähig (SLMs), braucht gute GPU (16GB+ VRAM ideal)

Cloud (Claude API, GPT API)

  • Viel mächtiger (100B+ Parameter)
  • Sofort verfügbar, keine Hardware nötig
  • Regelmäßige Updates & Verbesserungen
  • Pay-per-Use (Kosten pro Token)

Aber: Daten verlassen Ihren Rechner, Internetabhängig, Kosten

Best Practice: Entwicklung mit Cloud-KI, sensible Daten lokal. Ollama + MCP = lokaler Agent!

➡️ Wenn wir uns für Cloud entscheiden — wohin genau gehen unsere Daten dann? Schauen wir es uns an.

Sicherheit — Wo gehen die Daten wirklich hin?

Falsche Intuition: „Wenn der MCP-Server lokal läuft, bleiben meine Daten lokal." — Stimmt nicht.

Beispiel: lokale Excel-Datei mit Claude Code

📊 Excel-Datei auf deinem Mac (lokal)
🛠️ Lokaler MCP-Server liest sie (lokal)
🏠 Claude Code empfängt den Inhalt (lokal)
↓  HIER verlässt es deinen Rechner
☁️ Claude Code schickt den Inhalt an Anthropic-API (damit das LLM ihn sehen kann)
🧠 Claude (Cloud) liest den Inhalt, antwortet

Lokaler MCP + Cloud-LLM

Dateien werden zwar lokal gelesen — aber der Inhalt geht ans LLM in der Cloud. Anthropic sieht ihn.

100% lokal — nur mit lokalem LLM

Z.B. Ollama als LLM + lokaler MCP-Server. Erst dann verlässt nichts deinen Rechner.

Faustregel: Sensible Daten (Passwörter, API-Keys, Firmendaten) NIEMALS an MCP-Server geben, deren Output an ein Cloud-LLM weitergegeben wird.

Sicherheit — Best Practices

Code-Review

KI-generierten Code immer prüfen — Sicherheitslücken möglich!

API-Keys

Nie in Prompts oder Code einfügen. Immer Umgebungsvariablen nutzen.

MCP-Server

Nur vertrauenswürdige Quellen. Code vorher lesen!

Lokale Modelle

Ollama, LM Studio — alles bleibt auf dem Rechner. Für sensible Projekte ideal.

Verschlüsselung: Wenn MCP über Netzwerk, dann nur über verschlüsselte Kanäle!

Zero-Trust für KI

Never trust, always verify — auch bei KI!

KI-Output nicht vertrauen

  • Code immer testen
  • Fakten verifizieren
  • Security-Review durchführen
  • Keine blinde Übernahme

MCP-Daten nicht vertrauen

  • Quellen prüfen
  • Datenintegrität validieren
  • MCP-Server-Code lesen
  • Netzwerkverkehr überwachen

Alles verifizieren

  • Eingaben validieren
  • Ausgaben prüfen
  • Least Privilege Prinzip
  • Logging & Monitoring

Zero-Trust ist ein Grundprinzip verteilter Systeme — es gilt genauso für KI-Agenten wie für Microservices.

Offene Forschungsfragen

Sichere Kommunikation: Wie können KI-Agenten sicher über Netzwerke kommunizieren?

E2E-Verschlüsselung: Ende-zu-Ende-Verschlüsselung für Agent-to-Agent Kommunikation

Dezentrale KI: Dezentrale Infrastruktur statt Cloud-Abhängigkeit

Verifiable AI: Wie kann man die Integrität von KI-Antworten nachweisen?

Zero-Trust: MCP über sichere Tunnel — Zero-Trust-Architektur für KI-Tools

Sichere KI-Infrastruktur — Bedrohung & Lösung

Sobald MCP über Netzwerk läuft (egal ob Café-WiFi oder Firmen-LAN), gelten klassische Angriffe.
„Intern" ist nicht automatisch sicher.

⚠️ Ohne Schutz: offener Port im LAN

🖥️ MCP-Server 10.0.5.20:8080
↳ Tools: query_db, run_admin
━━━ Firmen-LAN ━━━
💻 Dev-Laptop (legit)
🖨️ Drucker — alte Firmware → kompromittiert
↓ scannt LAN, findet :8080
query_db("SELECT * FROM customers")
→ Kundendaten exfiltriert

Warum: Server lauscht auf offenem Port, keine Auth, jeder im LAN kann anrufen — auch ein gehackter Drucker.

✓ Mit verschlüsseltem Tunnel

💻 Client (outbound)
↓ TLS, Ed25519-Schlüssel
📡 Encrypted Tunnel
↑ TLS, mutual auth
🖥️ MCP-Server (outbound)
→ KEIN offener Port
→ KEIN DNS nötig
→ Drucker findet nichts zum Anrufen

Wie: Beide Seiten bauen ausgehende Verbindung zum Relay auf — kein lauschender Port, mutual auth via Schlüssel.

Bezug zu VS: Das ist Interprozesskommunikation über sichere Kanäle — kombiniert mit Zero-Trust (kein implizites Vertrauen, weder draußen noch drinnen). Kernthema dieses Kurses.

Praxis-Tools: Tailscale · WireGuard · mTLS-only HTTPS · Cloudflare Tunnel · Zero-Trust-Mesh-Networks

Agenten + Verteilte Systeme

KI-Agenten SIND verteilte Systeme!

Verteilte Systeme

  • Mehrere Prozesse
  • Nachrichtenaustausch (Message Passing)
  • Kein globaler Zustand
  • Fehlerbehandlung nötig
  • Konsens-Probleme
  • Skalierung & Lastverteilung

KI-Agenten-Systeme

  • Mehrere Agenten (= Prozesse)
  • MCP-Protokoll (= Message Passing)
  • Jeder Agent hat eigenen Kontext
  • Agenten können ausfallen / halluzinieren
  • Agenten müssen sich abstimmen
  • Mehr Agenten = mehr Durchsatz

Deshalb lernen Sie beides: Die Prinzipien verteilter Systeme helfen Ihnen, KI-Agenten-Systeme zu verstehen, zu bauen und zu debuggen.

Zusammenfassung — VL 3

Von Chat zu Agent: Die Evolution

Agentic Loop: Observe → Think → Act

Tool Use: JSON-basierte Werkzeugaufrufe

Multi-Agent Systeme = Verteilte Systeme

MCP: Standardprotokoll für KI-Tools

MCP-Server konfigurieren & selbst bauen

Lokale vs. Cloud KI

Zero-Trust & Sicherheit bei KI-Tools

Sichere KI-Infrastruktur (Staex)

Agenten = Verteilte Systeme in der Praxis

Links & Ressourcen

MCP & Agenten

Sicherheit & Lokale KI

Vielen Dank!

Fragen?

Prof. Dr. Alexandra Mikityuk

Büro Raum 308

Tel +49 30 5019-2664

Nächste Woche: Prozesse, Threads & Nebenläufigkeit

1 / …