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

MCP-Server sollten mit begrenzten Dateisystem-Mounts, Secrets mit minimalen Rechten, expliziten Netzwerkrichtlinien, arbeitsbereichsspezifischen Grenzen pro Agent und Logs ausgeführt werden, sodass der Tool-Zugriff die Vertrauensgrenze des Agenten nicht stillschweigend erweitert. Eine Sandbox ist nützlich, wenn ein MCP-Server Dateien lesen, Subprozesse starten, Pakete installieren, interne APIs aufrufen oder Zustand für eine langlebige Agenten-Sitzung halten kann. Die Schwierigkeit liegt nicht in der Entscheidung, dass MCP Isolation benötigt, sondern darin, welche Grenze um welches Tool gehört, 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, verwandelt aber auch jeden MCP-Server in eine Policy-Grenze. Wenn ein Server read_file, run_command, query_database oder deploy_preview bereitstellt, kann der Agent nun Aktionen anfordern, die über das Kontextfenster des Modells hinausreichen.

Die MCP-Spezifikation beschreibt mehrere Sicherheitserwartungen, die für das Sandbox-Design relevant sind: Benutzer sollten die bereitgestellten Tools verstehen und ihnen zustimmen, Hosts sollten vor dem Tool-Aufruf eine Zustimmung einholen, Tool-Beschreibungen sind unvertrauenswü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 und begrenzt, worauf der MCP-Server-Prozess zugreifen 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 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, Secrets, Lebenszyklus und Logs	Der Server-Prozess erbt Host-Zugriff, weil er zu nah an Produktionsressourcen läuft

Das Ziel ist nicht, jeden MCP-Server auf die gleiche Weise als unvertrauenswürdig zu behandeln. Ein Kalender-Suchtool, ein lokales Code-Ausführungstool und ein Bereitstellungstool haben unterschiedliche Risikoprofile. Das Ziel ist, den Laufzeitzugriff jedes Servers nicht breiter zu halten als die Aufgabe, die er erfüllt.

Was zuerst isoliert werden sollte

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

Kandidaten mit hoher Priorität für die Sandbox-Isolierung sind:

• Code-Ausführungstools, die Shell-Befehle, Python, Node.js, Compiler, Tests oder Notebooks ausführen.
• Dateisystem-Tools, die ein Repository, Benutzer-Uploads, gemountete Datensätze, Credential-Dateien oder generierte Artefakte lesen oder schreiben.
• Browser- und Computer-Use-Tools, die Cookies, Sitzungszustand, heruntergeladene Dateien oder Screenshots enthalten.
• 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ängigkeitstools, die Code von Registries, Git-Remotes oder beliebigen URLs abrufen können.

Auch MCP-Server mit geringerem Risiko können Kontrollen verdienen. Ein reiner Nur-Lese-Server für die öffentliche Dokumentation benötigt möglicherweise keine MicroVM pro Anfrage, sollte aber dennoch eine Positivliste für Netzwerkpfade, 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 sollte

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

Platzierung	Verwendung	Achten Sie auf
Gleiche Sandbox wie der Agent-Workspace	Der Server ist eng mit den aktuellen Dateien, Shell-Befehlen, Browser-Sitzung oder generierten Artefakten des Agenten gekoppelt	Der Server und der Agent teilen sich den Zustand, sodass ein kompromittiertes Tool denselben Workspace sehen kann, wenn Mounts und Secrets nicht eingegrenzt sind
Separate Sandbox pro MCP-Server oder Tool-Gruppe	Das Tool benötigt eine stärkere Isolation vom Agent-Workspace, verarbeitet andere Credentials oder führt riskantere Ausführungen durch	Dateitransfer zwischen Sandboxes 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 schmal sein; setzen Sie keine breite interne Admin-Oberfläche frei, nur weil sie außerhalb der Sandbox sitzt

Die Ausführung eines Servers in derselben Sandbox ist für Codierungs-Agenten praktisch. 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 Workspace 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-Codierungs-Agent dies nicht 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 zu Tools, die eigentlich gar keine „Laufzeittools“ sind. Eine Abfrage zur Abrechnung, ein Feature-Flag-Lesen oder eine Issue-Tracker-Suche sind möglicherweise sicherer als normale Backend-APIs mit serverseitiger Autorisierung als als freiformatiger Server in der Rechenumgebung des Agenten.

Dateisystem-Mounts und arbeitsbereichsspezifische Workspaces

Der Dateisystemzugriff ist der Bereich, in dem MCP-Bequemlichkeit oft in unbeabsichtigte Privilegien 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 Workspace-Grenzen:

• Geben Sie jeder Agentenausführung ein eigenes Workspace-Verzeichnis.
• Mounten Sie nur das Repository, den Upload-Ordner, das Dataset oder das Artefakt-Verzeichnis, das für die Aufgabe benötigt wird.
• Bevorzugen Sie Nur-Lese-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 Credential-Ordnern wie .ssh, Cloud-Konfigurationsverzeichnissen, Browser-Profilen oder lokalen Paketmanager-Auth-Dateien.
• Setzen Sie den Workspace zwischen nicht verwandten Benutzern, Mandanten oder Jobs zurück oder erstellen Sie einen Snapshot.

MCP-Roots können Clients dabei 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 dennoch Grenzen auf Dateisystemebene, und der Server sollte Pfade validieren, damit Anfragen den vorgesehenen Workspace nicht mit symbolischen Links, relativen Pfaden oder Archiv-Extraktionstricks verlassen können.

Ein praktisches Muster besteht darin, den Workspace-Zugriff nach Rolle aufzuteilen:

Verzeichnis	Zugriff	Zweck
/workspace/input	Nur-Lesen	Benutzer-Uploads, Seed-Repo, Benchmark-Fixtur oder Testdaten
/workspace/output	Lese-Schreiben	Generierte Dateien, Berichte, Patches, Diagramme oder Screenshots
/workspace/tmp	Lese-Schreiben, wegwerfbar	Build-Cache, Paketinstallations-Cache, temporäre Dateien
/workspace/secrets	Datei-Mounts vermeiden, wo möglich	Falls unvermeidbar, eine eingeschränkte Secret-Datei mit strikter Lebensdauer und Schwärzung mounten

Die exakten Pfade spielen keine Rolle. Das Prinzip schon.

Secrets und Umgebungsvariablen

Secrets sind in der Regel leichter zu leaken als Dateien, da sie durch Umgebungsvariablen, Logs, Stack-Traces, Paketskripte, Shell-Verlauf, Browser-Sitzungen und Tool-Antworten wandern. Wenn ein MCP-Server ein Credential benötigt, geben Sie ihm das schmalste Credential, das die Tool-Aktion abschließen kann.

Verwenden Sie separate Credentials für separate MCP-Server. Ein GitHub-Issue-Suchserver benötigt möglicherweise Nur-Lese-Zugriff auf Issues. Ein PR-Erstellungsserver benötigt möglicherweise Schreibzugriff auf Branches. Ein Bereitstellungsserver sollte keinen der beiden Token teilen, es sei denn, das Berechtigungsmodell erfordert es wirklich.

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

• Secrets zum Start der Sandbox oder des Prozesses injizieren, nicht über Prompts.
• Kurzlebige oder widerrufbare Token verwenden, wenn der Anbieter dies unterstützt.
• Credentials nach Tool, Mandant, Umgebung und Aktion eingrenzen.
• Secrets aus stdout, stderr, strukturierten Tool-Antworten und Trace-Logs schwärzen.
• Keine rohen Umgebungsvariablen an das Modell zurückgeben.
• Den Agenten nicht entscheiden lassen, welches Secret geladen wird.
• Credentials für risikoreiche Server rotieren und nach Verdacht auf Prompt-Injection-Exposition.

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

Netzwerk-Egress und Transportoptionen

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 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 anwendbar
Welche externen Hosts kann der Server anrufen?	Reicht allein nicht aus	Positivliste, Negativliste, Proxy, DNS-Richtlinie oder kein Egress
Kann der Server Pakete oder Webseiten abrufen?	Reicht allein nicht aus	Registry-Positivlisten, URL-Positivlisten, 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 vererbten 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 sandboxierten Prozess oder führen Sie das gesamte Host-Worker-Paar innerhalb eines wegwerfbaren Workspace aus.

Für HTTP-basierte MCP-Server verlagert sich das Risiko auf Authentifizierung, Netzwerkexposition und Cross-Tenant-Trennung. Verwenden Sie serverseitige Autorisierung, TLS, gegebenenfalls Origin-Checks und Client-spezifische Credentials. Setzen Sie einen entfernten MCP-Server nicht in einem breiten internen Netzwerk ohne klare Richtlinie frei, wer welche Tools aufrufen darf.

Für den Netzwerk-Egress ist eine Standard-Verweigerung einfacher zu handhaben als eine Standard-Öffnung. 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 durch einen Proxy, der angefragte Domänen protokolliert und interne Metadaten-Endpunkte blockiert. Wenn es interne APIs benötigt, setzen Sie eine schmale API frei, anstatt das gesamte private Netzwerk.

Paketinstallationen, Subprozesse und langlebiger Zustand

Viele nützliche MCP-Tools benötigen Subprozesse. Codierungs-Agenten führen Tests aus. Datenagenten installieren Bibliotheken. Browseragenten starten Browser. Build-Agenten rufen Compiler auf. Subprozess-Unterstützung ist nicht das Problem; unsichtbare Subprozess-Unterstützung 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 festgelegt oder lockfile-basiert sein müssen.
• Wo Build-Caches und installierte Pakete leben.
• Wie lange Hintergrundprozesse laufen können.
• Welche Ausgabedateien nach der Bereinigung erhalten bleiben.
• Ob der Agent Netzwerk-Listener starten kann.

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

Verwenden Sie Lebenszyklus-Kontrollen:

Kontrolle	Warum es wichtig ist
Pro-Agent-Sandbox-IDs	Verhindert, dass der Tool-Zustand eines Agenten zum Kontext eines anderen Agenten wird
Leerlauf-Timeout	Bereinigt verlassene Tool-Sitzungen
Pause- und Fortsetzungsrichtlinie	Unterstützt lange Jobs, ohne unnötige Rechenleistung aktiv zu halten
Snapshot- oder Vorlagenrichtlinie	Startet wiederholbare Umgebungen von einem bekannten Basisstand
Explizites Herunterfahren	Entfernt Dateien, tötet Prozesse und gibt Credentials nach dem Job frei

Wenn ein Tool dauerhafte Artefakte erzeugt, kopieren Sie nur diese Artefakte aus der Sandbox. Bewahren Sie nicht den gesamten Workspace auf, es sei denn, das Produkt erfordert explizit eine vollständige Sitzungswiedergabe.

Protokollierung, Bereinigung und menschliche Überprüfung

MCP-Tool-Logs sollten Sicherheits- und Debugging-Fragen beantworten, ohne sich in einen neuen Secret-Speicher zu verwandeln. Nützliche Logs enthalten Tool-Name, Aufruferidentität, Sandbox-ID, Workspace-ID, Befehls-Kategorie, 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ändige Dateiinhalte oder vollständige Befehlsausgaben. Halten Sie sensible Spuren 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, Chats, Tickets, Rechnungen oder kundenorientierten Nachrichten.
• Ändern von Zugriffskontrollen, Abrechnung, Benutzerdaten oder Infrastrukturkonfiguration.
• Exfiltrieren großer Dateien, privater Repositories, Datenbank-Exporte oder credential-ähnlicher Zeichenfolgen.
• Ausführen von Befehlen außerhalb der Workspace-Richtlinie.
• Aufrufen interner APIs mit Schreibberechtigungen.

Die Sandbox sollte den Schadensradius verringern. Sie sollte kein Grund werden, 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. Sie kann in MCP-Architekturen eingesetzt werden, in denen ein Tool-Server einen wegwerfbaren Workspace anstelle von direktem Zugriff auf einen Entwickler-Laptop, einen Produktions-Host oder eine gemeinsam genutzte CI-Maschine benötigt.

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

• Generierten Code oder Befehle ausführen.
• Mit temporären Dateien und generierten Artefakten arbeiten.
• Den Workspace-Zustand pro Agent ü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, Credential-Bereiche, Netzwerkrichtlinie, Genehmigungsabläufe, Protokollierungsschema und das Bereinigungsverhalten. Die Sandbox bietet die isolierte Umgebung, in der diese Entscheidungen durchgesetzt werden.

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

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

Dies hält die artikelübergreifende Anleitung stabil, während die genauen SDK-Aufrufe der aktuellen 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 stellt der Server bereit und welche ändern den externen Zustand?
Platzierung	Sollte 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 Nur-Lesen oder Lese-Schreiben, und wie werden Pfad-Escapes blockiert?
Secrets	Welche Credentials werden injiziert, wie sind sie eingegrenzt, und wo können sie in Logs oder Ausgaben erscheinen?
Netzwerk	Ist Egress standardmäßig verweigert, proxy-geroutet oder positiv gelistet nach Domäne, Registry und interner API?
Subprozesse	Welche Befehle, Paketmanager, Hintergrundjobs und Listener sind erlaubt?
Zustand	Wie werden Pro-Agent-Workspaces, Snapshots, Leerlauf-Timeouts, Pause/Fortsetzungsverhalten und Bereinigung gehandhabt?
Logs	Können Sie Tool-Aufrufe, Dateiänderungen, externe Domänen und Artefakte rekonstruieren, ohne Secrets zu speichern?
Menschliche Überprüfung	Welche Tool-Aufrufe erfordern eine Genehmigung vor der Ausführung, dem Export, der Bereitstellung oder einer kundenorientierten Aktion?
Tests	Haben Sie Prompt-Injection, Symlink-/Pfad-Traversal, große Ausgabe, fehlgeschlagene Bereinigung und verweigerte Egress-Pfade getestet?

MCP macht die Tool-Integration einfacher. Sandboxing verhindert, dass diese Integration zu einer stillschweigenden Ausweitung der Modellprivilegien wird. Das richtige Design ist in der Regel eine Mischung: Einige Server im selben Agent-Workspace, einige in separaten Sandboxes und einige außerhalb der Sandbox hinter APIs mit strenger Autorisierung. Wählen Sie die Platzierung, die den Daten-, Secret-, Subprozess- 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. Risikoärmere Nur-Lese-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 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 Workspace-Pfade 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 vorgesehenen Workspace zu halten.

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

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

Wann sollte ein MCP-Tool menschliche Genehmigung erfordern?

Fordern Sie Genehmigung für Produktionsbereitstellungen, kundenorientierte Nachrichten, Änderungen an Abrechnung oder Zugriffskontrollen, große Datenexporte, Infrastrukturschreibvorgänge und jeden Befehl oder jede Netzwerkaktion außerhalb der normalen Workspace-Richtlinie.

Empfohlene Artikel

• AI-Generated Code Sandbox Requirements for Production Apps
• 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