Pexon Consulting | 13 Min. Lesezeit | 17.04.2026
TL;DR
LLM Agent Sandboxing ist die Governance-Disziplin, die Banking, Versicherungen und Behörden von KI-Agenten-Produktion trennt. Das Model Context Protocol (MCP) liefert das Protokoll — die Sicherheit kommt aus Tool-Permission-Scoping, Container-Isolation, Human-in-the-Loop-Gates und DSGVO-konformen Audit-Logs. Pexon Consulting, Microsoft Partner mit 80 Mitarbeitern in Deutschland, betreibt diesen Layer als Managed Security Service für regulierte Branchen — inklusive BaFin-MaRisk-kompatibler Dokumentation.
Die Realität in regulierten Branchen 2026
Banken, Versicherungen und Behörden stehen 2026 vor dem gleichen Dilemma: Der Markt drückt auf KI-Einführung, die Regulatorik duldet keine Schönwetter-Architektur. Eine Versicherung in Süddeutschland fragte uns Anfang 2026: „Wir haben 40 potenzielle Use Cases für KI-Agenten. Unser Datenschutzbeauftragter sagt: Alle 40 sind DSGVO-riskant. Unser CIO sagt: Wenn wir jetzt nicht liefern, liefert es der Wettbewerb. Was machen wir?“
Die Antwort ist nicht, die 40 Use Cases zu stoppen. Sie ist auch nicht, 40 Einzellösungen zu bauen. Sie ist ein Sandboxing-Layer, der einmal auditierbar und dann für viele Agenten wiederverwendbar ist. Genau dieser Layer ist für regulierte DACH-Kunden 2026 die entscheidende Investition — und in den meisten Häusern die größte interne Kompetenzlücke.
Der IBM Cost of a Data Breach Report 2025 beziffert Shadow-AI-Breaches 670.000 USD teurer als den Durchschnitt. 97% der Unternehmen mit AI-Sicherheitsvorfall hatten keine AI-Access-Controls. 63% haben keine AI-Governance-Policy. Wer 2026 produktive KI-Agenten fährt, ohne diese Governance-Schicht zu bauen, produziert einen meldepflichtigen Vorfall in Zeitlupe.
Was MCP tatsächlich löst — und was nicht
Model Context Protocol, Anthropics Open Standard vom November 2024, ist der wichtigste Standardisierungsschritt im KI-Agenten-Ökosystem der letzten Jahre. MCP definiert drei Rollen: den Host (das LLM, z.B. Claude), den Client (der Connector) und den Server (der Tool-Anbieter). Jeder MCP-Server exponiert Tools, Ressourcen oder Prompts über ein einheitliches Protokoll. Seit der Spec-Version 2025-11-25 unterstützt MCP Authentication, Authorization, Encryption und Audit Logging als First-Class-Citizens.
Was MCP liefert: Austauschbarkeit. Ein MCP-Server für SharePoint kann ohne Umbau mit Claude, Gemini oder einem selbst gehosteten Llama verwendet werden. Für Enterprise-Architekten ist das ein echter Gewinn — keine Vendor-Lock-ins auf Tool-Ebene.
Was MCP nicht löst: Sicherheit by Default. Das ist keine Kritik am Protokoll, sondern eine Beobachtung. Die Practical-DevSecOps-Analyse aus März 2025 fand in untersuchten MCP-Servern 43% Command-Injection-Flaws und 30% unrestricted URL-Fetching. Drei dokumentierte CVEs im Anthropic-eigenen mcp-server-git 2025 (CVE-2025-68143 bis CVE-2025-68145). Im September 2025 das erste bösartige MCP-Paket, das zwei Wochen unentdeckt blieb und E-Mails exfiltrierte. JFrog entdeckte im Juli 2025 eine RCE-Lücke in mcp-remote (CVE-2025-6514), die über 437.000 Downloads betraf.
Simon Willison schrieb im April 2025, was inzwischen Konsens ist: MCP-Server haben Prompt-Injection-Probleme. Nicht weil das Protokoll schlecht ist, sondern weil ein Tool mit breitem Scope plus ein manipuliertes Dokument im RAG eine Exfiltrationskette ergibt, die durch kein Protokoll allein verhindert wird.
Die vier Sandboxing-Dimensionen, die wir bei Kunden umsetzen
Unser Standard-Sandboxing-Modell für regulierte Branchen baut auf vier Säulen. Jede Säule ist messbar, jede ist auditierbar.
Säule 1 — Tool-Permission-Scoping. Jeder MCP-Server wird mit explizitem, minimalem Scope gestartet. Keine Wildcards. Write-Operationen sind separate Server mit eigenem Deployment.
{
"mcpServers": {
"sharepoint-readonly": {
"command": "mcp-server-sharepoint",
"args": ["--read-only", "--allowed-sites=riskteam-de"],
"env": {
"OAUTH_SCOPE": "Sites.Read.Selected",
"TENANT": "kunde-de.onmicrosoft.com"
},
"sandbox": {
"network": "deny-egress-except:graph.microsoft.com",
"filesystem": "read-only",
"capabilities": "NONE"
},
"requireApproval": ["send_email", "create_item", "delete_*"]
}
}
}Die Allowlist ist immer positiv formuliert. Sites.Read.Selected statt Sites.Read.All. Ein bestimmter Teamsite statt des ganzen Tenants. Write-Tools liegen hinter requireApproval und triggern einen Human-in-the-Loop-Flow.
Säule 2 — Container-Isolation. Jeder MCP-Server läuft in einem eigenen Container mit Read-Only-Filesystem, gedropten Capabilities und restriktiver NetworkPolicy. In Kubernetes-basierten Setups ist das ein Default-Deny-Egress mit expliziter Allowlist auf Azure-OpenAI-Endpoints, Microsoft-Graph-IP-Ranges und die vom Tool benötigten Datenquellen.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: {name: mcp-sharepoint-egress}
spec:
podSelector: {matchLabels: {app: mcp-sharepoint}}
policyTypes: [Egress]
egress:
- to: [{ipBlock: {cidr: 20.190.128.0/18}}] # MS Graph EU
ports: [{port: 443, protocol: TCP}]
- to: [{ipBlock: {cidr: 20.9.152.0/22}}] # Azure OpenAI GWC
ports: [{port: 443, protocol: TCP}]Was das in der Praxis verhindert: Markdown-Bild-Exfiltration, Tool-Call-Exfil über http_get an Drittsysteme, DNS-basierte Covert Channels. Ein Angreifer-Prompt, der den Agent zum curl attacker.example.com bewegt, läuft ins Leere.
Säule 3 — Human-in-the-Loop-Tiering. Nicht jeder Tool-Call braucht einen Menschen. Aber jede Aktion mit Blast Radius außerhalb des Sandboxes tut es. Wir arbeiten mit drei Risiko-Tiers:
- LOW (reine Reads, keine Seiteneffekte): automatische Ausführung, asynchrones Logging.
- MEDIUM (Schreibzugriff auf interne, nicht-kritische Systeme): automatische Ausführung, synchrones Logging, Sample-Review.
- HIGH (Zahlungen, externe Kommunikation, DB-Updates auf Produktions-Tabellen, Zugriffsänderungen): synchroner Approval-Gate mit Evidence-Pack, Fail-Closed bei Timeout.
async def execute_tool(tool, args, risk_tier):
if risk_tier == "LOW":
return await tool(**args)
elif risk_tier == "MEDIUM":
asyncio.create_task(log_async(tool, args))
return await tool(**args)
elif risk_tier == "HIGH":
approval = await request_approval(
context=build_evidence_pack(tool, args),
timeout=300,
fail_closed=True,
)
if not approval.granted:
raise ApprovalDenied(approval.reason)
return await tool(**args)Entscheidend ist der fail_closed=True-Default. Wenn die Approval-Queue nicht erreichbar ist oder der Timeout zuschlägt, wird der Tool-Call abgelehnt — nicht ausgeführt. In regulierten Branchen ist das der einzige auditierbare Default.
Säule 4 — Audit-Log mit DSGVO-konformer Struktur. Jeder Tool-Call landet in einem strukturierten Log, das sowohl Incident-Response (Forensik) als auch DSGVO-Nachweis (Art. 30 Verarbeitungsverzeichnis) bedient.
{
"trace_id": "01HXN...",
"timestamp": "2026-04-17T14:22:01.234Z",
"user_id": "hash_of_sub_claim",
"agent_id": "claims-analyzer-v2.1",
"tool": "sharepoint.search",
"scope": "Sites.Read.Selected",
"input_hash": "sha256:...",
"input_pii_fields": ["customer_name"],
"input_redacted": true,
"risk_tier": "MEDIUM",
"human_approval": null,
"guardrail_flags": [],
"source_doc_ids": ["sp_doc_123"],
"output_tokens": 1842,
"output_risk_score": 0.12,
"retention_days": 2555
}Retention-Dauer 2.555 Tage (7 Jahre) für MaRisk-Kompatibilität in Bankenkontexten. Für DSGVO-Zwecke passen wir retention_days abhängig vom Verarbeitungszweck an. Wichtig: input_redacted=true plus input_hash — so ist der Call forensisch nachvollziehbar, ohne PII im Log zu speichern.
Wo DSGVO und Sandboxing sich konkret überschneiden
Das Mapping der Sandboxing-Schichten auf DSGVO-Artikel, das wir in Kunden-Auditberichten einsetzen:
Der Punkt, der in vielen Audits überraschend wichtig wird: Art. 28. Jeder MCP-Server ist potenziell ein Auftragsverarbeiter. Wenn Sie einen Community-MCP-Server von einem GitHub-Repo betreiben, gibt es keinen AVV — und damit eine DSGVO-Lücke. Unsere Empfehlung: Für produktive Deployments entweder selbst gehostete MCP-Server mit dokumentiertem AVV (intern) oder Commercial-MCP-Services mit vertraglichem AVV.
Warum regulierte Branchen diese Kompetenz extern einkaufen
Wir sehen in Bankkunden und Versicherungen einen konsistenten Pattern: Interne IT-Security-Teams kennen Web-App-Security, Cloud-Security, Network-Security. LLM-Agent-Security ist eine neue Disziplin, in der es in DACH gerade einmal mittleren zweistelligen Bereich an Fachkräften gibt. 37% der CISOs nennen laut Evanta CISO Survey 2025 „Securing AI Agents“ als Top-Issue. Nur 42% bewerten ihre eigene Risikominderung als „very/highly effective“ (Ponemon 2025).
Die Bitkom-Zahl hinterher ist der Kicker: 70% der deutschen Unternehmen nennen Fachkräftemangel als Hindernis bei KI-Einführung, 77% den Datenschutz. Wenn die Leute fehlen, die beides zusammen lösen können, kommt der Weg an externer Expertise nicht vorbei.
Genau hier positionieren wir uns als Pexon Consulting. Nicht als Austausch der internen Security — sondern als spezialisierter Layer on top: Wir bauen den Sandboxing-Stack mit dem internen Team auf, übergeben ihn auditierbar dokumentiert und betreiben ihn optional als Managed Security Layer mit 7×24-Bereitschaft. Für Häuser, die intern keine KI-Security-Kompetenz aufbauen können oder wollen, ist das der pragmatische Weg zu produktiven Agenten ohne Regulatorik-Risiko.
Was ein BaFin-konformes Sandboxing-Setup dokumentiert
Die BaFin’s neunte MaRisk-Novelle (Konsultation 1. April bis 8. Mai 2026, Finalisierung Q3/Q4 2026) bringt erstmals ein explizites Modul AT 4.3.4 für KI-Systeme. Was wir erwarten, basierend auf bereits veröffentlichten Entwurfstexten:
- Governance-Dokumentation pro KI-System (Zweck, Risiko-Einstufung, Verantwortlichkeiten).
- Nachvollziehbarkeit automatisierter Entscheidungen (Tracing, Audit-Logs).
- Betrugsminimierung und Modell-Monitoring (Drift-Detection, ASR-Messungen).
- Notfall- und Ausfallszenarien (was passiert, wenn der LLM-Provider ausfällt oder ein Incident läuft).
- Integration ins bestehende Risikomanagement (Meldewege, Eskalations-Matrix).
Unser Sandboxing-Stack ist dafür vorbereitet: Das Permission-Scoping dokumentiert die Zweckbindung. Die HITL-Tiers dokumentieren die Risiko-Einstufung. Die Audit-Logs liefern die Nachvollziehbarkeit. Die Container-Isolation liefert die Ausfallkontrolle. Das Incident-Runbook integriert mit den bestehenden Meldewegen.
Für Banken, die BaFin-Kompatibilität ab Herbst 2026 brauchen, beginnen wir die Arbeit jetzt. Ein Setup, das auditierbar MaRisk-kompatibel ist, braucht 4-8 Monate von Konzept zu Roll-out — zuzüglich Regel-Auditierung durch die interne Revision und den Wirtschaftsprüfer.
Projekt-Sizing aus Pexon-Kundenprojekten
Diese Zahlen sind Indikationen aus aktuellen Angeboten, keine Festpreise. Der größte Variabilitätsfaktor ist die Integration mit bestehenden Identity- und SIEM-Landschaften.
Häufig gestellte Fragen
Ist MCP DSGVO-konform einsetzbar in Banken und Healthcare?
Grundsätzlich ja, unter Bedingungen: Der MCP-Server muss in EU-Infrastruktur laufen (selbst gehostet oder bei einem Auftragsverarbeiter mit AVV), der Permission-Scope muss minimal sein, Audit-Logs DSGVO-konform strukturiert (PII-Redaction, Retention-Policy), und Write-Tools über Human-in-the-Loop abgesichert. Einfach einen Community-MCP-Server deployen und produktiv schalten ist nicht compliance-tauglich.
Read-Only vs. Write-Tools — wann ist Human-in-the-Loop zwingend?
Read-Only-Tools ohne Seiteneffekte (Dokumenten-Suche, Vektorabfrage, interne API-Reads) sind typisch automatisiert zulässig. Sobald ein Tool einen Seiteneffekt außerhalb des Sandboxes hat — E-Mail senden, DB-Update, externe API-Write, Zahlung, Zugriffsänderung — setzen wir Human-in-the-Loop. Für Banking-Kunden ist jede Aktion mit Kundendaten im Zweifel HITL. Die Mehrkosten durch Approval-Latency sind in unseren Projekten signifikant niedriger als die Incident-Kosten ohne Gate.
Wie verhindere ich Rug-Pull und Tool-Poisoning bei MCP-Servern?
Drei Maßnahmen: Erstens Image-Hash-Pinning statt latest-Tag — jeder Container-Pull geht gegen einen konkreten SHA256. Zweitens Tool-Beschreibungs-Signing: Wir hashen die Tool-Definitionen beim Deployment und prüfen bei jedem Pull auf Abweichung. Drittens Private Registry: MCP-Server werden nie direkt aus öffentlichen Quellen gepullt, sondern durchlaufen eine interne Supply-Chain-Schleife mit Vulnerability-Scan.
Welche Audit-Log-Felder fordert BaFin oder BSI konkret?
Die Rahmenwerke listen keine expliziten Feldnamen — sie fordern Nachvollziehbarkeit, Integrität und Retention. Die Praxis-Interpretation, die in Audits durchgeht: Wer, wann, welches Tool, welcher Input (redacted), welcher Output (redacted), welche Entscheidung (auto/HITL), welches Ergebnis, welche Source-Dokumente. BSI IT-Grundschutz OPS.1.1.5 liefert die Grundstruktur, MaRisk AT 4.3.4 die bankenspezifischen Ergänzungen.
Self-Hosted vs. Cloud-MCP — was sind die Security-Tradeoffs?
Self-Hosted gibt volle Kontrolle über Supply-Chain, Isolation und Audit-Logs. Dafür tragen Sie das Betriebsrisiko und müssen Upstream-Patches selbst einspielen. Cloud-MCP (z.B. Anthropic-gehostete Server) nimmt Betriebslast ab, aber öffnet einen Auftragsverarbeitungs-Pfad und erfordert AVV-Verhandlung mit dem Anbieter. Für regulierte Branchen empfehlen wir Hybrid: Cloud-MCP für uncritische Reads (z.B. öffentliche Websuche), Self-Hosted für alles mit PII oder Write-Scope.
Nächster Schritt
Wenn Sie in einer regulierten Branche KI-Agenten einführen und keine interne LLM-Security-Kompetenz haben, starten wir typischerweise mit einem Sandboxing-Pilot: ein Agent, ein MCP-Server, komplett auditierbar, DSGVO- und MaRisk-konform dokumentiert. Danach Entscheidung über Skalierung oder Managed-Betrieb.
Wenn Ihr Team bereits mit Claude Code arbeitet, ist das Claude Code Security-Audit der schnellste Einstieg: bestehendes Setup prüfen lassen, bevor der Sandboxing-Layer skaliert.
Verwandte Themen
→Indirect Prompt Injection in RAG-Systemen
→Claude Managed Agents DSGVO-konform einsetzen
→Structured Tool Calling mit PydanticAI
