Managed AgentsManaged Agents autoalojado

Datos y acceso en Claude Managed Agents autoalojado

Copy page



Qué envía fuera de tu red Claude Managed Agents autoalojado, adónde van su registro, trazas y métricas, cuánto tiempo se conservan los datos, quién puede acceder al servidor y cómo mantener separados a los tenants.

Con Claude Managed Agents autoalojado, tú ejecutas el servidor, su base de datos y los sandboxes donde los “workers” (trabajadores) ejecutan las herramientas de shell y de archivos del agente. Esta página responde a las preguntas de una revisión de seguridad. El proveedor de inferencia del servidor es el servicio que responde sus llamadas al modelo. El servidor se conecta a Anthropic solo cuando ese proveedor es la Claude API. Anthropic no tiene acceso remoto al servidor ni a su registro.

Qué sale de tu red

Todas las conexiones que establece el servidor

El servidor se conecta solo a estos destinos:

• Tu proveedor de inferencia
• La base de datos del servidor
• Los servicios que emiten la credencial del servidor para las llamadas al modelo, si obtiene esa credencial de un servicio
• El servicio de un proveedor de nube para listar modelos, si tu proveedor de inferencia lista sus modelos en un servicio independiente
• Los servidores MCP que permitas
• Los hosts de Git que permitas, para los repositorios que usan las sesiones
• Un recolector de OpenTelemetry, si configuras uno
• Los proveedores de identidad que indiques para el inicio de sesión único, si configuras alguno
• Un gestor de secretos o un servicio de administración de claves, si configuras uno
• Los servicios que emiten la credencial del servidor para ese gestor de secretos o servicio de administración de claves
• Cualquier otro servicio al que llame el servidor, si lo configuras para ello

El proveedor de inferencia predeterminado es la Claude API. Si configuras otro proveedor de inferencia, las llamadas al modelo van a ese proveedor de inferencia en su lugar. El servidor se conecta a Anthropic solo cuando la Claude API es su proveedor de inferencia.

Cuando el proveedor de inferencia ofrece las herramientas de búsqueda web y de obtención web, es él quien las ejecuta. El servidor no establece ninguna conexión propia para ellas. Las herramientas están desactivadas hasta que las activas en la configuración del servidor.

Para verificar el tráfico del servidor, compara el registro de tu proxy de salida o firewall con esta lista. Las solicitudes del servidor a la Claude API llevan un encabezado User-Agent. Consulta Campos que indican el software del servidor.

A qué pueden acceder los workers

La lista de destinos abarca solo el servidor. El gateway de salida, si lo ejecutas, se conecta a los hosts que indiques para él y les envía los valores de credenciales que almacenes para ellos. Los workers son independientes. Un worker tiene el acceso de red que le permitas al contenedor, la VM u otro sandbox en el que se ejecuta. Cada comando que un agente ejecuta a través del worker tiene el mismo acceso de red.

Qué envía el servidor a su proveedor de inferencia

Cada llamada al modelo lleva la conversación hasta ese momento, incluidos los prompts, las entradas de herramientas y los resultados de herramientas.

Cuando la Claude API es el proveedor de inferencia, cada llamada al modelo también lleva hasta tres encabezados. Contienen IDs que generó tu servidor:

Un ID no contiene ningún nombre ni ningún contenido, pero sí codifica el momento en que tu servidor lo creó. Con estos encabezados, Anthropic puede atribuir el uso a una sesión, un agente o un entorno. Ningún ajuste los desactiva. Si ANTHROPIC_BASE_URL indica un proxy o un gateway, los encabezados van allí. Con cualquier otro proveedor de inferencia, el servidor nunca los envía.

Cuando la Claude API es el proveedor de inferencia, el servidor también verifica con la Claude API que su credencial para las llamadas al modelo sea válida. Lo verifica al iniciarse y luego cada 60 segundos, a menos que cambies health.check_interval. Estas verificaciones no ejecutan inferencia ni llevan ninguno de los tres encabezados.

Campos que indican el software del servidor

Cada solicitud a la Claude API tiene un encabezado User-Agent que indica el software del servidor y su versión. El encabezado en sí no identifica tu implementación. Como en toda solicitud a la Claude API, la clave de API identifica a tu organización. Anthropic puede usar ese encabezado para contabilizar el uso de Managed Agents autoalojado.

Las llamadas al modelo también pueden llevar la etiqueta cma-server, en el cuerpo de la solicitud como metadata.user_id. La etiqueta es la misma en todos los servidores, así que la etiqueta en sí no identifica tu implementación, tus usuarios ni tus sesiones. Cuando una llamada llega a Anthropic, Anthropic puede usar la etiqueta para contabilizar el uso de Managed Agents autoalojado, incluso si un proxy eliminó el encabezado User-Agent.

Que una llamada lleve la etiqueta o no depende de adónde va:

• El servidor envía la etiqueta en estas llamadas: las llamadas a la Claude API, a Microsoft Foundry y a un gateway de modelos que acepta las mismas solicitudes que la Claude API.
• El servidor nunca envía metadata.user_id en estas llamadas: las llamadas a Amazon Bedrock, a Claude Models on Google Cloud (Google managed) y a un gateway de modelos que use otro formato de solicitud.

Si un gateway de modelos o un proxy reenvía una llamada a otro proveedor, metadata.user_id puede ir con ella. En las llamadas que llevan metadata.user_id, un proxy o gateway propio debe aceptarlo en el cuerpo de la solicitud. Si rechaza el campo, todas las llamadas al modelo fallan.

Adónde van el registro, las trazas y las métricas

El servidor escribe su registro en la salida de error estándar. Cuando ejecutas el servidor con Docker, Kubernetes o un gestor de servicios, ese sistema recopila el registro desde la salida de error estándar.

El servidor no registra trazas ni métricas hasta que las activas con las variables de entorno estándar de OpenTelemetry. Solo las envía adonde apuntan esas variables. Un endpoint de Prometheus también puede exponer métricas. Consulta Dónde escucha el servidor.

Cuánto tiempo se conservan los datos

Tu pipeline de registros, tu recolector y tu backend de trazas deciden durante cuánto tiempo se conservan el registro, las trazas y las métricas. El servidor no conserva archivos de registro ni almacena trazas ni métricas.

El servidor almacena todo lo demás, como agentes, sesiones e historial de sesiones, en tu base de datos. Si no configuras ninguna base de datos, que es lo predeterminado, el servidor mantiene esos datos en memoria, y un reinicio los borra. Si configuras un gestor de secretos, el servidor guarda allí, en lugar de en la base de datos, el secreto de cada nueva credencial de bóveda. Los secretos que almacenó anteriormente permanecen en la base de datos.

Las sesiones y su historial permanecen en tu base de datos hasta que las eliminas. El servidor no elimina una sesión por su antigüedad, esté archivada o no. Eliminar una sesión a través de la API elimina la sesión y su historial de tu base de datos, aunque el servidor conserva el ID de la sesión. El servidor puede rechazar la eliminación mientras una sesión está en ejecución. La eliminación no alcanza las copias en otros lugares, como las copias de seguridad de la base de datos, los registros y las trazas exportados, o lo que el agente escribió en un almacén de memoria. En Kubernetes, la eliminación también deja en su lugar el volumen /workspace de la sesión, como se describe en Liberar el volumen de una sesión.

Lo que el servidor envía al modelo, y lo que el modelo devuelve, se rige por el acuerdo de tu organización con el proveedor que sirve el modelo. Se aplican los términos de retención de datos de ese acuerdo. Cuando la Claude API sirve el modelo, se aplican el acuerdo de retención de datos y la configuración que tu organización tiene con Anthropic. Si tu organización tiene un acuerdo de retención cero de datos (ZDR), este cubre estas llamadas al modelo de la misma manera que otras llamadas a la Messages API.

La página API y retención de datos indica que Claude Managed Agents no está cubierto por ZDR. Esto se debe a que, cuando Anthropic ejecuta el servicio, almacena las transcripciones de las sesiones hasta que las eliminas. Quién almacena las transcripciones depende de quién ejecuta el servicio:

• Anthropic lo ejecuta: Anthropic las almacena. Con sandboxes autoalojados, tú alojas solo los sandboxes, y Anthropic ejecuta el resto.
• Tú lo ejecutas, con Managed Agents autoalojado: Tú mismo las almacenas.

Quién puede acceder al servidor

Anthropic no tiene acceso remoto al servidor ni a su registro. Tus aplicaciones y workers se conectan al servidor. El servidor nunca se conecta a un worker.

Credenciales que acepta el servidor

Anthropic no emite ninguna de las credenciales que acepta el servidor, ni conserva ninguna de ellas. Cada credencial que acepta el servidor es una de estas:

• Una que configuraste o creaste
• Una que emitió tu proveedor de identidad
• Una que generó el propio servidor, como el token que entrega a un worker con cada unidad de trabajo

Dónde escucha el servidor

El servidor acepta solicitudes de API en una dirección y un puerto. El servidor abre dos “listeners” (agentes de escucha) más, cada uno solo si lo activas.

Más detalles sobre los dos últimos listeners:

• El endpoint de métricas de Prometheus: No solicita ninguna credencial, así que quién puede acceder a él depende de dónde escucha. Si estableces OTEL_METRICS_EXPORTER en prometheus y no estableces ninguna dirección, escucha en la dirección predeterminada. Si lo activas a través del chart de Helm del servidor, escucha en el puerto 9464 de cada pod del servidor. Cualquier cosa con una ruta a la dirección de un pod puede entonces acceder a él, a menos que una NetworkPolicy bloquee ese tráfico.
• El listener para el gateway de salida: El gateway de salida es un proxy opcional entre tus sandboxes e internet. El servidor escucha al gateway en un puerto independiente. Este listener usa HTTP sin cifrar, y sus respuestas llevan valores de credenciales almacenados. El stack de Compose y el chart de Helm del servidor permiten que solo el gateway acceda a él. Si ejecutas el servidor de cualquier otra forma, haz lo mismo.

El stack de Docker Compose publica el puerto 8400 en la dirección de loopback del host de Docker, 127.0.0.1. Ejecuta Docker Engine 28.3.3 o posterior. En algunas versiones anteriores, las máquinas de la red local del host pueden acceder a un puerto publicado en loopback. Para publicar el puerto en otra dirección, establece CMA_PUBLISH_ADDRESS en .env.

Multitenencia

Cada implementación sirve a un “tenant” (inquilino) con un único nivel de confianza. Los entornos de una misma implementación no mantienen separados los niveles de confianza. La clave de API del servidor alcanza todos los entornos. Cada llamador con un rol puede ejecutar sesiones en todos los entornos, con cualquier red y archivos a los que puedan acceder los workers de ese entorno.

Gestores de secretos, inicio de sesión único y gateways de modelos

Si tus implementaciones usan uno de estos servicios, mantenlas separadas también allí:

• Gestor de secretos: Mantén separados los secretos de las implementaciones, como indican los límites del gestor de secretos.
• Inicio de sesión único: Dale a cada implementación entradas audiences que ninguna otra implementación incluya, para que rechace los tokens de las demás implementaciones. En la implementación de cada nivel de confianza, asigna un rol solo a los llamadores permitidos en ese nivel, y no establezcas ningún default_role.
• Gateway de modelos: Para distinguir las implementaciones, dale a cada una su propio valor para un encabezado como x-tenant-id en inference.headers.

Lo que los roles no limitan

Los roles limitan solo las solicitudes que un llamador hace con su propio token. El código que ejecuta un agente puede llamar al servidor con cualquier credencial que contenga su sandbox. Una clave de entorno puede leer eventos y publicar resultados de herramientas en todas las sesiones de su entorno. Así que ejecuta cada sesión en un sandbox propio y mantén la clave de entorno fuera de ese sandbox. Los stacks de Primeros pasos con Claude Managed Agents autoalojado y Implementar en Kubernetes hacen esto.