MCP-Server-Sandbox: Isolierte MCP-Server mit Dateisystem-, Geheimnis- und Netzwerkkontrollen

MCP-Server sollten mit eingeschränkten Dateisystem-Mounts, Geheimnissen mit minimalen Rechten, expliziten Netzwerkrichtlinien, pro Agent festgelegten Arbeitsbereichsgrenzen und Protokollen ausgeführt werden, damit der Tool-Zugriff die Vertrauensgrenze des Agenten nicht stillschweigend erweitert. Eine Sandbox ist sinnvoll, wenn ein MCP-Server Dateien lesen, Unterprozesse starten, Pakete installieren, interne APIs aufrufen oder den Zustand für eine langlebige Agentensitzung halten kann. Die Schwierigkeit liegt nicht darin zu entscheiden, dass MCP eine Isolation benötigt, sondern darin, welche Grenze um welches Tool gelegt wird, welche Daten diese Grenze überschreiten und welche Aktionen dennoch eine menschliche Überprüfung erfordern.

Warum MCP die Vertrauensgrenze des Agenten verändert

Das Model Context Protocol bietet KI-Anwendungen eine gemeinsame Möglichkeit, Modelle mit Tools, Prompts und Ressourcen zu verbinden. Das macht die Integration sauberer, aber es verwandelt auch jeden MCP-Server in eine Richtliniengrenze. Wenn ein Server read_file, run_command, query_database oder deploy_preview bereitstellt, kann der Agent nun Aktionen anfordern, die über das Modellkontextfenster hinausreichen.

Wenn Sie diese Tools mit einem breiteren Workflow verbinden, beginnen Sie mit Wie man Aufgaben mit KI automatisiert und entscheiden Sie dann, ob die äußere Schleife einen Coding-Agenten oder einen leichteren Interpreter benötigt.

Die MCP-Spezifikation beschreibt mehrere Sicherheitserwartungen, die für das Sandbox-Design wichtig sind: Benutzer sollten die bereitgestellten Tools verstehen und ihnen zustimmen, Hosts sollten vor dem Tool-Aufruf die Zustimmung einholen, Tool-Beschreibungen sind nicht vertrauenswürdig, sofern sie nicht verifiziert wurden, und sensible Daten sollten durch geeignete Zugriffskontrollen geschützt werden. Diese Regeln sind Kontrollen auf Anwendungsebene. Eine Sandbox fügt darunter liegende Laufzeitkontrollen hinzu, die den Zugriff des MCP-Server-Prozesses einschränken, selbst wenn der Agent, die Tool-Beschreibung oder die Prompt-Kette eine fehlerhafte Anfrage stellt.

Betrachten Sie die Vertrauensgrenze in drei Schichten:

Schicht	Was sie kontrolliert	Häufige Fehlerart
Host oder MCP-Client	Welche Server verbunden sind und welche Tool-Aufrufe genehmigt werden	Ein breites Tool wird einmal genehmigt und in einem sensibleren Kontext wiederverwendet
MCP-Server	Tool-Implementierung, Authentifizierung, Eingabevalidierung, Ressourcenzugriff	Ein Tool liest mehr Dateien, sendet mehr Daten oder führt mehr Befehle aus als erwartet
Sandbox-Laufzeit	Dateisystem, Prozess, Netzwerk, Geheimnisse, Lebenszyklus und Protokolle	Der Server-Prozess erbt Host-Zugriff, weil er zu nahe an Produktionsressourcen läuft

Das Ziel ist nicht, jeden MCP-Server auf die gleiche Weise als nicht vertrauenswürdig einzustufen. Ein Kalender-Such-Tool, ein lokales Code-Ausführungs-Tool und ein Bereitstellungs-Tool haben unterschiedliche Risikoprofile. Das Ziel ist, den Laufzeitzugriff jedes Servers nicht breiter zu halten als die Aufgabe, die er erfüllt.

Was zuerst isolieren

Beginnen Sie mit den MCP-Servern, die den externen Zustand ändern, sensible Daten berühren oder Code ausführen können. Dies sind die Server, die am wahrscheinlichsten einen normalen Prompt-Fehler in einen größeren Vorfall verwandeln.

Kandidaten mit hoher Priorität für die Sandboxing sind:

• Code-Ausführungs-Tools, die Shell-Befehle, Python, Node.js, Compiler, Tests oder Notebooks ausführen.
• Dateisystem-Tools, die ein Repository, Benutzer-Uploads, gemountete Datensets, Berechtigungsdateien oder generierte Artefakte lesen oder schreiben.
• Browser- und Computer-Use-Tools, die Cookies, Sitzungszustände, heruntergeladene Dateien oder Screenshots halten.
• Datenkonnektoren, die Kundendatensätze, Analyse-Exporte, Tickets oder private Dokumente abfragen können.
• Bereitstellungs- und CI-Tools, die Branches erstellen, Vorschauen veröffentlichen, Konfigurationen rotieren oder Infrastruktur ändern können.
• Paket- und Abhängigkeits-Tools, die Code aus Registries, Git-Remotes oder beliebigen URLs abrufen können.

MCP-Server mit geringerem Risiko können dennoch Kontrollen verdienen. Ein schreibgeschützter Server für die Suche in öffentlicher Dokumentation benötigt möglicherweise keine MicroVM pro Anfrage, sollte aber dennoch eine Whitelist für Netzwerkpfade, Protokolle und Ratenbegrenzungen haben. Die Isolation sollte dem praktischen Explosionsradius des Tools folgen, nicht dem Label “MCP-Server”.

Wo der MCP-Server laufen sollte

Es gibt drei gängige Platzierungsmuster. Keines ist universell richtig.

Platzierung	Verwenden, wenn	Achten auf
Gleiche Sandbox wie der Agent-Arbeitsbereich	Der Server ist eng an die aktuellen Dateien, Shell-Befehle, Browser-Sitzung oder generierten Artefakte des Agenten gekoppelt	Server und Agent teilen sich den Zustand, sodass ein kompromittiertes Tool denselben Arbeitsbereich sehen kann, es sei denn, Mounts und Geheimnisse sind eingeschränkt
Separate Sandbox pro MCP-Server oder Tool-Gruppe	Das Tool benötigt eine stärkere Isolation vom Agent-Arbeitsbereich, behandelt andere Anmeldedaten oder führt risikoreichere Ausführungen durch	Dateiübertragung zwischen Sandboxen und Latenz werden Teil des Produktdesigns
Außerhalb der Sandbox hinter einer eingeschränkten API	Das Tool ist ein stabiler Produktionsdienst mit eigener Authentifizierung, Autorisierung, Protokollierung und Ratenbegrenzung	Die API muss eng sein; setzen Sie keine breite interne Admin-Oberfläche frei, nur weil sie außerhalb der Sandbox liegt

Das Ausführen eines Servers in derselben Sandbox ist praktisch für Coding-Agenten. Der MCP-Server kann das Repository sehen, Tests ausführen, Artefakte inspizieren und Ergebnisse zurückgeben, ohne Dateien zwischen Umgebungen zu verschieben. Dies funktioniert am besten, wenn der Arbeitsbereich selbst bereits wegwerfbar ist und nur die Dateien enthält, die der Agent verwenden soll.

Eine separate Sandbox ist besser, wenn das Tool eine andere Richtlinie verdient. Beispielsweise könnte ein Paketanalyse-MCP-Server Internetzugriff auf öffentliche Registries benötigen, während der Haupt-Coding-Agent dies nicht sollte. Ein Browser-MCP-Server benötigt möglicherweise Cookies für ein Testkonto, während ein Code-Ausführungs-Server diese Cookies niemals sehen sollte.

Ein externer Dienst passt zu Tools, die eigentlich gar keine “Laufzeit-Tools” sind. Ein Abrechnungs-Lookup, Feature-Flag-Read oder Issue-Tracker-Search können als normale Backend-API mit serverseitiger Autorisierung sicherer sein als als formloser Server in der Rechenumgebung des Agenten.

Dateisystem-Mounts und pro Agent festgelegte Arbeitsbereiche

Der Dateisystemzugriff ist der Bereich, in dem MCP-BeQemlichkeit oft in unbeabsichtigte Berechtigungen umschlägt. Ein Server, der ./src lesen muss, sollte nicht das Home-Verzeichnis eines Entwicklers erben. Ein Tool, das generierte Diagramme schreibt, sollte keine Bereitstellungskonfiguration überschreiben können.

Verwenden Sie explizite Arbeitsbereichsgrenzen:

• Geben Sie jedem Agentenlauf ein eigenes Arbeitsbereichsverzeichnis.
• Mounten Sie nur das Repository, den Upload-Ordner, das Dataset oder das Artefaktverzeichnis, das für die Aufgabe benötigt wird.
• Bevorzugen Sie schreibgeschützte Mounts für Quellmaterial und Lese-/Schreib-Mounts nur für Ausgaben.
• Trennen Sie generierte Ausgaben von vertrauenswürdigen Quelldateien.
• Vermeiden Sie das Mounten von Berechtigungsordnern wie .ssh, Cloud-Konfigurationsverzeichnissen, Browser-Profilen oder lokalen Paketmanager-Auth-Dateien.
• Setzen Sie den Arbeitsbereich zwischen nicht verwandten Benutzern, Mandanten oder Jobs zurück oder erstellen Sie einen Snapshot.

MCP-Wurzeln können Clients helfen, die Dateisystempositionen zu kommunizieren, auf die ein Server zugreifen soll, aber Wurzeln sind für sich genommen keine vollständige Sicherheitsgrenze. Behandeln Sie sie als Koordinationsmechanismus zwischen Client und Server. Die Laufzeit benötigt dennoch Grenzen auf Dateisystemebene, und der Server sollte Pfade validieren, damit Anfragen den beabsichtigten Arbeitsbereich nicht mit Symlinks, relativen Pfaden oder Archiv-Extraktionstricks verlassen können.

Ein praktisches Muster ist, den Arbeitsbereichszugriff nach Rolle aufzuteilen:

Verzeichnis	Zugriff	Zweck
/workspace/input	Schreibgeschützt	Benutzer-Uploads, Seed-Repo, Benchmark-Fixture oder Testdaten
/workspace/output	Lese-/Schreibzugriff	Generierte Dateien, Berichte, Patches, Diagramme oder Screenshots
/workspace/tmp	Lese-/Schreibzugriff, wegwerfbar	Build-Cache, Paket-Installations-Cache, temporäre Dateien
/workspace/secrets	Datei-Mounts vermeiden, wo möglich	Wenn unvermeidbar, eine eingeschränkte Secret-Datei mit strenger Lebensdauer und Schwärzung mounten

Die genauen Pfade spielen keine Rolle. Das Prinzip schon.

Geheimnisse und Umgebungsvariablen

Geheimnisse sind in der Regel einfacher preiszugeben als Dateien, da sie über Umgebungsvariablen, Protokolle, Stack-Traces, Paketskripte, Shell-Verlauf, Browser-Sitzungen und Tool-Antworten wandern. Wenn ein MCP-Server eine Berechtigung benötigt, geben Sie ihm die schmalste Berechtigung, die die Tool-Aktion abschließen kann.

Verwenden Sie separate Anmeldedaten für separate MCP-Server. Ein GitHub-Issue-Search-Server benötigt möglicherweise schreibgeschützten Issue-Zugriff. Ein PR-Authoring-Server benötigt möglicherweise Branch-Schreibzugriff. Ein Bereitstellungsserver sollte keinen der beiden Token teilen, es sei denn, das Berechtigungsmodell erfordert es wirklich.

Eine gute Geheimnisbehandlung für MCP-Server sieht so aus:

• Injizieren Sie Geheimnisse beim Start der Sandbox oder des Prozesses, nicht über Prompts.
• Verwenden Sie kurzlebige oder widerrufbare Token, wenn der Anbieter dies unterstützt.
• Beschränken Sie Anmeldedaten nach Tool, Mandant, Umgebung und Aktion.
• Schwärzen Sie Geheimnisse aus stdout, stderr, strukturierten Tool-Antworten und Ablaufverfolgungsprotokollen.
• Geben Sie keine rohen Umgebungsvariablen an das Modell zurück.
• Lassen Sie den Agenten nicht entscheiden, welches Geheimnis geladen werden soll.
• Rotieren Sie Anmeldedaten, die von Hochrisiko-Servern verwendet werden, und nach Verdacht auf Prompt-Injection-Exposition.

Vermeiden Sie ein häufiges Anti-Pattern: Eine Allzweck-Umgebungsdatei, die in jede Agentensitzung eingebunden wird. Das macht die lokale Entwicklung einfacher und die Produktionsüberprüfung schwieriger. Wenn ein Tool kein Geheimnis benötigt, sollte es keins lesen können.

Netzwerk-Egress und Transportwahl

MCP unterstützt lokale und entfernte Transportmuster. Die Spezifikation beschreibt stdio für die lokale Prozesskommunikation und Streamable HTTP für die Server-Client-Kommunikation über HTTP. Ältere SSE-basierte Designs sind immer noch im Ökosystem vorhanden, aber neue Integrationen sollten die aktuelle MCP-Dokumentation und das gewählte SDK überprüfen, bevor sie sich auf einen bestimmten Transport verlassen.

Transportwahl und Sandbox-Netzwerkrichtlinie lösen unterschiedliche Probleme:

Frage	Transport beantwortet	Netzwerkrichtlinie beantwortet
Wie kommuniziert der MCP-Client mit dem Server?	stdio, HTTP-basierter Transport oder ein anderes unterstütztes Muster	Nicht zutreffend
Welche externen Hosts kann der Server anrufen?	Nicht genug für sich allein	Whitelist, Blacklist, Proxy, DNS-Richtlinie oder kein Egress
Kann der Server Pakete oder Webseiten abrufen?	Nicht genug für sich allein	Registry-Whitelists, URL-Whitelists, Caching und Protokollierung
Kann ein anderer Prozess den Server erreichen?	Bindung und Authentifizierungsdetails	Eingehende Firewall und Sandbox-Netzwerkgrenze

Bei lokalen stdio-Servern ist das Risiko oft der geerbte Host-Zugriff. Der Server kann als Kindprozess der Host-Anwendung laufen und lokale Dateien, Umgebungsvariablen und Netzwerk-Routen sehen. Wenn dieser Server Code ausführt oder sensible Dateien liest, verschieben Sie ihn in einen gesandboxten Prozess oder führen Sie das gesamte Host-Worker-Paar in einem wegwerfbaren Arbeitsbereich aus.

Bei HTTP-basierten MCP-Servern verschiebt sich das Risiko hin zu Authentifizierung, Netzwerkexposition und Mandantentrennung. Verwenden Sie serverseitige Autorisierung, TLS, gegebenenfalls Origin-Checks und client-spezifische Anmeldedaten. Setzen Sie einen entfernten MCP-Server nicht in einem breiten internen Netzwerk ohne klare Richtlinie aus, wer welche Tools aufrufen darf.

Für Netzwerk-Egress ist “Default-Deny” einfacher zu handhaben als “Default-Open”. Wenn ein Tool Paketinstallationen benötigt, erlauben Sie die Paket-Registry oder einen Pull-Through-Cache. Wenn es Web-Recherche benötigt, leiten Sie es über einen Proxy, der die angeforderten Domänen protokolliert und interne Metadaten-Endpunkte blockiert. Wenn es interne APIs benötigt, setzen Sie eine schmale API anstelle des gesamten privaten Netzwerks frei.

Paketinstallationen, Unterprozesse und langlebige Zustände

Viele nützliche MCP-Tools benötigen Unterprozesse. Coding-Agenten führen Tests aus. Daten-Agenten installieren Bibliotheken. Browser-Agenten starten Browser. Build-Agenten rufen Compiler auf. Die Unterstützung von Unterprozessen ist nicht das Problem; die unsichtbare Unterstützung von Unterprozessen schon.

Bevor Sie Paketinstallationen oder Shell-Ausführungen zulassen, definieren Sie:

• Welche Befehle erlaubt, verboten oder genehmigungspflichtig sind.
• Ob Paketmanager das öffentliche Internet erreichen können.
• Ob Abhängigkeitsversionen festgepinnt oder lockfile-basiert sein müssen.
• Wo Build-Caches und installierte Pakete leben.
• Wie lange Hintergrundprozesse laufen können.
• Welche Ausgabedateien nach der Bereinigung aufbewahrt werden.
• Ob der Agent Netzwerk-Listener starten kann.

Langlebige MCP-Server führen ein zweites Problem ein: Zustandsdrift. Ein Server, der stundenlang lebt, kann Dateien, Anmeldedaten, Browser-Cookies, Shell-Verlauf, Abhängigkeitsänderungen und Hintergrundjobs ansammeln. Dieser Zustand kann für mehrstufige Workflows nützlich sein, muss aber dem richtigen Agenten, Benutzer und der richtigen Aufgabe gehören.

Verwenden Sie Lebenszykluskontrollen:

Kontrolle	Warum es wichtig ist
Pro-Agent-Sandbox-IDs	Verhindert, dass der Tool-Zustand eines Agenten zum Kontext eines anderen wird
Leerlauf-Timeout	Räumt verlassene Tool-Sitzungen auf
Pause- und Resume-Richtlinie	Unterstützt lange Jobs, ohne unnötige Rechenleistung aktiv zu halten
Snapshot- oder Template-Richtlinie	Startet wiederholbare Umgebungen von einer bekannten Baseline
Explizite Bereinigung	Entfernt Dateien, beendet Prozesse und gibt Anmeldedaten nach dem Job frei

Wenn ein Tool dauerhafte Artefakte produziert, kopieren Sie nur diese Artefakte aus der Sandbox. Bewahren Sie nicht den gesamten Arbeitsbereich auf, es sei denn, das Produkt benötigt explizit eine vollständige Sitzungswiedergabe.

Protokollierung, Bereinigung und menschliche Überprüfung

MCP-Tool-Protokolle sollten Sicherheits- und Debugging-Fragen beantworten, ohne sich in einen neuen Geheimnisspeicher zu verwandeln. Nützliche Protokolle umfassen Tool-Name, Aufruferidentität, Sandbox-ID, Arbeitsbereichs-ID, Befehlskategorie, gelesene oder geschriebene Dateien, kontaktierte externe Domänen, installierte Paketnamen, Exit-Status und Artefaktpfade.

Protokollieren Sie standardmäßig keine rohen Prompts, rohen Kundendaten, Token, vollständigen Dateiinhalte oder vollständige Befehlsausgaben. Halten Sie sensible Ablaufverfolgungen hinter strengeren Zugriffskontrollen und Aufbewahrungsrichtlinien.

Einige MCP-Aktionen sollten auch innerhalb einer Sandbox menschlich überprüft bleiben:

• Veröffentlichen oder Bereitstellen in der Produktion.
• Senden von E-Mails, Chat-Nachrichten, Tickets, Rechnungen oder kundenorientierten Nachrichten.
• Ändern von Zugriffskontrollen, Abrechnung, Benutzerdaten oder Infrastrukturkonfiguration.
• Exfiltrieren von großen Dateien, privaten Repositories, Datenbankexporten oder berechtigungsähnlichen Zeichenfolgen.
• Ausführen von Befehlen außerhalb der Arbeitsbereichsrichtlinie.
• Aufrufen von internen APIs mit Schreibberechtigungen.

Die Sandbox sollte den Explosionsradius verringern. Sie sollte kein Grund werden, die Überprüfung von sensiblen Geschäftsaktionen zu entfernen.

Wie Novita Agent Sandbox passt

Novita Agent Sandbox ist für Agent-Workloads konzipiert, die eine isolierte Laufzeit für Code-Ausführung, Dateien, Prozesse, browserähnliche Workflows und langlebige Sitzungen benötigen. Es kann in MCP-Architekturen passen, bei denen ein Tool-Server einen wegwerfbaren Arbeitsbereich anstelle des direkten Zugriffs auf einen Entwickler-Laptop, einen Produktions-Host oder eine gemeinsam genutzte CI-Maschine benötigt.

Verwenden Sie es als Laufzeitgrenze für Server, die Folgendes benötigen:

• Generierten Code oder Befehle ausführen.
• Mit temporären Dateien und generierten Artefakten arbeiten.
• Pro-Agent-Arbeitsbereichszustand über mehrstufige Aufgaben hinweg halten.
• Hintergrundarbeit ausführen, die der Agent später überprüfen kann.
• Agenten-Experimente vom Anwendungs-Host trennen.

Halten Sie die Produktgrenze klar: Ein MCP-Server ist immer noch Ihr Anwendungscode. Sie entwerfen weiterhin die Tool-Berechtigungen, Anmeldeinformationsbereiche, Netzwerkrichtlinien, Genehmigungsabläufe, Protokollschemata und das Bereinigungsverhalten. Die Sandbox stellt die isolierte Umgebung bereit, in der diese Entscheidungen durchgesetzt werden.

Für die produktspezifische Einrichtung verwenden Sie die aktuelle Novita-Dokumentation, anstatt veraltete Snippets aus älteren Tutorials zu kopieren. Konzeptionell sieht die Form so aus:

für jede Agentenaufgabe:
  Sandbox aus genehmigter Vorlage erstellen
  nur den Aufgabenarbeitsbereich mounten
  nur tool-spezifische Geheimnisse injizieren
  MCP-Server innerhalb der Sandbox starten oder mit einer sandboxgestützten Tool-API verbinden
  Tool-Aufrufe durch Genehmigungs- und Richtlinienprüfungen leiten
  Protokolle und genehmigte Artefakte sammeln
  Sandbox gemäß dem Aufgabenlebenszyklus stoppen, zurücksetzen oder pausieren

Dies hält die artikelübergreifende Anleitung stabil, während die genauen SDK-Aufrufe der neuesten Dokumentation und Ihrem Plattformcode überlassen bleiben.

Implementierungs-Checkliste

Verwenden Sie diese Checkliste, bevor Sie einen MCP-Server mit einem autonomen oder semi-autonomen Agenten verbinden:

Bereich	Zu beantwortende Fragen
Tool-Umfang	Welche Tools setzt der Server frei und welche ändern den externen Zustand?
Platzierung	Soll der Server in der Agent-Sandbox, einer separaten Sandbox oder außerhalb der Sandbox hinter einer schmalen API laufen?
Dateisystem	Welche Verzeichnisse werden gemountet, sind sie schreibgeschützt oder lese-/schreibbar und wie werden Pfadausbrüche blockiert?
Geheimnisse	Welche Anmeldedaten werden injiziert, wie sind sie eingeschränkt und wo können sie in Protokollen oder Ausgaben erscheinen?
Netzwerk	Ist Egress standardmäßig verboten, proxy-gesteuert oder per Whitelist für Domäne, Registry und interne API?
Unterprozesse	Welche Befehle, Paketmanager, Hintergrundjobs und Listener sind erlaubt?
Zustand	Wie werden pro Agent Arbeitsbereiche, Snapshots, Leerlauf-Timeouts, Pause-/Resume-Verhalten und Bereinigung gehandhabt?
Protokolle	Können Sie Tool-Aufrufe, Dateiänderungen, externe Domänen und Artefakte rekonstruieren, ohne Geheimnisse zu speichern?
Menschliche Überprüfung	Welche Tool-Aufrufe erfordern eine Genehmigung vor der Ausführung, dem Export, der Bereitstellung oder einer kundenorientierten Aktion?
Testen	Haben Sie Prompt-Injection, Symlink-/Pfad-Traversal, große Ausgaben, fehlgeschlagene Bereinigung und verweigerte Egress-Pfade getestet?

MCP macht die Tool-Integration einfacher. Sandboxing verhindert, dass diese Integration zu einer stillschweigenden Ausweitung der Modellberechtigungen wird. Das richtige Design ist normalerweise eine Mischung: einige Server im selben Agent-Arbeitsbereich, einige in separaten Sandboxen und einige außerhalb der Sandbox hinter APIs mit strenger Autorisierung. Wählen Sie die Platzierung, die den Daten-, Geheimnis-, Unterprozess- und Netzwerkanforderungen des Tools entspricht.

FAQ

Sollte jeder MCP-Server in einer Sandbox laufen?

Nein. Priorisieren Sie Server, die Code ausführen, Dateien lesen oder schreiben, Geheimnisse verwenden, private Dienste aufrufen, Browser starten, Pakete installieren oder den externen Zustand ändern. Weniger riskante, schreibgeschützte Server benötigen möglicherweise dennoch Authentifizierung, Protokollierung und Netzwerkkontrollen, aber möglicherweise keine dedizierte Sandbox pro Anfrage.

Ist stdio sicherer als HTTP für MCP-Server?

Nicht automatisch. Stdio kann für lokale Server einfach sein, aber der Server erbt möglicherweise lokalen Dateisystem-, Umgebungs- und Netzwerkzugriff. HTTP-basierte Server benötigen stärkere Authentifizierungs- und Expositionskontrollen. Die sicherere Wahl hängt davon ab, wo der Prozess läuft und welche Laufzeitberechtigungen er erhält.

Können MCP-Wurzeln die Dateisystem-Sandboxing ersetzen?

Nein. Wurzeln helfen, die beabsichtigten Arbeitsbereichsorte zwischen Client und Server zu kommunizieren, sind aber keine vollständige Laufzeitgrenze. Verwenden Sie Pfadvalidierung und Dateisystemkontrollen auf Sandbox-Ebene, um den Server innerhalb des beabsichtigten Arbeitsbereichs zu halten.

Wo sollten Geheimnisse für gesandboxte MCP-Tools gespeichert werden?

Injizieren Sie nur die Anmeldedaten, die das Tool benötigt, idealerweise als kurzlebige Umgebungsvariablen oder eingeschränkte Laufzeitgeheimnisse. Mounten Sie keine breiten Entwickler-Anmeldeinformationsordner und übergeben Sie keine Geheimnisse über Prompts. Schwärzen Sie sie aus Protokollen und Tool-Antworten.

Wann sollte ein MCP-Tool eine menschliche Genehmigung erfordern?

Erfordern Sie eine Genehmigung für Produktionsbereitstellungen, kundenorientierte Nachrichten, Abrechnungs- oder Zugriffskontrolländerungen, große Datenexporte, Infrastrukturschreibvorgänge und jeden Befehls- oder Netzwerkvorgang außerhalb der normalen Arbeitsbereichsrichtlinie.

Empfohlene Artikel

• KI-generierte Code-Sandbox-Anforderungen für Produktions-Apps
• Claude MCP: So konfigurieren Sie MCP-Server in Claude Code und Claude Desktop
• Erstellen eines Coding-Agenten mit Novitas Agent Sandbox