--- title: Dados e acesso no Claude Managed Agents auto-hospedado url: https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted-data-and-access description: O que o Claude Managed Agents auto-hospedado envia para fora da sua rede, para onde vão seu log, traces e métricas, por quanto tempo os dados são mantidos, quem pode acessar o servidor e como manter os tenants separados. --- Para solicitar acesso ao Claude Managed Agents auto-hospedado, entre em contato com a equipe da sua conta na Anthropic. Com o [Claude Managed Agents auto-hospedado](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted), você executa o servidor, seu banco de dados e os sandboxes em que os “workers” (processos de trabalho) executam as ferramentas de shell e de arquivos do agente. Esta página responde às perguntas de uma revisão de segurança. O “inference provider” (provedor de inferência) do servidor é o serviço que responde às suas chamadas de modelo. O servidor se conecta à Anthropic somente quando esse provedor é a Claude API. A Anthropic não tem acesso remoto ao servidor nem ao seu log. ## O que sai da sua rede ### Todas as conexões que o servidor faz O servidor se conecta apenas a estes destinos: * O seu provedor de inferência * O banco de dados do servidor * Os serviços que emitem a credencial do servidor para chamadas de modelo, se ele obtiver essa credencial de um serviço * O serviço de um provedor de nuvem para listar modelos, se o seu provedor de inferência listar seus modelos em um serviço separado * Os servidores MCP que você permitir * Os hosts Git que você permitir, para os repositórios que as sessões usam * Um coletor OpenTelemetry, se você configurar um * Os provedores de identidade que você listar para single sign-on, se você configurar algum * Um gerenciador de segredos ou um serviço de gerenciamento de chaves, se você configurar um * Os serviços que emitem a credencial do servidor para esse gerenciador de segredos ou serviço de gerenciamento de chaves * Qualquer outro serviço que você configurar para o servidor chamar O provedor de inferência padrão é a Claude API. Se você configurar outro provedor de inferência, as chamadas de modelo vão para lá em vez disso. O servidor se conecta à Anthropic somente quando a Claude API é seu provedor de inferência. Quando o provedor de inferência oferece as ferramentas de pesquisa na web e web fetch, é ele quem as executa. O servidor não faz nenhuma conexão própria para elas. As ferramentas ficam desativadas até que você as ative nas configurações do servidor. Para verificar o tráfego do servidor, compare o log do seu proxy de saída ou firewall com esta lista. As solicitações do servidor para a Claude API carregam um cabeçalho `User-Agent`. Consulte [Campos que nomeiam o software do servidor](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted-data-and-access#fields-that-name-the-server-software). ### O que os workers podem acessar A lista de destinos abrange somente o servidor. O [egress gateway](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/agent-identity#environment-variable-credentials), se você o executar, se conecta aos hosts que você listar para ele e envia a eles os valores de credenciais que você armazenar para eles. Os workers são separados. Um worker tem o acesso à rede que você permitir ao contêiner, à VM ou a outro sandbox em que ele é executado. Cada comando que um agente executa por meio do worker tem o mesmo acesso à rede. ### O que o servidor envia ao seu provedor de inferência Cada chamada de modelo carrega a conversa até o momento, incluindo prompts, entradas de ferramentas e resultados de ferramentas. Quando a Claude API é o provedor de inferência, cada chamada de modelo também carrega até três cabeçalhos. Eles contêm IDs que o seu servidor gerou: | Cabeçalho | O que contém | | ----------------------------------------- | -------------------------------------- | | `anthropic-managed-agents-session-id` | O ID da sessão à qual a chamada atende | | `anthropic-managed-agents-agent-id` | O ID do agente dessa sessão | | `anthropic-managed-agents-environment-id` | O ID do ambiente dessa sessão | Um ID não contém nenhum nome nem conteúdo, mas codifica o momento em que o seu servidor o criou. Com esses cabeçalhos, a Anthropic pode atribuir o uso a uma sessão, a um agente ou a um ambiente. Nenhuma configuração os desativa. Se `ANTHROPIC_BASE_URL` indicar um proxy ou um gateway, os cabeçalhos vão para lá. Com qualquer outro provedor de inferência, o servidor nunca os envia. Quando a Claude API é o provedor de inferência, o servidor também verifica com a Claude API se sua credencial para chamadas de modelo é válida. Ele verifica na inicialização e depois a cada 60 segundos, a menos que você altere `health.check_interval`. Essas verificações não executam nenhuma inferência e não carregam nenhum dos três cabeçalhos. ### Campos que nomeiam o software do servidor Toda solicitação à Claude API tem um cabeçalho `User-Agent` que nomeia o software do servidor e sua versão. O cabeçalho em si não identifica a sua implantação. Como em toda solicitação à Claude API, a chave de API identifica a sua organização. A Anthropic pode usar esse cabeçalho para contabilizar o uso do Managed Agents auto-hospedado. As chamadas de modelo também podem carregar o rótulo `cma-server`, no corpo da solicitação como `metadata.user_id`. O rótulo é o mesmo em todos os servidores, então o rótulo em si não identifica a sua implantação, os seus usuários nem as suas sessões. Quando uma chamada chega à Anthropic, a Anthropic pode usar o rótulo para contabilizar o uso do Managed Agents auto-hospedado, mesmo que um proxy tenha removido o cabeçalho `User-Agent`. Se uma chamada carrega o rótulo ou não depende de para onde ela vai: * **O servidor envia o rótulo nestas chamadas:** chamadas para a Claude API, para o Microsoft Foundry e para um model gateway que aceita as mesmas solicitações que a Claude API. * **O servidor nunca envia `metadata.user_id` nestas chamadas:** chamadas para o Amazon Bedrock, para o Claude Models on Google Cloud (Google managed) e para um model gateway que usa outro formato de solicitação. Se um model gateway ou proxy repassar uma chamada para outro provedor, `metadata.user_id` pode ir junto com ela. Nas chamadas que carregam `metadata.user_id`, um proxy ou gateway seu precisa aceitá-lo no corpo da solicitação. Se ele rejeitar o campo, todas as chamadas de modelo falham. ## Para onde vão o log, os traces e as métricas O servidor grava seu log na saída de erro padrão. Quando você executa o servidor sob Docker, Kubernetes ou um gerenciador de serviços, esse sistema coleta o log da saída de erro padrão. O servidor não registra traces nem métricas até que você os ative com as variáveis de ambiente padrão do OpenTelemetry. Ele os envia somente para onde essas variáveis apontam. Um endpoint do Prometheus também pode expor métricas. Consulte [Onde o servidor escuta](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted-data-and-access#where-the-server-listens). ## Por quanto tempo os dados são mantidos O seu pipeline de logs, o seu coletor e o seu backend de tracing decidem por quanto tempo o log, os traces e as métricas são mantidos. O servidor não mantém arquivos de log e não armazena traces nem métricas. O servidor armazena todo o resto, como agentes, sessões e histórico de sessões, no seu banco de dados. Se você não configurar nenhum banco de dados, que é o padrão, o servidor mantém esses dados em memória, e uma reinicialização os apaga. Se você configurar um gerenciador de segredos, o servidor mantém ali o segredo de cada nova [credencial de vault](https://platform.claude.com/docs/pt-BR/managed-agents/vaults), em vez de no banco de dados. Os segredos que ele armazenou anteriormente permanecem no banco de dados. As sessões e o histórico delas permanecem no seu banco de dados até que você os exclua. O servidor não exclui uma sessão por causa da idade dela, arquivada ou não. Excluir uma sessão por meio da API remove a sessão e o seu histórico do seu banco de dados, embora o servidor mantenha o ID da sessão. O servidor pode recusar a exclusão enquanto uma sessão estiver em execução. A exclusão não alcança cópias em outros lugares, como backups do banco de dados, logs e traces exportados, ou o que o agente gravou em um [armazenamento de memória](https://platform.claude.com/docs/pt-BR/managed-agents/memory). No Kubernetes, a exclusão também mantém o volume `/workspace` da sessão no lugar, conforme descrito em [Liberar o volume de uma sessão](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/kubernetes#free-a-sessions-volume). O que o servidor envia ao modelo e o que o modelo retorna estão sujeitos ao contrato da sua organização com o provedor que serve o modelo. Aplicam-se os termos de retenção de dados desse contrato. Quando a Claude API serve o modelo, aplicam-se o contrato e as configurações de retenção de dados que sua organização tem com a Anthropic. Se sua organização tiver um arranjo de [retenção zero de dados (ZDR)](https://platform.claude.com/docs/pt-BR/manage-claude/api-and-data-retention#zero-data-retention-zdr-scope), ele abrange essas chamadas de modelo da mesma forma que outras chamadas da Messages API. A página API e retenção de dados lista o Claude Managed Agents como [não abrangido pela ZDR](https://platform.claude.com/docs/pt-BR/manage-claude/api-and-data-retention#what-zdr-does-not-cover). Isso ocorre porque, quando a Anthropic executa o serviço, ela armazena as transcrições de sessão até que você as exclua. Quem armazena as transcrições depende de quem executa o serviço: * **A Anthropic o executa:** A Anthropic as armazena. Com [sandboxes auto-hospedados](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted-sandboxes), você hospeda apenas os sandboxes, e a Anthropic executa o resto. * **Você o executa, com o Managed Agents auto-hospedado:** Você mesmo as armazena. ## Quem pode acessar o servidor A Anthropic não tem acesso remoto ao servidor nem ao seu log. Seus aplicativos e workers se conectam ao servidor. O servidor nunca se conecta a um worker. ### Credenciais que o servidor aceita A Anthropic não emite nenhuma das credenciais que o servidor aceita e não detém nenhuma delas. Toda credencial que o servidor aceita é uma destas: * Uma que você definiu ou criou * Uma que seu provedor de identidade emitiu * Uma que o próprio servidor gerou, como o token que ele entrega a um worker com cada unidade de trabalho ### Onde o servidor escuta O servidor aceita solicitações de API em um endereço e uma porta. O servidor abre mais dois listeners, cada um somente se você o ativar. | Listener | Ativado por padrão | Endereço padrão | O que ele exige | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Solicitações de API | Sim | `127.0.0.1:8400`, que apenas a mesma máquina consegue acessar. Para alterar o endereço e a porta, defina `server.addr`. | Consulte [Credenciais que o servidor aceita](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted-data-and-access#credentials-that-the-server-accepts). | | O [console no seu servidor](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/console), uma página web | Sim. Para parar de servi-lo, consulte [Desativar o console](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/console#turn-off-the-console). | O mesmo endereço e a mesma porta das solicitações de API | Nada para carregar a página, para qualquer pessoa que consiga acessá-la. Para fazer qualquer coisa no console, uma pessoa faz login por meio do seu provedor de identidade. | | O endpoint de métricas do Prometheus | Não | `localhost:9464`, que apenas a mesma máquina consegue acessar | Nenhuma credencial | | O listener do servidor para o [egress gateway](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/agent-identity#environment-variable-credentials) | Não | Porta 8410 em todas as interfaces | A chave do gateway | Mais detalhes sobre os dois últimos listeners: * **O endpoint de métricas do Prometheus:** Ele não exige nenhuma credencial, então quem consegue acessá-lo depende de onde ele escuta. Se você definir `OTEL_METRICS_EXPORTER` como `prometheus` e não definir nenhum endereço, ele escuta no endereço padrão. Se você ativá-lo por meio do Helm chart do servidor, ele escuta na porta 9464 de cada pod do servidor. Qualquer coisa com uma rota para o endereço de um pod pode então acessá-lo, a menos que uma NetworkPolicy bloqueie esse tráfego. * **O listener para o egress gateway:** O egress gateway é um proxy opcional entre os seus sandboxes e a internet. O servidor escuta o gateway em uma porta separada. Esse listener usa HTTP simples, e as respostas dele carregam valores de credenciais armazenados. A stack do Compose e o Helm chart do servidor permitem que apenas o gateway o acesse. Se você executar o servidor de qualquer outra forma, faça o mesmo. A stack Docker Compose publica a porta 8400 no endereço de loopback do host Docker, `127.0.0.1`. Execute o Docker Engine 28.3.3 ou posterior. Em algumas versões anteriores, máquinas na rede local do host conseguem acessar uma porta publicada no loopback. Para publicar a porta em outro endereço, defina `CMA_PUBLISH_ADDRESS` em `.env`. ## Multilocação Cada implantação atende a um “tenant” (locatário) em um nível de confiança. Ambientes em uma mesma implantação não mantêm os níveis de confiança separados. A chave de API do servidor alcança todos os ambientes. Todo chamador com um role pode executar sessões em todos os ambientes, com qualquer rede e arquivos que os workers desse ambiente consigam acessar. | Para manter separados | Faça isto | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Tenants | Dê a cada tenant sua própria implantação, com seu próprio banco de dados, chave de API do servidor e workers. | | Cargas de trabalho em diferentes níveis de confiança | Dê a cada nível de confiança sua própria implantação, configurada como para um tenant. Exemplos são código confiável e não confiável, ou workers que acessam sistemas que somente alguns chamadores podem usar. | | Chamadores em uma implantação | Ative o [single sign-on](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#single-sign-on), mapeie grupos para o role `developer` ou `user` e reserve a chave de API do servidor para administradores. [O que cada função pode fazer](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/configure#what-each-role-can-do) mostra o que esses chamadores veem. | ### Gerenciadores de segredos, single sign-on e model gateways Se as suas implantações usarem um desses serviços, mantenha-as separadas também neles: * **Gerenciador de segredos:** Mantenha os segredos das implantações separados, conforme os [limites do gerenciador de segredos](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/agent-identity#limits). * **Single sign-on:** Dê a cada implantação entradas `audiences` que nenhuma outra implantação lista, para que ela recuse os tokens das outras implantações. Na implantação de cada nível de confiança, atribua um role somente aos chamadores permitidos nesse nível e não defina `default_role`. * **[Model gateway](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/inference-provider#model-gateway):** Para distinguir as implantações, dê a cada uma seu próprio valor para um cabeçalho como `x-tenant-id` em `inference.headers`. ### O que os roles não limitam Os roles limitam somente as solicitações que um chamador faz com o próprio token. O código que um agente executa pode chamar o servidor com qualquer credencial que o sandbox dele contenha. Uma [chave de ambiente](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted#the-three-credentials) pode ler eventos e publicar resultados de ferramentas em todas as sessões no seu ambiente. Então execute cada sessão em um sandbox próprio e mantenha a chave de ambiente fora desse sandbox. As stacks em [Comece a usar o Claude Managed Agents auto-hospedado](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/quickstart) e [Implantar no Kubernetes](https://platform.claude.com/docs/pt-BR/managed-agents/self-hosted/kubernetes) fazem isso.