MCP-Server in isolierten Sandboxes: Dateisystem, Secrets und Netzwerk-Kompromisse

MCP-Server sollten mit abgegrenzten Dateisystem-Mounts, minimalen Secrets, expliziten Netzwerkrichtlinien, agentenbezogenen Arbeitsbereichsgrenzen und Logs betrieben werden, sodass 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 über eine längere Agentensitzung hinweg Zustand halten kann. Die Schwierigkeit besteht nicht darin zu entscheiden, dass MCP Isolation benötigt – es geht darum, welche Grenze um welches Tool gelegt wird, welche Daten diese Grenze überschreiten und welche Aktionen weiterhin einer menschlichen Überprüfung bedürfen.

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 vereinfacht die Integration, macht aber gleichzeitig jeden MCP-Server zu einer Richtliniengrenze. Wenn ein Server read_file, run_command, query_database oder deploy_preview bereitstellt, kann der Agent nun Aktionen anfordern, die über den Modellkontext hinausgehen.

Die MCP-Spezifikation beschreibt mehrere Sicherheitserwartungen, die für das Sandbox-Design relevant sind: Benutzer sollten verstehen und der Nutzung der bereitgestellten Tools zustimmen; Hosts sollten vor dem Tool-Aufruf die Zustimmung einholen; Tool-Beschreibungen sind ohne Verifizierung nicht vertrauenswürdig; und sensible Daten sollten durch geeignete Zugriffskontrollen geschützt werden. Diese Regeln sind anwendungsseitige Kontrollen. Eine Sandbox fügt darunter liegende Laufzeitkontrollen hinzu, die einschränken, was der MCP-Server-Prozess berühren kann – 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 Fehlerquelle
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, Prozesse, Netzwerk, Secrets, Lebenszyklus und Logs	Der Serverprozess erbt Host-Zugriff, weil er zu nah an Produktionsressourcen läuft

Das Ziel ist nicht, jeden MCP-Server auf die gleiche Weise als nicht vertrauenswürdig einzustufen. Ein Kalender-Nachschlage-Tool, ein lokales Code-Ausführungstool und ein Deployment-Tool haben unterschiedliche Risikoprofile. Ziel ist es, den Laufzeitzugriff jedes Servers nicht breiter zu halten als den Job, den er ausführt.

Was zuerst isolieren

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

Zu den hochprioritären Kandidaten für eine Sandbox gehören:

• Code-Ausführungstools, die Shell-Befehle, Python, Node.js, Compiler, Tests oder Notebooks ausführen.
• Dateisystem-Tools, die ein Repository, Benutzer-Uploads, bereitgestellte Datensätze, Anmeldedaten-Dateien oder generierte Artefakte lesen oder schreiben.
• Browser- und Computer-Use-Tools, die Cookies, Sitzungszustand, heruntergeladene Dateien oder Screenshots halten.
• Datenverbinder, die Kundenaufzeichnungen, Analyse-Exporte, Tickets oder private Dokumente abfragen können.
• Deployment- und CI-Tools, die Branches erstellen, Vorschauen veröffentlichen, Konfigurationen rotieren oder Infrastruktur ändern können.
• Paket- und Abhängigkeitstools, die Code aus Registries, Git-Remotes oder beliebigen URLs abrufen können.

Auch MCP-Server mit geringerem Risiko können dennoch Kontrollen verdienen. Ein schreibgeschützter Server für die Suche in öffentlicher Dokumentation benötigt vielleicht keine Mikro-VM pro Anfrage, aber er sollte dennoch eine zugelassene Netzwerkverbindung, Logs und Ratenbegrenzungen haben. Die Isolation sollte dem praktischen Schadensradius des Tools folgen, nicht dem Label „MCP-Server".

Wo der MCP-Server ausgeführt werden soll

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

Platzierung	Verwendung	Achtung
Gleiche Sandbox wie der Agent-Arbeitsbereich	Der Server ist eng mit den aktuellen Dateien, Shell-Befehlen, Browser-Sitzungen oder generierten Artefakten des Agenten gekoppelt	Server und Agent teilen sich den Zustand, sodass ein kompromittiertes Tool denselben Arbeitsbereich sehen kann, es sei denn, Mounts und Secrets sind abgegrenzt
Separate Sandbox pro MCP-Server oder Tool-Gruppe	Das Tool benötigt eine stärkere Isolation vom Agent-Arbeitsbereich, verwendet andere Anmeldeinformationen oder führt risikoreichere Aktionen aus	Dateiübertragung zwischen Sandboxes und Latenz werden Teil des Produktdesigns
Außerhalb der Sandbox hinter einer abgestimmten API	Das Tool ist ein stabiler Produktionsdienst mit eigener Authentifizierung, Autorisierung, Protokollierung und Ratenbegrenzung	Die API muss schmal 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 zu öffentlichen Registries benötigen, während der Haupt-Coding-Agent keinen haben sollte. Ein Browser-MCP-Server benötigt möglicherweise Cookies für ein Testkonto, während ein Code-Ausführungsserver diese Cookies niemals sehen sollte.

Ein externer Dienst passt für Tools, die eigentlich gar keine „Laufzeit-Tools" sind. Eine Rechnungsabfrage, das Lesen von Feature-Flags oder die Suche im Issue-Tracker sind möglicherweise sicherer als normale Backend-API mit serverseitiger Autorisierung, als als frei formbarer Server innerhalb der Rechenumgebung des Agenten.

Dateisystem-Mounts und agentenbezogene Arbeitsbereiche

Der Dateisystemzugriff ist der Bereich, in dem MCP-Bequemlichkeit oft in unbeabsichtigte Privilegien umschlägt. Ein Server, der ./src lesen muss, sollte nicht das Heimatverzeichnis eines Entwicklers erben. Ein Tool, das generierte Diagramme schreibt, sollte nicht in der Lage sein, Deployment-Konfigurationen zu überschreiben.

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 Anmeldedaten-Ordnern 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 machen Sie einen Snapshot.

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

Ein praktisches Muster besteht darin, den Arbeitsbereich nach Rolle aufzuteilen:

Verzeichnis	Zugriff	Zweck
/workspace/input	Schreibgeschützt	Benutzer-Uploads, Start-Repository, Benchmark-Fixtur oder Testdaten
/workspace/output	Lese-/Schreibzugriff	Generierte Dateien, Berichte, Patches, Diagramme oder Screenshots
/workspace/tmp	Lese-/Schreibzugriff, wegwerfbar	Build-Cache, Paketinstallations-Cache, Zwischendateien
/workspace/secrets	Datei-Mounts vermeiden, wo möglich	Falls unvermeidbar, eine abgegrenzte Secret-Datei mit strikter Lebensdauer und Schwärzung mounten

Die genauen Pfade spielen keine Rolle. Das Prinzip schon.

Secrets und Umgebungsvariablen

Secrets sind normalerweise einfacher zu leaken als Dateien, da sie durch Umgebungsvariablen, Logs, Stack-Traces, Paketskripte, Shell-Verläufe, Browser-Sitzungen und Tool-Antworten reisen. Wenn ein MCP-Server eine Anmeldeinformation benötigt, geben Sie ihm die engste Anmeldeinformation, die die Tool-Aktion abschließen kann.

Verwenden Sie separate Anmeldeinformationen für separate MCP-Server. Ein GitHub-Issue-Suchserver benötigt möglicherweise schreibgeschützten Issue-Zugriff. Ein PR-Erstellungsserver benötigt möglicherweise Branch-Schreibzugriff. Ein Deployment-Server sollte keinen der Token teilen, es sei denn, das Berechtigungsmodell erfordert dies wirklich.

Gute Handhabung von Secrets für MCP-Server sieht so aus:

• Secrets werden beim Start der Sandbox oder des Prozesses injiziert, nicht über Prompts.
• Verwenden Sie kurzlebige oder widerrufbare Token, wenn der Anbieter dies unterstützt.
• Grenzen Sie Anmeldeinformationen nach Tool, Mandant, Umgebung und Aktion ab.
• Schwärzen Sie Secrets aus stdout, stderr, strukturierten Tool-Antworten und Trace-Logs.
• Geben Sie keine rohen Umgebungsvariablen an das Modell zurück.
• Lassen Sie den Agenten nicht entscheiden, welches Secret geladen wird.
• Rotieren Sie Anmeldeinformationen, die von Hochrisikoservern 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 Secret benötigt, sollte es keins lesen können.

Netzwerk-Egress und Transportwahl

MCP unterstützt lokale und Remote-Transportmuster. Die Spezifikation beschreibt Stdio für die lokale Prozesskommunikation und Streamable HTTP für die Server-zu-Client-Kommunikation über HTTP. Ältere SSE-basierte Designs sind 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 liefert Antwort	Netzwerkrichtlinie liefert Antwort
Wie kommuniziert der MCP-Client mit dem Server?	Stdio, HTTP-basierter Transport oder ein anderes unterstütztes Muster	Nicht anwendbar
Welche externen Hosts kann der Server anrufen?	Nicht ausreichend für sich allein	Allowlist, Denylist, Proxy, DNS-Richtlinie oder kein Egress
Kann der Server Pakete oder Webseiten abrufen?	Nicht ausreichend für sich allein	Registry-Allowlisten, URL-Allowlisten, Caching und Protokollierung
Kann ein anderer Prozess den Server erreichen?	Bindung und Authentifizierungsdetails	Eingehende Firewall und Sandbox-Netzwerkgrenze

Für lokale Stdio-Server liegt das Risiko oft im geerbten Host-Zugriff. Der Server kann als untergeordneter Prozess 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 Sandbox-Prozess oder führen Sie das gesamte Host-Worker-Paar innerhalb eines wegwerfbaren Arbeitsbereichs aus.

Für HTTP-basierte MCP-Server verlagert sich das Risiko in Richtung Authentifizierung, Netzwerk-Exposition und mandantenübergreifende Trennung. Verwenden Sie serverseitige Autorisierung, TLS, Herkunftsprüfungen wo relevant und clientspezifische Anmeldeinformationen. Setzen Sie einen Remote-MCP-Server nicht ohne klare Richtlinie, wer welche Tools aufrufen darf, in einem breiten internen Netzwerk frei.

Für Netzwerk-Egress ist es einfacher, mit Default-Deny zu argumentieren als mit 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 angefragte Domains protokolliert und interne Metadaten-Endpunkte blockiert. Wenn es interne APIs benötigt, setzen Sie eine schmale API frei, anstatt das gesamte private Netzwerk.

Paketinstallationen, Unterprozesse und langlebige Zustände

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

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

• Welche Befehle erlaubt, verboten oder genehmigungspflichtig sind.
• Ob Paketmanager das öffentliche Internet erreichen können.
• Ob Abhängigkeitsversionen festgelegt oder lockfile-basiert sein müssen.
• Wo Build-Caches und installierte Pakete abgelegt werden.
• 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 Stunden lebt, kann Dateien, Anmeldeinformationen, Browser-Cookies, Shell-Verläufe, Abhängigkeitsänderungen und Hintergrund-Jobs ansammeln. Dieser Zustand kann für mehrstufige Workflows nützlich sein, aber er muss dem richtigen Agenten, Benutzer und der richtigen Aufgabe gehören.

Verwenden Sie Lebenszyklus-Kontrollen:

Kontrolle	Warum sie wichtig ist
Agentenspezifische Sandbox-IDs	Verhindert, dass der Tool-Zustand eines Agenten zum Kontext eines anderen wird
Leerlauf-Timeout	Räumt verlassene Tool-Sitzungen auf
Pause- und Fortsetzungsrichtlinie	Unterstützt lange Jobs, ohne unnötige Rechenleistung aktiv zu halten
Snapshot- oder Vorlagenrichtlinie	Startet wiederholbare Umgebungen von einem bekannten Ausgangszustand aus
Explizites Herunterfahren	Entfernt Dateien, beendet Prozesse und gibt Anmeldeinformationen nach dem Job frei

Wenn ein Tool dauerhafte Artefakte erzeugt, 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-Logs sollten Sicherheits- und Debugging-Fragen beantworten, ohne zu einem neuen Secrets-Speicher zu werden. Nützliche Logs umfassen Tool-Name, Aufrufer-Identität, Sandbox-ID, Workspace-ID, Befehlskategorie, gelesene oder geschriebene Dateien, kontaktierte externe Domains, installierte Paketnamen, Exit-Status und Artefakt-Pfade.

Protokollieren Sie standardmäßig keine rohen Prompts, rohe Kundendaten, Token, vollständige Dateiinhalte oder vollständige Befehlausgaben. Bewahren Sie sensible Spuren hinter strengeren Zugriffskontrollen und Aufbewahrungsrichtlinien auf.

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

• Veröffentlichen oder Bereitstellen in der Produktion.
• Senden von E-Mails, Chats, Tickets, Rechnungen oder kundenorientierten Nachrichten.
• Ändern von Zugriffskontrollen, Abrechnung, Benutzerdaten oder Infrastrukturkonfiguration.
• Exfiltrieren großer Dateien, privater Repositories, Datenbank-Exporte oder anmeldeinformationsähnlicher Zeichenfolgen.
• Ausführen von Befehlen außerhalb der Workspace-Richtlinie.
• Aufrufen interner APIs mit Schreibberechtigungen.

Die Sandbox sollte den Schadensradius verkleinern. Sie sollte kein Grund sein, die Überprüfung sensibler Geschäftsaktionen zu entfernen.

Wie Novita Agent Sandbox passt

Novita Agent Sandbox wurde für Agenten-Workloads entwickelt, die eine isolierte Laufzeit für Code-Ausführung, Dateien, Prozesse, browserähnliche Workflows und langlebige Sitzungen benötigen. Es kann in MCP-Architekturen eingesetzt werden, bei denen ein Tool-Server einen wegwerfbaren Arbeitsbereich anstelle des direkten Zugriffs auf einen Entwickler-Laptop, Produktions-Host oder eine gemeinsame 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.
• Agentenspezifischen Arbeitsbereichszustand über mehrstufige Aufgaben hinweg beibehalten.
• Hintergrundarbeit ausführen, die der Agent später überprüfen kann.
• Trennung von Agenten-Experimenten vom Anwendungs-Host.

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

Für produktionsspezifische Einrichtung verwenden Sie die aktuelle Novita-Dokumentation anstatt veralteter 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 toolspezifische Secrets injizieren
  MCP-Server in der Sandbox starten oder mit einer sandboxgestützten Tool-API verbinden
  Tool-Aufrufe durch Genehmigungs- und Richtlinienprüfungen leiten
  Logs und genehmigte Artefakte sammeln
  Sandbox je nach Aufgabenlebenszyklus stoppen, zurücksetzen oder pausieren

Dies hält die leitfadenbezogenen Anweisungen stabil und überlässt die genauen SDK-Aufrufe der aktuellen Dokumentation und Ihrem Plattformcode.

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 Agenten-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-/Schreibzugriff, und wie werden Pfadumgehungen blockiert?
Secrets	Welche Anmeldeinformationen werden injiziert, wie sind sie abgegrenzt, und wo können sie in Logs oder Ausgaben erscheinen?
Netzwerk	Ist Egress standardmäßig blockiert, über einen Proxy geleitet oder nach Domain, Registry und interner API zugelassen?
Unterprozesse	Welche Befehle, Paketmanager, Hintergrundjobs und Listener sind erlaubt?
Zustand	Wie werden agentenspezifische Arbeitsbereiche, Snapshots, Leerlauf-Timeout, Pause/Fortsetzen-Verhalten und Bereinigung behandelt?
Logs	Können Sie Tool-Aufrufe, Dateiänderungen, externe Domains und Artefakte rekonstruieren, ohne Secrets zu speichern?
Menschliche Überprüfung	Welche Tool-Aufrufe erfordern eine Genehmigung vor der Ausführung, dem Export, dem Deployment oder der kundenorientierten Aktion?
Tests	Haben Sie Prompt-Injection, Symlink-/Pfad-Traversal, große Ausgaben, fehlgeschlagene Bereinigung und blockierte Egress-Pfade getestet?

MCP macht die Werkzeugintegration einfacher. Sandboxing verhindert, dass diese Integration zu einer stillschweigenden Erweiterung der Modellprivilegien wird. Das richtige Design ist normalerweise eine Mischung: Einige Server im selben Agentenarbeitsbereich, einige in separaten Sandboxes und einige außerhalb der Sandbox hinter APIs mit strenger Autorisierung. Wählen Sie die Platzierung, die den Daten-, Secrets-, 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, Secrets verwenden, private Dienste aufrufen, Browser starten, Pakete installieren oder den externen Zustand ändern. Schreibgeschützte Server mit geringerem Risiko benötigen möglicherweise dennoch Authentifizierung, Protokollierung und Netzwerkkontrollen, aber nicht unbedingt eine dedizierte Sandbox pro Anfrage.

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

Nicht automatisch. Stdio kann einfach für lokale Server sein, aber der Server kann lokale Dateisystem-, Umgebungs- und Netzwerkzugriffe erben. 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-Roots die Dateisystem-Sandboxierung ersetzen?

Nein. Roots helfen dabei, beabsichtigte Arbeitsbereichs-Pfade zwischen Client und Server zu kommunizieren, aber sie sind keine vollständige Laufzeitgrenze. Verwenden Sie Pfadvalidierung und Dateisystemkontrollen auf Sandbox-Ebene, um den Server im beabsichtigten Arbeitsbereich zu halten.

Wo sollten Secrets für sandboxierte MCP-Tools gespeichert werden?

Injizieren Sie nur die Anmeldeinformationen, die das Tool benötigt, idealerweise als kurzlebige Umgebungsvariablen oder abgegrenzte Laufzeit-Secrets. Mounten Sie keine breiten Entwickler-Anmeldeordner und geben Sie keine Secrets über Prompts weiter. Schwärzen Sie sie aus Logs und Tool-Antworten.

Wann sollte ein MCP-Tool eine menschliche Genehmigung erfordern?

Fordern Sie Genehmigung an für Produktions-Deployments, kundenorientierte Nachrichten, Änderungen an Abrechnung oder Zugriffskontrolle, große Datenexporte, Infrastruktur-Schreibvorgänge und jeden Befehl oder jede Netzwerkaktion außerhalb der normalen Arbeitsbereichsrichtlinie.

Empfohlene Artikel

• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation