Company Secure Python MCP

Ein Clean-Room-Design-Minimal-MCP-Server, der ausschließlich für die Nutzung mit Copilot Studio vorgesehen ist. Der Code des früheren m365-copilot-companion-mcp wird nicht wiederverwendet. Der Auditbericht im übergeordneten Verzeichnis wird als negative Anforderung behandelt, und die Funktionen werden auf 6 Tools reduziert.

Der aktuelle Status ist „sicherheitsüberprüfbare Referenzimplementierung". Bis zum Abschluss des realen Docker-Integrationstests mit dedizierter VM oder dediziertem rootless Docker, Entra ID, TLS-Terminierung, Schlüssel-ACL, internem Registry und DLP/SIEM nicht in Produktion einsetzen.

Bereitgestellte Funktionen

E-Mail, Kalender, Zwischenablage, Registry, ODBC, Webabruf, beliebige URLs, Shell, PowerShell, Paketinstallation, Selbstaktualisierung, Autostart, Browser, Tool Forge, Tunnel und allgemeine Tool-Weiterleitung sind nicht implementiert.

Related MCP server: AI Workspace MCP Server

Vertrauensgrenze

flowchart LR
    CS[Copilot Studio] -->|OAuth 2.0 delegated token / TLS| RP[Reverse proxy / WAF]
    RP -->|loopback or private hop| MCP[6-tool MCP service]
    MCP -->|JWKS only| ENTRA[Microsoft Entra ID]
    MCP -->|scoped access| WS[Per-user workspace]
    MCP -->|immutable request| Q[Control queue]
    REVIEW[Separate reviewer account] -->|Ed25519 signed approval| Q
    Q -->|one-time claim| RUN[Dedicated/rootless Docker runner]
    RUN -->|network=none / read-only / limits| JOB[Python container]
    JOB -->|declared UTF-8 outputs only| WS
    MCP -->|HMAC chain; no content| AUDIT[Audit log -> SIEM]

Der Genehmigungsschlüssel wird nicht an den MCP-Dienst übergeben. Der MCP-Dienst besitzt nur den öffentlichen Genehmigungsschlüssel und den Prüfschlüssel. Python-Code wird nicht mit dem Host-Python ausgeführt; es gibt kein Fallback auf lokale Ausführung.

Zuerst zu lesende Dokumente

• Sicherheitsdesignbericht

• Installationsanleitung

• Bedrohungsmodell

• Sicherheitstestplan

• Richtlinie zur Behandlung von Schwachstellen

Prüfung in der Entwicklungsumgebung

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install uv
.\.venv\Scripts\uv.exe sync --frozen --extra dev
.\scripts\Invoke-SecurityChecks.ps1 -PythonExecutable .\.venv\Scripts\python.exe

In der Produktion nicht direkt von PyPI im Internet installieren, sondern den genehmigten internen Mirror und den fixierten Hash aus requirements.lock verwenden. uv.lock fixiert auch die Entwicklungs- und Testumgebung. .env wird nicht gelesen. Die Konfiguration wird von der Dienstverwaltungsplattform an die Prozessumgebung übergeben.

Vertrag für Python-Jobs

• Eingabe: /work/input/manifest.json und /work/input/<fixierter Name> (nur lesbar)

• Ausgabe: /work/output/<in python_prepare deklarierter Dateiname>

• Öffentlicher Name: Zur Kollisionsvermeidung als <request-id>-<laufende Nummer>.<Erweiterung> neu in der eigenen Ausgabe erstellen

• Ausgabeformat: UTF-8 .txt, .md, .csv, .json

• Standardausgabe und Standardfehler: Verwerfen, nicht an das Modell zurückgeben

• Netzwerk: Keins

• Ausführungszeit: Standard 60 Sekunden, maximal 300 Sekunden

• Speicher: 256 MiB, CPU: 1, PID: 64

Die Import-Erlaubnisliste für AST ist eine Verteidigung in der Tiefe und gilt nicht als Python-Sandbox. Die tatsächliche Grenze bilden die Genehmigung über einen separaten Pfad und die OS-Isolation durch die dedizierte VM bzw. das rootless Docker.

Wenn bei einem Timeout der Erfolg von docker rm -f nicht bestätigt werden kann, wird der Runner in den Quarantänezustand versetzt, alle weiteren Python-Ausführungen werden vollständig abgelehnt und das Ausführungsverzeichnis wird gesichert. Der Betrieb wird erst wieder aufgenommen, wenn der Betreiber die dedizierte VM verworfen und neu aufgebaut hat.