--- title: Daten und Zugriff in selbst gehostetem Claude Managed Agents url: https://platform.claude.com/docs/de/managed-agents/self-hosted-data-and-access description: Was selbst gehostetes Claude Managed Agents außerhalb deines Netzwerks sendet, wohin sein Log, seine Traces und seine Metriken gehen, wie lange Daten aufbewahrt werden, wer den Server erreichen kann und wie du Mandanten getrennt hältst. --- Um Zugriff auf selbst gehostetes Claude Managed Agents anzufordern, kontaktiere dein Anthropic-Account-Team. Mit [selbst gehostetem Claude Managed Agents](https://platform.claude.com/docs/de/managed-agents/self-hosted) betreibst du den Server, seine Datenbank und die Sandboxes, in denen Worker die Shell- und Datei-Tools des Agenten ausführen. Diese Seite beantwortet die Fragen einer Sicherheitsprüfung. Der Inferenzanbieter des Servers ist der Dienst, der seine Modellaufrufe beantwortet. Der Server verbindet sich nur dann mit Anthropic, wenn dieser Anbieter die Claude API ist. Anthropic hat keinen Fernzugriff auf den Server oder sein Log. ## Was dein Netzwerk verlässt ### Jede Verbindung, die der Server herstellt Der Server verbindet sich nur mit diesen Zielen: * Deinem Inferenzanbieter * Der Datenbank des Servers * Den Diensten, die die Anmeldedaten des Servers für Modellaufrufe ausstellen, falls er diese Anmeldedaten von einem Dienst bezieht * Dem Dienst eines Cloud-Anbieters zum Auflisten von Modellen, falls dein Inferenzanbieter seine Modelle über einen separaten Dienst auflistet * Den MCP-Servern, die du zulässt * Den Git-Hosts, die du zulässt, für die Repositories, die von Sitzungen verwendet werden * Einem OpenTelemetry-Collector, falls du einen konfigurierst * Den Identitätsanbietern, die du für Single Sign-on angibst, falls du welche konfigurierst * Einem Secret-Manager oder einem Schlüsselverwaltungsdienst, falls du einen konfigurierst * Den Diensten, die die Anmeldedaten des Servers für diesen Secret-Manager oder Schlüsselverwaltungsdienst ausstellen * Jedem anderen Dienst, den der Server gemäß deiner Konfiguration aufrufen soll Der Standard-Inferenzanbieter ist die Claude API. Wenn du einen anderen Inferenzanbieter konfigurierst, gehen die Modellaufrufe stattdessen dorthin. Der Server verbindet sich nur dann mit Anthropic, wenn die Claude API sein Inferenzanbieter ist. Wenn der Inferenzanbieter die Tools für Websuche und Web-Abruf anbietet, führt er sie aus. Der Server baut dafür keine eigene Verbindung auf. Die Tools sind deaktiviert, bis du sie in den Einstellungen des Servers aktivierst. Um den Datenverkehr des Servers zu überprüfen, vergleiche das Log deines Egress-Proxys oder deiner Firewall mit dieser Liste. Die Anfragen des Servers an die Claude API enthalten einen `User-Agent`-Header. Siehe [Felder, die die Server-Software benennen](https://platform.claude.com/docs/de/managed-agents/self-hosted-data-and-access#fields-that-name-the-server-software). ### Was Worker erreichen können Die Liste der Ziele deckt nur den Server ab. Das [Egress-Gateway](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#environment-variable-credentials) verbindet sich, falls du es betreibst, mit den Hosts, die du dafür aufführst, und sendet ihnen die Werte der Anmeldedaten, die du für sie speicherst. Worker sind davon getrennt. Ein Worker hat genau den Netzwerkzugriff, den du dem Container, der VM oder der sonstigen Sandbox erlaubst, in der er läuft. Jeder Befehl, den ein Agent über den Worker ausführt, hat denselben Netzwerkzugriff. ### Was der Server an seinen Inferenzanbieter sendet Jeder Modellaufruf enthält die bisherige Konversation, einschließlich Prompts, Tool-Eingaben und Tool-Ergebnissen. Wenn die Claude API der Inferenzanbieter ist, enthält jeder Modellaufruf außerdem bis zu drei Header. Sie enthalten IDs, die dein Server generiert hat: | Header | Was er enthält | | ----------------------------------------- | ---------------------------------------- | | `anthropic-managed-agents-session-id` | Die ID der Sitzung, der der Aufruf dient | | `anthropic-managed-agents-agent-id` | Die ID des Agenten dieser Sitzung | | `anthropic-managed-agents-environment-id` | Die ID der Umgebung dieser Sitzung | Eine ID enthält keinen Namen und keinen Inhalt, kodiert aber den Zeitpunkt, zu dem dein Server sie erstellt hat. Mit diesen Headern kann Anthropic die Nutzung einer Sitzung, einem Agenten oder einer Umgebung zuordnen. Keine Einstellung schaltet sie ab. Wenn `ANTHROPIC_BASE_URL` einen Proxy oder ein Gateway angibt, gehen die Header dorthin. Bei jedem anderen Inferenzanbieter sendet der Server sie nie. Wenn die Claude API der Inferenzanbieter ist, prüft der Server zusätzlich bei der Claude API, ob seine Anmeldedaten für Modellaufrufe gültig sind. Er prüft dies beim Start und danach alle 60 Sekunden, sofern du `health.check_interval` nicht änderst. Bei diesen Prüfungen findet keine Inferenz statt, und sie enthalten keinen der drei Header. ### Felder, die die Server-Software benennen Jede Anfrage an die Claude API hat einen `User-Agent`-Header, der die Server-Software und ihre Version angibt. Der Header selbst identifiziert nicht deine Bereitstellung. Wie bei jeder Anfrage an die Claude API identifiziert der API-Key deine Organisation. Anthropic kann diesen Header verwenden, um die Nutzung von selbst gehostetem Managed Agents zu zählen. Modellaufrufe können außerdem das Label `cma-server` tragen, im Anfragetext als `metadata.user_id`. Das Label ist auf jedem Server gleich, das Label selbst identifiziert also weder deine Bereitstellung noch deine Nutzer oder deine Sitzungen. Wenn ein Aufruf Anthropic erreicht, kann Anthropic das Label verwenden, um die Nutzung von selbst gehostetem Managed Agents zu zählen, selbst wenn ein Proxy den `User-Agent`-Header entfernt hat. Ob ein Aufruf das Label trägt, hängt davon ab, wohin er geht: * **Der Server sendet das Label bei diesen Aufrufen:** Aufrufe an die Claude API, an Microsoft Foundry und an ein Modell-Gateway, das dieselben Anfragen wie die Claude API akzeptiert. * **Der Server sendet `metadata.user_id` nie bei diesen Aufrufen:** Aufrufe an Amazon Bedrock, an Claude Models on Google Cloud (Google managed) und an ein Modell-Gateway, das ein anderes Anfrageformat verwendet. Wenn ein Modell-Gateway oder Proxy einen Aufruf an einen anderen Anbieter weiterleitet, kann `metadata.user_id` mitgesendet werden. Bei den Aufrufen, die `metadata.user_id` enthalten, muss ein eigener Proxy oder ein eigenes Gateway es im Anfragetext akzeptieren. Wenn es das Feld ablehnt, schlägt jeder Modellaufruf fehl. ## Wohin das Log, die Traces und die Metriken gehen Der Server schreibt sein Log in die Standardfehlerausgabe. Wenn du den Server unter Docker, Kubernetes oder einem Dienstmanager ausführst, sammelt dieses System das Log aus der Standardfehlerausgabe. Der Server zeichnet keine Traces oder Metriken auf, bis du sie mit den standardmäßigen OpenTelemetry-Umgebungsvariablen aktivierst. Er sendet sie nur dorthin, wohin diese Variablen zeigen. Auch ein Prometheus-Endpunkt kann Metriken bereitstellen. Siehe [Wo der Server lauscht](https://platform.claude.com/docs/de/managed-agents/self-hosted-data-and-access#where-the-server-listens). ## Wie lange Daten aufbewahrt werden Deine Log-Pipeline, dein Collector und dein Tracing-Backend entscheiden, wie lange das Log, die Traces und die Metriken aufbewahrt werden. Der Server speichert keine Log-Dateien und keine Traces oder Metriken. Alles andere, etwa Agenten, Sitzungen und Sitzungsverlauf, speichert der Server in deiner Datenbank. Wenn du keine Datenbank einrichtest, was die Standardeinstellung ist, hält der Server diese Daten im Arbeitsspeicher, und ein Neustart löscht sie. Wenn du einen Secret-Manager konfigurierst, speichert der Server das Secret neu angelegter [Vault-Anmeldedaten](https://platform.claude.com/docs/de/managed-agents/vaults) dort statt in der Datenbank. Secrets, die er zuvor gespeichert hat, bleiben in der Datenbank. Sitzungen und ihr Verlauf bleiben in deiner Datenbank, bis du sie löschst. Der Server löscht eine Sitzung nicht aufgrund ihres Alters, ob archiviert oder nicht. Das Löschen einer Sitzung über die API entfernt die Sitzung und ihren Verlauf aus deiner Datenbank, wobei der Server jedoch die ID der Sitzung behält. Der Server kann das Löschen verweigern, während eine Sitzung läuft. Das Löschen erreicht keine Kopien an anderen Orten, etwa Datenbank-Backups, exportierte Logs und Traces oder das, was der Agent in einen [Memory-Store](https://platform.claude.com/docs/de/managed-agents/memory) geschrieben hat. Auf Kubernetes lässt das Löschen außerdem das `/workspace`-Volume der Sitzung bestehen, wie [Das Volume einer Sitzung freigeben](https://platform.claude.com/docs/de/managed-agents/self-hosted/kubernetes#free-a-sessions-volume) beschreibt. Was der Server an das Modell sendet und was das Modell zurückgibt, unterliegt der Vereinbarung deiner Organisation mit dem Anbieter, der das Modell bereitstellt. Es gelten die Bedingungen zur Datenaufbewahrung dieser Vereinbarung. Wenn die Claude API das Modell bereitstellt, gelten die Vereinbarung und Einstellungen zur Datenaufbewahrung, die deine Organisation mit Anthropic hat. Wenn deine Organisation eine Vereinbarung zu [Zero Data Retention (ZDR)](https://platform.claude.com/docs/de/manage-claude/api-and-data-retention#zero-data-retention-zdr-scope) hat, deckt diese Vereinbarung diese Modellaufrufe auf dieselbe Weise ab wie andere Messages-API-Aufrufe. Die Seite „API und Datenaufbewahrung“ führt Claude Managed Agents als [nicht durch ZDR abgedeckt](https://platform.claude.com/docs/de/manage-claude/api-and-data-retention#what-zdr-does-not-cover). Das liegt daran, dass Anthropic, wenn es den Dienst betreibt, Sitzungstranskripte speichert, bis du sie löschst. Wer die Transkripte speichert, hängt davon ab, wer den Dienst betreibt: * **Anthropic betreibt ihn:** Anthropic speichert sie. Mit [selbst gehosteten Sandboxes](https://platform.claude.com/docs/de/managed-agents/self-hosted-sandboxes) hostest du nur die Sandboxes, und Anthropic betreibt den Rest. * **Du betreibst ihn, mit selbst gehostetem Managed Agents:** Du speicherst sie selbst. ## Wer den Server erreichen kann Anthropic hat keinen Fernzugriff auf den Server oder sein Log. Deine Anwendungen und Worker verbinden sich mit dem Server. Der Server verbindet sich nie mit einem Worker. ### Anmeldedaten, die der Server akzeptiert Anthropic stellt keine der Anmeldedaten aus, die der Server akzeptiert, und besitzt keine davon. Alle Anmeldedaten, die der Server akzeptiert, gehören zu einer dieser Arten: * Solche, die du festgelegt oder erstellt hast * Solche, die dein Identitätsanbieter ausgestellt hat * Solche, die der Server selbst generiert hat, etwa das Token, das er einem Worker mit jeder Arbeitseinheit übergibt ### Wo der Server lauscht Der Server nimmt API-Anfragen an einer Adresse und einem Port entgegen. Der Server öffnet zwei weitere Listener, jeweils nur, wenn du sie aktivierst. | Listener | Standardmäßig aktiv | Standardadresse | Was er verlangt | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | API-Anfragen | Ja | `127.0.0.1:8400`, nur von derselben Maschine aus erreichbar. Um Adresse und Port zu ändern, setze `server.addr`. | Siehe [Anmeldedaten, die der Server akzeptiert](https://platform.claude.com/docs/de/managed-agents/self-hosted-data-and-access#credentials-that-the-server-accepts). | | Die [Konsole auf deinem Server](https://platform.claude.com/docs/de/managed-agents/self-hosted/console), eine Webseite | Ja. Um sie nicht mehr bereitzustellen, siehe [Die Konsole ausschalten](https://platform.claude.com/docs/de/managed-agents/self-hosted/console#turn-off-the-console). | Dieselbe Adresse und derselbe Port wie bei API-Anfragen | Nichts, um die Seite zu laden, für jeden, der sie erreichen kann. Um in der Konsole etwas zu tun, meldet sich eine Person über deinen Identitätsanbieter an. | | Der Prometheus-Metrik-Endpunkt | Nein | `localhost:9464`, nur von derselben Maschine aus erreichbar | Keine Anmeldedaten | | Der Listener des Servers für das [Egress-Gateway](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#environment-variable-credentials) | Nein | Port 8410 auf jeder Schnittstelle | Den Schlüssel des Gateways | Weitere Details zu den letzten beiden Listenern: * **Der Prometheus-Metrik-Endpunkt:** Er verlangt keine Anmeldedaten, daher hängt es davon ab, wo er lauscht, wer ihn erreichen kann. Wenn du `OTEL_METRICS_EXPORTER` auf `prometheus` setzt und keine Adresse festlegst, lauscht er auf der Standardadresse. Wenn du ihn über das Helm-Chart des Servers aktivierst, lauscht er auf Port 9464 jedes Server-Pods. Dann kann ihn alles erreichen, was eine Route zur Adresse eines Pods hat, sofern keine NetworkPolicy diesen Datenverkehr blockiert. * **Der Listener für das Egress-Gateway:** Das Egress-Gateway ist ein optionaler Proxy zwischen deinen Sandboxes und dem Internet. Der Server lauscht für das Gateway auf einem separaten Port. Dieser Listener spricht einfaches HTTP, und seine Antworten enthalten gespeicherte Werte von Anmeldedaten. Der Compose-Stack und das Helm-Chart des Servers lassen nur das Gateway ihn erreichen. Wenn du den Server auf andere Weise betreibst, tu dasselbe. Der Docker-Compose-Stack veröffentlicht Port 8400 auf der Loopback-Adresse des Docker-Hosts, `127.0.0.1`. Verwende Docker Engine 28.3.3 oder neuer. Unter einigen früheren Versionen können Maschinen im lokalen Netzwerk des Hosts einen Port erreichen, der auf Loopback veröffentlicht ist. Um den Port auf einer anderen Adresse zu veröffentlichen, setze `CMA_PUBLISH_ADDRESS` in `.env`. ## Mandantenfähigkeit Jede Bereitstellung bedient einen Mandanten auf einer Vertrauensstufe. Umgebungen in einer Bereitstellung halten Vertrauensstufen nicht getrennt. Der Server-API-Key erreicht jede Umgebung. Jeder Aufrufer mit einer Rolle kann Sitzungen in jeder Umgebung ausführen, mit allen Netzwerken und Dateien, die die Worker dieser Umgebung erreichen können. | Zu trennen | Vorgehen | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mandanten | Gib jedem Mandanten eine eigene Bereitstellung mit eigener Datenbank, eigenem Server-API-Key und eigenen Workern. | | Workloads mit unterschiedlichen Vertrauensstufen | Gib jeder Vertrauensstufe eine eigene Bereitstellung, eingerichtet wie für einen Mandanten. Beispiele sind vertrauenswürdiger und nicht vertrauenswürdiger Code oder Worker, die Systeme erreichen, die nur manche Aufrufer nutzen dürfen. | | Aufrufer innerhalb einer Bereitstellung | Aktiviere [Single Sign-on](https://platform.claude.com/docs/de/managed-agents/self-hosted/configure#single-sign-on), ordne Gruppen der Rolle `developer` oder `user` zu und behalte den Server-API-Key Administratoren vor. [Was jede Rolle tun kann](https://platform.claude.com/docs/de/managed-agents/self-hosted/configure#what-each-role-can-do) zeigt, was diese Aufrufer sehen. | ### Secret-Manager, Single Sign-on und Modell-Gateways Wenn deine Bereitstellungen einen dieser Dienste verwenden, halte sie auch dort getrennt: * **Secret-Manager:** Halte die Secrets der Bereitstellungen getrennt, wie in den [Einschränkungen des Secret-Managers](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#limits) beschrieben. * **Single Sign-on:** Gib jeder Bereitstellung `audiences`-Einträge, die keine andere Bereitstellung aufführt, damit sie die Tokens der anderen Bereitstellungen ablehnt. Gib in der Bereitstellung jeder Vertrauensstufe eine Rolle nur den Aufrufern, die auf dieser Stufe zugelassen sind, und setze keine `default_role`. * **[Modell-Gateway](https://platform.claude.com/docs/de/managed-agents/self-hosted/inference-provider#model-gateway):** Um die Bereitstellungen zu unterscheiden, gib jeder einen eigenen Wert für einen Header wie `x-tenant-id` unter `inference.headers`. ### Was Rollen nicht beschränken Rollen beschränken nur die Anfragen, die ein Aufrufer mit seinem eigenen Token stellt. Code, den ein Agent ausführt, kann den Server mit allen Anmeldedaten aufrufen, die seine Sandbox enthält. Ein [Umgebungs-Key](https://platform.claude.com/docs/de/managed-agents/self-hosted#the-three-credentials) kann in jeder Sitzung seiner Umgebung Events lesen und Tool-Ergebnisse senden. Führe also jede Sitzung in einer eigenen Sandbox aus und halte den Umgebungs-Key aus dieser Sandbox heraus. Die Stacks in [Erste Schritte mit selbst gehostetem Claude Managed Agents](https://platform.claude.com/docs/de/managed-agents/self-hosted/quickstart) und [Auf Kubernetes bereitstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/kubernetes) tun dies.