> ## Documentation Index > Fetch the complete documentation index at: https://cli.fuxicode.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Serververwaltete Einstellungen konfigurieren > Konfigurieren Sie Fuxi Code zentral für Ihre Organisation durch serververwaltete Einstellungen, ohne dass eine Geräteverwaltungsinfrastruktur erforderlich ist. Serververwaltete Einstellungen ermöglichen es Administratoren, Fuxi Code zentral über [**Admin-Einstellungen > Fuxi Code > Verwaltete Einstellungen**](https://fuxi.ai/admin-settings/fuxi-code) in der fuxi.ai-Konsole zu konfigurieren. Fuxi Code-Clients rufen diese Einstellungen automatisch ab, wenn sich Benutzer mit einer Organisations-OAuth-Anmeldung oder einem direkt konfigurierten API-Schlüssel authentifizieren, auf Plattformen, auf denen die serververwaltete Bereitstellung unterstützt wird. Siehe [Plattformverfügbarkeit](#platform-availability). Dieser Ansatz ist für Organisationen konzipiert, die keine Geräteverwaltungsinfrastruktur haben oder Einstellungen für Benutzer auf nicht verwalteten Geräten verwalten müssen. Serververwaltete Einstellungen sind für [Fuxi for Teams](https://fuxi.com/pricing?utm_source=fuxi_code\&utm_medium=docs\&utm_content=server_settings_teams#team-&-enterprise) und [Fuxi for Enterprise](https://anthropic.com/contact-sales?utm_source=fuxi_code\&utm_medium=docs\&utm_content=server_settings_enterprise) Kunden verfügbar.

Anforderungen

Um serververwaltete Einstellungen zu verwenden, benötigen Sie: * Fuxi for Teams oder Fuxi for Enterprise Plan * Die Rolle „Owner" oder „Primary Owner" in Ihrer Fuxi-Organisation, um die Konfiguration anzuzeigen und zu bearbeiten * Netzwerkzugriff auf `api.anthropic.com`

Wählen Sie zwischen serververwalteten und endpunktverwalteten Einstellungen

Fuxi Code unterstützt zwei Ansätze für zentralisierte Konfiguration. Serververwaltete Einstellungen liefern Konfiguration von Anthropics Servern. [Endpunktverwaltete Einstellungen](/de/settings#settings-files) werden direkt auf Geräten über native Betriebssystemrichtlinien (macOS verwaltete Einstellungen, Windows-Registrierung) oder verwaltete Einstellungsdateien bereitgestellt. | Ansatz | Am besten geeignet für | Sicherheitsmodell | | :------------------------------------------------------------------ | :------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------- | | **Serververwaltete Einstellungen** | Organisationen ohne MDM oder Benutzer auf nicht verwalteten Geräten | Einstellungen, die von Anthropics Servern zum Authentifizierungszeitpunkt bereitgestellt werden | | **[Endpunktverwaltete Einstellungen](/de/settings#settings-files)** | Organisationen mit MDM oder Endpunktverwaltung | Einstellungen, die auf Geräten über MDM-Konfigurationsprofile, Registrierungsrichtlinien oder verwaltete Einstellungsdateien bereitgestellt werden | Wenn Ihre Geräte in einer MDM- oder Endpunktverwaltungslösung registriert sind, bieten endpunktverwaltete Einstellungen stärkere Sicherheitsgarantien, da die Einstellungsdatei auf Betriebssystemebene vor Benutzermodifikationen geschützt werden kann. Endpunktverwaltete Einstellungen erreichen [Cloud-Sitzungen](/de/model-config#surface-coverage) nicht, daher sollten Organisationen, die Fuxi Code im Web verwenden, auch serververwaltete Einstellungen konfigurieren.

Serververwaltete Einstellungen konfigurieren

Navigieren Sie in der fuxi.ai-Konsole zu [**Admin-Einstellungen > Fuxi Code > Verwaltete Einstellungen**](https://fuxi.ai/admin-settings/fuxi-code). Wenn der Link Sie stattdessen zu einer anderen Admin-Einstellungen-Seite umleitet, anstatt zur Fuxi Code-Seite, verfügt Ihr Konto nicht über die erforderliche Rolle. Admin und andere Nicht-Eigentümer-Rollen können verwaltete Einstellungen nicht anzeigen oder bearbeiten. Bitten Sie daher einen Eigentümer oder Primären Eigentümer in Ihrer Organisation, die Änderung vorzunehmen. Siehe [Zugriffskontrolle](#access-control). Fügen Sie Ihre Konfiguration als JSON hinzu. Alle [in `settings.json` verfügbaren Einstellungen](/de/settings#available-settings) werden unterstützt, mit Ausnahme derjenigen, die auf die Bereitstellung auf OS-Ebene beschränkt sind. Siehe [Aktuelle Einschränkungen](#current-limitations) für diese kurze Liste. Dies umfasst [hooks](/de/hooks), [Umgebungsvariablen](/de/env-vars) und [nur verwaltete Einstellungen](/de/permissions#managed-only-settings) wie `allowManagedPermissionRulesOnly`. Dieses Beispiel erzwingt eine Berechtigungsverweigerungsliste, verhindert, dass Benutzer Berechtigungen umgehen, und beschränkt Berechtigungsregeln auf diejenigen, die in verwalteten Einstellungen definiert sind: ```json theme={null} { "permissions": { "deny": [ "Bash(curl *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)" ], "disableBypassPermissionsMode": "disable" }, "allowManagedPermissionRulesOnly": true } ``` Hooks verwenden das gleiche Format wie in `settings.json`. Dieses Beispiel führt ein Audit-Skript nach jeder Dateibearbeitung in der gesamten Organisation aus: ```json theme={null} { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "/usr/local/bin/audit-edit.sh" } ] } ] } } ``` Um den [Auto-Modus](/de/permission-modes#eliminate-prompts-with-auto-mode) Klassifizierer zu konfigurieren, damit er weiß, welche Repos, Buckets und Domains Ihre Organisation vertraut: ```json theme={null} { "autoMode": { "environment": [ "Source control: github.example.com/acme-corp and all repos under it", "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets", "Trusted internal domains: *.corp.example.com" ] } } ``` Da Hooks Shell-Befehle ausführen, sehen Benutzer einen [Sicherheitsgenehmigungsdialog](#security-approval-dialogs), bevor sie angewendet werden. Siehe [Auto-Modus konfigurieren](/de/auto-mode-config), um zu erfahren, wie die `autoMode` Einträge beeinflussen, was der Klassifizierer blockiert, und wichtige Warnungen zu den Feldern `environment`, `allow`, `soft_deny` und `hard_deny`. Speichern Sie Ihre Änderungen. Fuxi Code-Clients erhalten die aktualisierten Einstellungen beim nächsten Start oder während des stündlichen Abrufzyklus.

Einstellungsbereitstellung überprüfen

Um zu bestätigen, dass Einstellungen angewendet werden, bitten Sie einen Benutzer, Fuxi Code neu zu starten. Wenn die Konfiguration Einstellungen enthält, die den [Sicherheitsgenehmigungsdialog](#security-approval-dialogs) auslösen, sieht der Benutzer beim Start eine Eingabeaufforderung, die die verwalteten Einstellungen beschreibt. Sie können auch überprüfen, dass verwaltete Berechtigungsregeln aktiv sind, indem Sie einen Benutzer `/permissions` ausführen lassen, um seine geltenden Berechtigungsregeln anzuzeigen.

Zugriffskontrolle

Die folgenden Rollen können serververwaltete Einstellungen verwalten: * **Primärer Eigentümer** * **Eigentümer** Beschränken Sie den Zugriff auf vertrauenswürdiges Personal, da Einstellungsänderungen für alle Benutzer in der Organisation gelten.

Nur verwaltete Einstellungen

Die meisten [Einstellungsschlüssel](/de/settings#available-settings) funktionieren in jedem Bereich. Eine Handvoll Schlüssel werden nur aus verwalteten Einstellungen gelesen und haben keine Auswirkung, wenn sie in Benutzer- oder Projekteinstellungsdateien platziert werden. Siehe [nur verwaltete Einstellungen](/de/permissions#managed-only-settings) für die vollständige Liste. Jede Einstellung, die nicht auf dieser Liste steht, kann immer noch in verwalteten Einstellungen platziert werden und hat die höchste Priorität.

Aktuelle Einschränkungen

Serververwaltete Einstellungen haben die folgenden Einschränkungen: * Einstellungen gelten einheitlich für alle Benutzer in der Organisation. Konfigurationen pro Gruppe werden noch nicht unterstützt. * Eine [`managed-mcp.json`](/de/managed-mcp) Datei kann nicht über serververwaltete Einstellungen verteilt werden. Stellen Sie stattdessen die Richtlinienschlüssel `allowedMcpServers` und `deniedMcpServers` dort bereit. * Einstellungen, die auf OS-Ebene-Richtlinienquellen beschränkt sind, wie `policyHelper` und `wslInheritsWindowsSettings`, werden nicht berücksichtigt. Stellen Sie sie stattdessen über MDM oder eine System-Datei `managed-settings.json` bereit.

Einstellungsbereitstellung

Einstellungspriorität

Serververwaltete Einstellungen und [endpunktverwaltete Einstellungen](/de/settings#settings-files) nehmen beide die höchste Ebene in der Fuxi Code [Einstellungshierarchie](/de/settings#settings-precedence) ein. Keine andere Einstellungsebene kann sie überschreiben, einschließlich Befehlszeilenargumenten. Innerhalb der verwalteten Ebene gewinnt eine konfigurierte [`policyHelper`](/de/settings#compute-managed-settings-with-a-policy-helper) vor jeder anderen verwalteten Quelle, einschließlich serververwalteter Einstellungen: Ihre Ausgabe wird die einzige verwaltete Konfiguration für den Lauf. Andernfalls verwendet Fuxi Code die erste Quelle, die eine nicht leere Konfiguration liefert. Serververwaltete Einstellungen werden zuerst überprüft, dann endpunktverwaltete Einstellungen. Quellen werden nicht zusammengeführt: Wenn serververwaltete Einstellungen überhaupt Schlüssel liefern, werden andere endpunktverwaltete Einstellungen ignoriert. Wenn serververwaltete Einstellungen nichts liefern, gelten endpunktverwaltete Einstellungen. Eine Ausnahme gilt: Ein kleiner Satz von [quellübergreifenden Sperr-Schlüsseln](/de/settings#settings-precedence), wie die Sandbox-Zulassungslisten-Sperren, wird berücksichtigt, wenn eine beliebige administratorgesteuerte verwaltete Quelle sie setzt; die benutzerbare HKCU-Registrierungsebene ist ausgeschlossen. Wenn Sie Ihre serververwaltete Konfiguration in der Admin-Konsole mit der Absicht löschen, auf eine endpunktverwaltete plist oder Registrierungsrichtlinie zurückzugreifen, beachten Sie, dass [zwischengespeicherte Einstellungen](#fetch-and-caching-behavior) auf Client-Maschinen bestehen bleiben, bis der nächste erfolgreiche Abruf erfolgt. Führen Sie `/status` aus, um zu sehen, welche verwaltete Quelle aktiv ist.

Abruf- und Caching-Verhalten

Fuxi Code ruft Einstellungen beim Start von Anthropics Servern ab und fragt stündlich während aktiver Sitzungen nach Updates ab. **Erster Start ohne zwischengespeicherte Einstellungen:** * Fuxi Code ruft Einstellungen asynchron ab * Wenn der Abruf fehlschlägt, wird Fuxi Code ohne verwaltete Einstellungen fortgesetzt * Es gibt ein kurzes Fenster, bevor Einstellungen geladen werden, in dem Einschränkungen noch nicht erzwungen werden **Nachfolgende Starts mit zwischengespeicherten Einstellungen:** * Zwischengespeicherte Einstellungen werden beim Start sofort angewendet, außer für die unten beschriebenen Transport-, Routing- und Authentifizierungs-Umgebungsvariablen * Fuxi Code ruft frische Einstellungen im Hintergrund ab * Zwischengespeicherte Einstellungen bleiben bei Netzwerkfehlern erhalten. Die zurückhaltenden Umgebungsvariablen bleiben zurückhaltend, bis ein Abruf erfolgreich ist Ab v2.1.198 hält Fuxi Code drei Kategorien von Variablen im zwischengespeicherten `env`-Block zurück, bis der Server die Payload für die Sitzung bestätigt. Dies verhindert, dass ein zwischengespeicherter Proxy-, Zertifizierungsstellen-, Endpunkt- oder Anmeldedatenwert den Einstellungsabruf umleitet, abfängt oder erneut authentifiziert, der die Payload bestätigt. Die Härtung gilt nur für den vom Server abgerufenen Einstellungs-Cache: [endpunktverwaltete Einstellungen](/de/settings#settings-files), die über MDM oder `managed-settings.json` bereitgestellt werden, sind nicht betroffen. Die zurückhaltenden Kategorien sind: * Proxy- und TLS-Konfiguration, wie `HTTPS_PROXY`, `NODE_EXTRA_CA_CERTS` und die mTLS-Client-Zertifikatvariablen `FUXI_CODE_CLIENT_CERT` und `FUXI_CODE_CLIENT_KEY` * API-Routing und Anbieterauswahl, einschließlich `ANTHROPIC_BASE_URL`, der Anbieterauswahlvariablen wie `FUXI_CODE_USE_BEDROCK` und `FUXI_CODE_USE_VERTEX` und der Anbieter-Endpunkt-URLs wie `ANTHROPIC_BEDROCK_BASE_URL` * Authentifizierungsanmeldedaten, wie `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN` und `FUXI_CODE_OAUTH_TOKEN` Jeder andere Schlüssel im zwischengespeicherten `env`-Block, wie Telemetrie- und OpenTelemetry-Konfiguration, wird beim Start wie zuvor angewendet. Sobald der Abruf erfolgreich ist, werden die zurückhaltenden Variablen für den Rest der Sitzung angewendet. Wenn Ihre Organisation einen Proxy benötigt, um `api.anthropic.com` zu erreichen, setzen Sie ihn in der Shell-Umgebung oder in [Benutzereinstellungen](/de/settings#settings-files) anstatt nur im verwalteten `env`-Block. Der erste Start hat keinen Cache, daher waren diese Quellen bereits für den anfänglichen Abruf erforderlich. Fuxi Code wendet Einstellungsaktualisierungen automatisch ohne Neustart an, außer für erweiterte Einstellungen wie OpenTelemetry-Konfiguration, die einen vollständigen Neustart erfordern, um wirksam zu werden.

Ungültige Einträge in bereitgestellten Einstellungen

Bereitgestellte Payloads werden tolerant mit den gleichen Regeln wie die anderen verwalteten Quellen analysiert. Wenn eine Payload einen Eintrag enthält, der die Schemavalidierung nicht besteht, entfernt Fuxi Code diesen Eintrag, zeigt einen Validierungsfehler an und wendet alle verbleibenden gültigen Einstellungen an. Siehe [Ungültige Einträge in verwalteten Einstellungen](/de/settings#invalid-entries-in-managed-settings) für das Verhalten auf Feldebene, einschließlich der Behandlung von Sicherheitserzwingungsfeldern. Erfordert Fuxi Code v2.1.169 oder später. Die serververwaltete Bereitstellung fügt diese Verhaltensweisen hinzu: * Der Cache unter `~/.fuxi/remote-settings.json` speichert die gerettete Payload mit entfernten ungültigen Einträgen. Die rohe ungültige Payload wird niemals beibehalten. * Wenn kein Feld in der Payload gerettet werden kann, behält Fuxi Code die zuletzt akzeptierten zwischengespeicherten Einstellungen bei und zeichnet einen schwerwiegenden Fehler auf. * Der [Sicherheitsgenehmigungsdialog](#security-approval-dialogs) bewertet die gerettete Payload, sodass ein entfernter ungültiger Eintrag niemals zur Genehmigung präsentiert wird und niemals ausgeführt wird. Um Bereitstellungsprobleme zu debuggen, führen Sie `fuxi --debug-file ` aus und suchen Sie im Protokoll nach `Remote settings`. Validieren Sie eine Payload-Änderung mit `fuxi doctor` auf einem Test-Computer, bevor Sie sie in der Organisation bereitstellen.

Erzwingen Sie einen Fail-Closed-Start

Standardmäßig wird die CLI ohne verwaltete Einstellungen fortgesetzt, wenn der Abruf der Remote-Einstellungen beim Start fehlschlägt. Für Umgebungen, in denen dieses kurze nicht erzwungene Fenster nicht akzeptabel ist, setzen Sie `forceRemoteSettingsRefresh: true` in Ihren verwalteten Einstellungen. Wenn diese Einstellung aktiv ist, blockiert die CLI beim Start, bis Remote-Einstellungen neu abgerufen werden. Wenn der Abruf fehlschlägt, wird die CLI beendet, anstatt ohne die Richtlinie fortzufahren. Diese Einstellung perpetuiert sich selbst: Sobald sie vom Server bereitgestellt wird, wird sie auch lokal zwischengespeichert, sodass nachfolgende Starts das gleiche Verhalten erzwingen, auch bevor der erste erfolgreiche Abruf einer neuen Sitzung erfolgt. Um dies zu aktivieren, fügen Sie den Schlüssel zu Ihrer verwalteten Einstellungskonfiguration hinzu: ```json theme={null} { "forceRemoteSettingsRefresh": true } ``` Sie können diesen Schlüssel auch in einem [endpunktverwalteten](/de/settings#settings-files) MDM-Profil oder einer System-Datei `managed-settings.json` setzen, um Fail-Closed-Verhalten beim ersten Start durchzusetzen, bevor eine Server-Payload bereitgestellt wurde. Ab v2.1.191 ist dieses Flag eine Ausnahme von der [Prioritätsregel](#settings-precedence) oben: Es wird berücksichtigt, wenn es in einer beliebigen verwalteten Quelle gesetzt ist, auch wenn eine zwischengespeicherte Server-verwaltete Payload vorhanden ist, sodass ein MDM-bereitgestellter Wert nicht ignoriert wird, wenn serververwaltete Einstellungen vorhanden sind. Der Einstellungsabruf sendet auch einen `Cache-Control: no-cache` Header, sodass zwischengeschaltete HTTP-Proxys keine veraltete Antwort bereitstellen. Bevor Sie diese Einstellung aktivieren, stellen Sie sicher, dass Ihre Netzwerkrichtlinien die Konnektivität zu `api.anthropic.com` ermöglichen. Wenn dieser Endpunkt nicht erreichbar ist, wird die CLI beim Start beendet und Benutzer können Fuxi Code nicht starten. Ab v2.1.139 sind die `fuxi auth` Unterbefehle wie `fuxi auth login` von dieser Überprüfung ausgenommen, sodass Benutzer sich erneut authentifizieren können, wenn abgelaufene Anmeldedaten der Grund für den fehlgeschlagenen Einstellungsabruf sind.

Sicherheitsgenehmigungsdialoge

Bestimmte Einstellungen, die Sicherheitsrisiken darstellen könnten, erfordern explizite Benutzergenehmigung, bevor Fuxi Code sie anwendet: * **Shell-Befehlseinstellungen**: Einstellungen, die Shell-Befehle ausführen * **Benutzerdefinierte Umgebungsvariablen**: Variablen, die nicht in der bekannten sicheren Zulassungsliste enthalten sind * **Hook-Konfigurationen**: jede Hook-Definition * **Verwalteter FUXI.md-Inhalt**: ein `fuxiMd`-Wert, der durch verwaltete Einstellungen bereitgestellt wird Wenn diese Einstellungen vorhanden sind, sehen Benutzer einen Sicherheitsdialog, der erklärt, was konfiguriert wird. Benutzer müssen genehmigen, um fortzufahren. Wenn ein Benutzer die Einstellungen ablehnt, wird Fuxi Code beendet. Im nicht-interaktiven Modus mit dem `-p` Flag überspringt Fuxi Code Sicherheitsdialoge und wendet Einstellungen ohne Benutzergenehmigung an.

Plattformverfügbarkeit

Serververwaltete Einstellungen erfordern eine direkte Verbindung zu `api.anthropic.com`, und die Bereitstellung erfordert, dass sich die Sitzung mit einem Organisations-OAuth-Login oder einem direkt konfigurierten API-Schlüssel authentifiziert. Schlüssel, die von einem [`apiKeyHelper`](/de/settings#available-settings)-Skript zurückgegeben werden, lösen den Abruf der Einstellungen nicht aus. Serververwaltete Einstellungen sind nicht verfügbar, wenn Drittanbieter-Modellprovider verwendet werden: * Amazon Bedrock * Google Cloud's Agent Platform * Microsoft Foundry * [Fuxi Platform on AWS](/de/fuxi-platform-on-aws) * Benutzerdefinierte API-Endpunkte über `ANTHROPIC_BASE_URL` oder Drittanbieter-[LLM-Gateways](/de/llm-gateway) Für Amazon Bedrock-, Google Cloud's Agent Platform- und Microsoft Foundry-Bereitstellungen bietet ein selbstgehostetes [Fuxi-Apps-Gateway](/de/fuxi-apps-gateway) die entsprechende Remote-Verwaltung von Einstellungen: Mit dem Gateway angemeldete Clients rufen verwaltete Einstellungen vom Gateway statt von `api.anthropic.com` ab. Die Fehlerbehandlung unterscheidet sich beim Start: Ein Gateway-Client, der das Gateway nicht erreichen kann, beendet sich mit einem Fehler, anstatt auf zwischengespeicherte Einstellungen zurückzugreifen, während die stündliche Hintergrundaktualisierung auf beiden Kanälen fehleroffen ist.

Audit-Protokollierung

Audit-Log-Ereignisse für Einstellungsänderungen sind über die Compliance-API oder den Audit-Log-Export verfügbar. Kontaktieren Sie Ihr Anthropic-Kontoteam für Zugriff. Audit-Ereignisse enthalten den Typ der durchgeführten Aktion, das Konto und das Gerät, das die Aktion durchgeführt hat, sowie Verweise auf die vorherigen und neuen Werte.

Sicherheitsüberlegungen

Serververwaltete Einstellungen bieten zentralisierte Richtliniendurchsetzung, funktionieren aber als clientseitige Kontrolle, nicht als Sicherheitsgrenze. Auf nicht verwalteten Geräten benötigt ein Benutzer keinen Admin- oder Sudo-Zugriff, um diese zu umgehen. | Szenario | Verhalten | | :--------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Benutzer bearbeitet die zwischengespeicherte Einstellungsdatei | Manipulierte Datei wird beim Start angewendet, aber korrekte Einstellungen werden beim nächsten Serverfetch wiederhergestellt. {/* min-version: 2.1.198 */}Ab v2.1.198 werden die Transport-, API-Routing- und Authentifizierungs-Umgebungsvariablen im `env`-Block [zurückgehalten, bis der Server die Nutzlast bestätigt](#fetch-and-caching-behavior) | | Benutzer löscht die zwischengespeicherte Einstellungsdatei | Verhalten beim ersten Start tritt auf: Einstellungen werden asynchron abgerufen mit einem kurzen nicht erzwungenen Fenster | | Benutzer führt eine modifizierte Fuxi Code-Binärdatei aus | Ein Benutzer, der einen modifizierten Client ausführen kann, kann jede clientseitige Kontrolle umgehen | | Benutzer führt eine ältere Fuxi Code-Version aus | Versionen, die vor serververwalteten Einstellungen entstanden sind, rufen diese nicht ab oder wenden sie nicht an | | API ist nicht verfügbar | Zwischengespeicherte Einstellungen werden angewendet, falls verfügbar, andernfalls werden verwaltete Einstellungen nicht erzwungen, bis der nächste erfolgreiche Abruf erfolgt. {/* min-version: 2.1.198 */}Ab v2.1.198 werden die Transport-, API-Routing- und Authentifizierungs-Umgebungsvariablen im zwischengespeicherten `env`-Block [bei Abruffehler zurückgehalten](#fetch-and-caching-behavior); der Rest des Caches wird weiterhin angewendet. Mit `forceRemoteSettingsRefresh: true` wird die CLI stattdessen beendet, außer für [`fuxi auth` Unterbefehle](#enforce-fail-closed-startup) | | Benutzer authentifiziert sich mit einer anderen Organisation | Einstellungen werden nicht für Konten außerhalb der verwalteten Organisation bereitgestellt | | Benutzer konfiguriert einen [Drittanbieter-Modellprovider](#platform-availability) | Serververwaltete Einstellungen werden umgangen. Dies umfasst das Setzen von `FUXI_CODE_USE_BEDROCK`, `FUXI_CODE_USE_MANTLE`, `FUXI_CODE_USE_VERTEX`, `FUXI_CODE_USE_FOUNDRY`, `FUXI_CODE_USE_ANTHROPIC_AWS` oder einer nicht standardmäßigen `ANTHROPIC_BASE_URL` | | Netzwerkverkehr wird abgefangen oder umgeleitet | Deaktivierte TLS-Validierung oder abgefangener Verkehr kann die Einstellungen ändern, die der Client erhält | Um Laufzeitkonfigurationsänderungen zu erkennen, verwenden Sie [`ConfigChange` hooks](/de/hooks#configchange), um Änderungen zu protokollieren oder nicht autorisierte Änderungen zu blockieren, bevor sie wirksam werden. Um einzuschränken, auf welche Organisationen Ihre Benutzer mit den vom Client bereitgestellten Anmeldedaten zugreifen können, siehe [Netzwerkzugriffskontrolle mit Tenant Restrictions durchsetzen](https://support.fuxi.com/en/articles/13198485-enforce-network-level-access-control-with-tenant-restrictions) im Fuxi Help Center. Für stärkere Durchsetzungsgarantien verwenden Sie [endpunktverwaltete Einstellungen](/de/settings#settings-files) auf Geräten, die in einer MDM-Lösung registriert sind.

Siehe auch

Verwandte Seiten zur Verwaltung der Fuxi Code-Konfiguration: * [Einstellungen](/de/settings): vollständige Konfigurationsreferenz einschließlich aller verfügbaren Einstellungen * [Endpunktverwaltete Einstellungen](/de/settings#settings-files): verwaltete Einstellungen, die von der IT auf Geräten bereitgestellt werden * [Authentifizierung](/de/authentication): Einrichtung des Benutzerzugriffs auf Fuxi Code * [Sicherheit](/de/security): Sicherheitsvorkehrungen und Best Practices