MCP-Modul-Codestandard

Aktualisierung — 2026-08-18: CoSAI Token-Austausch, MCP Project Sandboxing Baseline, OWASP GenAI Baseline, Ruby SDK Bugs — das Autorisierungsmuster und die Deployment-Baseline

Vier Entwicklungen liefern das Autorisierungsmuster und die Deployment-Baseline, die dieser Codestandard brauchte.

1. CoSAI Token-Austausch (18. August) — das Autorisierungsmuster. Jedes MCP-Modul sollte an der Vertrauensgrenze ein Token austauschen, keine dauerhaften Anmeldedaten halten. Token läuft in Minuten ab mit sofortigem Widerruf.

2. MCP Project Sandboxing Baseline (16. August) — die Deployment-Baseline. Jedes MCP-Modul-Deployment muss OS-Level-Sandboxing (Landlock/Seatbelt/Windows ACL) enthalten.

3. OWASP GenAI MCP Server Security Baseline (18. August) — die Entwicklungsreferenz. Die Verzeichnisstruktur, Tool-Registrierung und Fehlerbehandlung dieses Standards mappen zu OWASP GenAI-Entwicklungskontrollen.

4. MCP Ruby SDK Bugs (16. August) — neue CVE-Klassen bestätigen defensive Haltung. Ruby SDK DoS erweitert Rate-Limiting-Anforderung; Directory Traversal erweitert Input-Validierungs-Anforderung. Siehe die MCP Security Hardening Checklist.

Update — 2026-08-15: DeepSeek Harness — "alles ist ein Plugin" validiert das Modul-Muster

DeepSeek open-sourcte den DeepSeek Harness am 13.-14. August 2026 — eine MIT-Runtime basierend auf dem Cordis Meta-Framework. Prinzip: "alles ist ein Plugin." 33.000+ GitHub-Sterne in Stunden.

Warum ein Codestandard wichtig ist

Jeder Connector, den wir ausliefern, sieht gleich aus. Das ist kein Zufall — es ist Disziplin. Wenn eine zweite Integration hinzukommt, sind die Fähigkeiten des Agenten einfacher zu testen, zu auditen und auszutauschen, weil jedes MCP-Modul derselben Struktur, Namensgebung und demselben Fehlervertrag folgt.

Dieses Dokument definiert den Standard für alle MCP-Module im IdeaBosque-Orchestrierungs-Backbone. Es behandelt Verzeichnislayout, Werkzeugregistrierung, Eingabe-/Ausgabeschemas, Fehlerbehandlung, Ratenbegrenzung, Audit-Logging und die Behandlung der PII-Grenze.

Verzeichnisstruktur

Jedes MCP-Modul liegt in seinem eigenen Verzeichnis unter app/mcp_modules/ mit einem einheitlichen Layout:

app/mcp_modules//
  __init__.py
  module.py          # Werkzeugregistrierung + Handler
  schemas.py         # Pydantic-Modelle für Eingabe/Ausgabe
  tests/
    test_module.py
  README.md

Werkzeugregistrierung

Jedes Modul registriert seine Werkzeuge über eine Standardschnittstelle. Der Orchestrierungs-Backbone entdeckt Werkzeuge durch das Suchen nach dem Einstiegspunkt register_tools() — ohne manuelle Verdrahtung.

def register_tools(registrar):
    """Alle von diesem Modul bereitgestellten Werkzeuge registrieren."""
    registrar.tool(
        name="search_catalog",
        description="Lieferantenkatalog nach SKU oder Name durchsuchen",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # Aufrufe pro Minute
    )

Fehlerbehandlung

Module müssen typisierte Exceptions auslösen, keine bloßen Strings. Der Backbone fängt MCPToolError-Subklassen ab und wandelt sie in strukturierte Antworten um, über die der Agent räsonieren kann:

• MCPAuthError — Anmeldedaten fehlen oder sind abgelaufen
• MCPRateLimitError — Ratenbegrenzung des Upstream-Systems erreicht
• MCPTimeoutError — Upstream-Aufruf hat das konfigurierte Timeout überschritten
• MCPValidationError — Eingabe hat die Schemavalidierung nicht bestanden
• MCPUpstreamError — Upstream-System hat einen Fehlerstatus zurückgegeben

Ratenbegrenzung

Jedes Werkzeug deklariert seine eigene Ratenbegrenzung im Registrierungsaufruf. Der Backbone setzt diese pro Agent, pro Werkzeug und pro Zeitfenster durch. Wenn ein Limit erreicht wird, erhält der Agent eine 429-Antwort mit einem Retry-After-Header — er stürzt nicht ab und wiederholt nicht blind.

Audit-Logging

Jeder Werkzeugaufruf wird protokolliert mit: Zeitstempel, Agent-ID, Werkzeugname, Eingabe-Hash (nicht die rohe Eingabe — PII-Grenze), Ausgabestatus, Dauer und Upstream-System. Logs werden als strukturiertes JSON geschrieben und an die Observability-Pipeline gesendet.

„Jeder Werkzeugaufruf wird protokolliert und ist auditierbar" ist kein Feature, das wir später hinzufügen. Es ist das Erste, was der Standard verlangt.

Behandlung der PII-Grenze

Module müssen angeben, welche Eingabefelder PII enthalten. Der Backbone hasht diese Felder vor dem Protokollieren und sendet niemals rohe PII an die Audit-Pipeline. PII-Felder werden im Schema markiert:

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

Wenn pii=True gesetzt ist, ersetzt der Audit-Logger den Wert durch einen SHA-256-Hash. Der Werkzeug-Handler erhält weiterhin den rohen Wert — die PII-Behandlung wird an der Logging-Grenze durchgesetzt, nicht innerhalb der Geschäftslogik.

Update — 2026-08-06: Transport-mode security — the stateful streamable-HTTP attack surface

CVE-2026-16496 (CVSS 10.0, patched in Terraform MCP Server on August 5, 2026) is the first maximum-severity CVE in the MCP ecosystem and the first production evidence that the transport mode is a security dimension, not just an operational one. The vulnerability is a session-hijacking authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This adds a transport-mode-security rule to the deployment-hardening standard:

5. Prefer stateless transport; treat stateful streamable-HTTP as a security risk. The MCP 2026-07-28 specification moved to a stateless protocol core — the initialize/initialized handshake and Mcp-Session-Id header are removed, and stateful workflows use explicit handles instead of server-side sessions. The stateless design eliminates the session-hijacking attack class at the architecture level: a stateless server has no session to steal. The stateful streamable-HTTP transport mode that CVE-2026-16496 exploits is the mode the stateless core is designed to replace. If a module must run stateful streamable-HTTP (for compatibility with a client that has not migrated), treat it as a known-vulnerable configuration: bind it to a private network, require authentication on every session, and plan the migration to stateless transport on the same 12-month clock as the SSE deprecation. A module that exposes stateful streamable-HTTP on a public interface without authentication is in the same risk class as the 1,467 servers Trend Micro found with zero auth — plus the session-hijacking vector.

The OX Security advisory also expanded with additional CVEs beyond the original four exploit families: CVE-2026-30618, CVE-2026-33224, CVE-2026-30617 (Family 1 — STDIO command injection), CVE-2026-30625 (Family 2 — Upsonic allowlist bypass), CVE-2026-30615 (Family 3 — Windsurf prompt injection), CVE-2026-26015 (Family 4 — SSRF), plus CVE-2025-65720 (GPT Researcher RCE), CVE-2026-30623 (LiteLLM RCE), CVE-2026-30624 (Agent Zero RCE), and CVE-2026-54449 (LangBot RCE). The expanded inventory extends the supply-chain risk beyond MCP servers to the agent frameworks and orchestration layers that wrap them — signed provenance, pinned versions, and AIBOM manifests (the dependency control for MCP) are what make the expanded inventory detectable before it fires.

Deployment-Härtung: Setzen Sie MCP-Server niemals ohne Authentifizierung frei

Die STDIO-Härtungsregeln adressieren Schwachstellen auf Code-Ebene. Eine separate Expositionsdimension trat im Juli 2026 zutage, und sie landete in der Referenzimplementierung selbst. Zwischen dem 11. und 21. Juli 2026 wurden drei CVEs gegen das offizielle MCP Python SDK eingereicht — die Referenzimplementierung, von der jeder Python-MCP-Server erbt:

• CVE-2026-59950 — fehlende Host/Origin-Validierung. Eine Webseite, die das Opfer besucht, kann seinen lokalen MCP-Server über DNS-Rebinding und CSRF steuern. Der Browser wird zum Proxy des Angreifers in einen Loopback-Server, den der Betreiber für privat hielt.
• CVE-2026-52869 — unverifizierte Session-Anfragen. Der HTTP-Transport bedient Session-Anfragen ohne Verifikation der Session und ermöglicht unbefugten Zugriff.
• CVE-2026-52870 — offene Task-Handler. Experimentelle Task-Handler erlauben jedem Client, auf den Task eines anderen Clients zuzugreifen.

Weitere CVEs trafen in derselben zwei Wochen beliebte Server: meta-ads-mcp (CVE-2026-54547 / -54549, Auth-Token-Wiederverwendung + SSRF), LangBot (CVE-2026-54449, authentifizierte RCE), ToolHive (CVE-2026-58196, SSRF) und mcp-atlassian (GHSA-g5r6-gv6m-f5jv, beliebige Datei-Lesen). Das Muster ist kategorielevel, nicht isoliert: MCP wurde für Localhost-Loopback entworfen, Teams setzten es im Internet ein, und die Sicherheitsgrundlagen — Authentifizierung, Origin-Validierung, Eingabeprüfung — wurden übersprungen. Dass die Referenzimplementierung dieselbe Fehlerklasse wie die Community-Server ausliefert, ist die Bereitstellungshärtungs-Evidenz, die dieser Standard adressiert: die Authentifizierungs- und Origin-Validierungsregeln unten sind nicht aspirativ — sie schließen die Grundursache hinter CVE-2026-59950 und CVE-2026-52869.

Ein korrigierter Folgescan von Trend Micro fand 1,467 öffentlich zugängliche MCP-Server ohne Authentifizierung oder Verschlüsselung — fast verdreifacht von den ursprünglichen 492, nicht die zuvor zitierten "~2,000". Die Eskalation ist nicht nur die Zahl: 1,227 der 1,467 laufen auf dem veralteten SSE-Transport (die Bevölkerung, die sowohl von der 28. Juli-Spec-Migration als auch von der Sicherheitsbelastung am stärksten betroffen ist), das execute_sql-Tool erscheint auf 70 Hosts, "Graphiti Agent Memory" (ein agentischer MCP-Server) auf 39 Hosts — ein erstklassiges Ziel für die Exfiltration speicherresidenter Daten — und mindestens drei Server exponieren Patientenkrankheitsakten über ein "progress_note"-Tool. Die Bedrohung weitete sich von lokalen STDIO-Konfigurationen auf in der Cloud bereitgestellte MCP-Server aus, die aus dem Internet erreichbar sind. Viele dieser Server setzten fest codierte Anmeldedaten, Werkzeug-Endpunkte und Systemzugriff jedem aus, der den Port erreichen konnte.

BlueRock Security: 36.7% von 7.000+ MCP-Servern anfaellig fuer SSRF. BlueRock Security analysierte ueber 7.000 MCP-Server und fand, dass 36.7% potenziell anfaellig fuer Server-Side Request Forgery sind \u2014 ein groesserer Korpus als Trend Micros Scan von 1.467 exponierten Servern und eine andere Vulnerability-Klasse. SSRF erlaubt einem Angreifer, einen MCP-Server dazu zu zwingen, Anfragen an interne Netzwerkressourcen zu senden, die der Server erreichen kann, der Angreifer aber nicht \u2014 Cloud-Metadaten-Endpoints, interne APIs, Datenbanken. Die 36.7% sind die neue aggregierte Vulnerability-Statistik: mehr als jeder dritte MCP-Server kann dazu gebracht werden, das interne Netzwerk zu sondieren. Fuer B2B-Deployments ist die SSRF-Risiko akut, da MCP-Server typischerweise Zugriff auf interne Systeme (ERP, CRM, Inventar-Datenbanken) haben \u2014 ein Server, der ein Lieferantenkatalog abruft, kann umgeleitet werden, um den Cloud-Metadaten-Endpoint abzurufen und Credentials zu leaken.

Drei zusaetzliche CVEs tauchten in der Juli 2026-Welle auf und erweiterten die CVE-Zeitleiste ueber die offiziellen SDK-Schwachstellen hinaus:

• CVE-2025-68143 \u2014 Path Traversal. Ein MCP-Server ermoeglicht Dateizugriff ausserhalb des vorgesehenen Verzeichnisses durch manipulierte Pfadargumente, was beliebiges Dateilesen auf dem Agent-Host ermoeglicht.
• CVE-2025-68144 \u2014 Argument Injection. Ein Tool, das Kommandozeilenargumente akzeptiert, kann dazu gezwungen werden, zusaetzliche Flags auszufuehren, die der Operator nicht beabsichtigte, aehnlich dem STDIO-Allowlist-Bypass-Pattern, das im OX Security-Vier-Regeln-Standard oben dokumentiert ist.
• CVE-2025-68145 \u2014 Repository-Scoping-Bypass. Ein Server, der auf ein einziges Repository beschraenkt sein sollte, kann auf Repositories ausserhalb seines deklarierten Bereichs zugreifen und privaten Code und Secrets exponieren.

cyberdesserts.com bestaetigte, dass die Protokollrevision vom 28. Juli 2026 die Authorization-Model-Luecke nicht schliesst \u2014 die strukturelle Vulnerability, die es einer kompromittierten Tool-Beschreibung oder einem Output ermoeglicht, Agent-Verhalten zu uebernehmen, besteht in der finalen Spezifikation weiter. Das Stateless-Redesign verbessert die betriebliche Effizienz, behandelt aber nicht MCP03 (Tool Poisoning), MCP06 (Intent Flow Subversion) oder MCP10 (Context Over-Sharing). Die Governance-Schicht bleibt Verantwortung des Operators \u2014 und dieser Standard ist der Implementierungsvertrag fuer diese Verantwortung.

Spec-Final-Migrationshinweise (28. Juli 2026). Die MCP 2026-07-28-Spezifikation wurde als final veroeffentlicht mit einer 12-Monats-SSE-Deprecation-Policy: Der SSE-Transport ist deprecated und muss innerhalb von 12 Monaten zum Streamable-HTTP-Transport migriert werden. Alle vier Tier-1-SDKs (Python, TypeScript, Java, Kotlin) haben kompatible Versionen veroeffentlicht. Module, die den SSE-Transport verwenden, muessen migriert werden; Module, die STDIO verwenden, sind nicht betroffen. Die Migration ist eine Transport-Layer-Aenderung \u2014 die Tool-Registrierungs-, Fehlerbehandlungs-, Rate-Limiting- und Audit-Logging-Regeln in diesem Standard sind transport-agnostisch. Der Modulvertrag aendert sich nicht; nur das Transport-Binding aendert sich.

Die Regeln der Deployment-Härtung:

1. Setzen Sie niemals einen MCP-Server auf einer öffentlichen Schnittstelle ohne Authentifizierung frei. Jeder MCP-Server — egal ob STDIO-, SSE- oder HTTP-Transport — muss eine Authentifizierung verlangen (OAuth 2.1 mit PKCE, API-Schlüssel oder mTLS). Ein Server, der unter 0.0.0.0:3000 ohne Authentifizierung erreichbar ist, ist eine Oberfläche für Remote-Code-Ausführung, keine Entwicklungserleichterung.

2. Binden Sie an Localhost oder ein privates Netzwerk. Produktions-MCP-Server binden an 127.0.0.1 oder ein privates Subnetz. Wenn externer Zugriff erforderlich ist, leiten Sie über einen Reverse-Proxy mit Authentifizierung, Ratenbegrenzung und TLS-Terminierung — nicht über direkte Portfreigabe.

3. Codieren Sie niemals Anmeldedaten in MCP-Konfigurationsdateien fest. Der Trend-Micro-Scan fand fest codierte API-Schlüssel, Datenbankpasswörter und OAuth-Secrets in öffentlich zugänglichen MCP-Serverkonfigurationen. Anmeldedaten müssen aus Umgebungsvariablen oder einem Secrets-Manager stammen — niemals aus einer JSON-Datei, die ein Angreifer lesen kann.

4. Verschlüsseln Sie den gesamten Transport. STDIO ist per Definition nur lokal, aber SSE- und HTTP-Transporte müssen TLS verwenden. Ein Klartext-HTTP-MCP-Server in einem öffentlichen Netzwerk setzt jeden Werkzeugaufruf — einschließlich Authentifizierungstokens und PII — der Abfangbarkeit auf Netzwerkebene aus.

Der Trend-Micro-Scan ist das deploymentseitige Komplement zur OX-Security-Advisory: die Schwachstellen auf Code-Ebene (nicht bereinigter STDIO, Allowlist-Umgehungen, Konfigurationsinjektion) werden fernausnutzbar, wenn der Server selbst ohne Authentifizierung freigegeben ist. Code-Härtung ohne Deployment-Härtung ist eine abgeschlossene Tür auf einer offenen Veranda.

Update — 2026-08-07: MCP-Server-Erkennbarkeit und Governance — die Black-Hat-2026-Produktdimension

Das vollständige Black-Hat-2026-Produktinventar (crn.com, 4. August 2026) fügt dem MCP-Code-Standard eine neue Dimension hinzu: MCP-Server-Erkennbarkeit und Governance. Drei auf der Black Hat USA 2026 lancierte Produkte adressieren direkt die Lücke zwischen dem Code-Standard (der regiert, wie ein Modul geschrieben wird) und der Deployment-Realität (die regiert, wie viele Module existieren und wer sie kennt).

1. Cyera Agent Guardian — Schatten-MCP-Server-Erkennung. Der Code-Standard geht davon aus, dass jedes MCP-Modul registriert, dokumentiert ist und der Verzeichnisstruktur und dem Fehlervertrag folgt. Cyeras Produkt offenbart die Lücke: Schatten-MCP-Server, die dem Code-Standard nicht folgen, existieren in den meisten Unternehmen. Der Code-Standard regiert genehmigte Module; Cyera entdeckt nicht genehmigte.

2. SailPoint Identity Security — MCP-Server-Identitätslebenszyklus. Der Code-Standard regiert, wie sich ein Modul authentifiziert. SailPoints Produkt fügt die Lebenszyklusdimension hinzu: jeder MCP-Server hat eine Identität, die durch einen Identitäts-Governance-Workflow bereitgestellt, attestiert und widerrufen werden muss. Ein Modul mit hartcodierten Anmeldeinformationen kann nicht durch den Identitätslebenszyklus gesteuert werden; ein Modul mit OAuth 2.1 und verwalteten Anmeldeinformationen kann.

3. Check Point AI Network Firewall — Netzwerkebenen-MCP-Kommunikationsüberwachung. Der Code-Standard regiert, was ein Modul auf Anwendungsebene protokolliert. Check Points Produkt fügt die Netzwerkebenendimension hinzu: der MCP-Kommunikationskanal ist nun auf Netzwerkebene überwachbar. Ein Modul, das seine Tool-Aufrufe auf Anwendungsebene nicht protokolliert, kann auf Netzwerkebene überwacht werden, aber ein Modul, das auf beiden Ebenen protokolliert, produziert einen vollständigen Audit-Trail.

Die Black-Hat-2026-MCP-Server-Erkennungsprodukte fügen dem Code-Standard eine „Erkennbarkeit und Governance"-Dimension hinzu: ein Modul, das der Verzeichnisstruktur, dem Fehlervertrag und den Sicherheitsregeln folgt, ist ein gut geschriebenes Modul, aber ein Modul, das auch in einer Identitäts-Governance-Plattform (SailPoint) registriert, durch ein Schattenserver-Erkennungstool (Cyera) erkennbar und auf Netzwerkebene (Check Point) überwacht wird, ist ein gut governanctes Modul. Der Code-Standard ist die Grundlage; die Black-Hat-2026-Produkte sind die Governance-Schicht darüber.

Update — 2026-08-08: Skill/Plugin Security Scanning — anbieterseitige Supply-Chain-Minderung

Anthropic veröffentlichte Skill/Plugin Security Scanning am 6. August 2026 — die erste modellanbieterseitige Supply-Chain-Minderung für Drittanbieter-Werkzeugserver. Der Scan prüft Drittanbieter-Claude-Code-Uploads (Skills und Plugins) auf bösartige Inhalte, bevor sie den Marketplace erreichen. Dies ist die anbieterseitige Ergänzung zur Prüfung, die ein Betreiber an seinen eigenen Werkzeugdefinitionen vornimmt: Kontrolle 10 (Tool-Poisoning-Abwehr) regelt die Prüfung, die Sie durchführen; Skill/Plugin Scanning regelt, was der Modell-Anbieter auf seinem Marketplace prüft.