Claude self-hosted: verifique a fronteira entre agentes e inferência
Operar agentes na própria infraestrutura muda as responsabilidades de segurança e de continuidade. O aceite precisa mostrar onde o serviço roda, quais dados saem e quem controla cada acesso.
Read in EnglishPor Pentesty
O anúncio abre uma opção de operação
Em 12 de novembro de 2026, a Anthropic anunciou a beta privada de Claude Managed Agents self-hosted. O anúncio descreve harness, sandboxes, credenciais e histórico na infraestrutura do cliente, com solicitações de modelo encaminhadas ao provedor escolhido. A escolha exige distinguir o serviço de agentes da inferência que ele utiliza.
Antes de aprovar um piloto, escreva qual necessidade empresarial motivou a mudança: localização do histórico, integração interna ou controle operacional. Dê a cada necessidade um critério observável e um responsável. Isso permite comparar alternativas pelo problema que resolvem e identificar compromissos que o nome do produto não responde.
Desenhe execução, armazenamento e chamada de modelo
A arquitetura documentada separa o servidor cma-server dos workers que executam ferramentas. Ela exige PostgreSQL 16 ou posterior para persistência; sem banco, os dados ficam em memória e desaparecem no reinício. O modelo continua em Anthropic ou em outro provedor selecionado.
Monte um diagrama com endereços, proprietários e caminhos autorizados entre aplicação, servidor, banco, workers e provedor. Inclua dependências administradas por terceiros. Em um ambiente de teste, compare esse desenho com conexões observadas durante uma tarefa fictícia. Uma diferença precisa de explicação e de encaminhamento antes de se tornar uma exceção permanente.
Observe o que efetivamente deixa o ambiente
A página de dados e acesso informa que cada chamada envia a conversa acumulada, inclusive entradas e resultados de ferramentas, ao provedor de inferência. A mesma documentação define uma implantação por tenant e nível de confiança. Portanto, hospedar o serviço não estabelece isolamento de todo o fluxo.
Use uma tarefa com conteúdo sintético e identifique quais classes de informação poderiam aparecer nos resultados de ferramentas. Relacione cada saída ao destino aprovado e ao responsável por autorizar seu uso. Defina como o time demonstrará a recusa de um destino não permitido, sem introduzir dados de clientes para produzir essa evidência. A análise de consentimento para agentes complementa essa revisão.
Planeje a migração como uma mudança própria
As diferenças do serviço incluem ausência de cópia automática do histórico hospedado e necessidade de recriar agentes, skills, credenciais e memory stores. A documentação também informa que o servidor próprio não envia webhooks. Essas condições precisam entrar na análise de dependências do piloto.
Liste o que o fluxo empresarial precisa fazer no primeiro dia e o que pode aguardar. Para cada dependência, retenha uma demonstração com resultado esperado e observado. Teste uma falha controlada e identifique quem recebe a ocorrência. Um processo que só termina com a intervenção de quem o construiu ainda precisa de um encaminhamento operacional claro.
Faça credenciais e continuidade participarem do aceite
Prepare uma matriz de acessos por função, usando identidades de teste e permissões limitadas ao piloto. Registre quem pode criar agentes, iniciar sessões, alterar integrações e recuperar o serviço. Peça ao revisor que explique, pelos registros, qual identidade realizou cada ação. Não inclua valores de segredos nas evidências entregues para aceite.
Combine também uma janela de manutenção e um exercício de recuperação com dados fictícios. A equipe deve localizar a versão implantada, a configuração aprovada e o responsável pelo retorno. A revisão de chaves de provedores ajuda a relacionar rotação e acesso efetivo; a avaliação de integrações MCP acrescenta critérios de mudança e reteste.
Entregue uma conclusão que outra equipe consiga revisar
A recomendação empresarial é fechar o piloto com um pacote pequeno: desenho dos fluxos, amostra de tarefa sintética, decisões de acesso, resultados de recuperação e exceções com prazo. Se um requisito depender de contrato ou de avaliação especializada, identifique o responsável e preserve a pendência no parecer, sem substituí-la por uma afirmação genérica de soberania.
Peça a uma pessoa externa à implantação que reconstrua uma sessão e encontre a decisão que autorizou seus destinos. O aceite deve dizer qual uso está aprovado e que mudança exige nova análise. Essa conclusão serve tanto para continuar o piloto quanto para adiá-lo, porque mantém a decisão ligada ao escopo examinado e às evidências disponíveis.
Perguntas frequentes
Self-hosted significa que o modelo roda no nosso servidor?
A documentação distingue o serviço de agentes do provedor que executa o modelo. Confirme esse caminho no desenho aprovado e na observação do piloto.
Qual é a primeira evidência útil do piloto?
Um fluxo de tarefa sintética que relacione origem, ferramenta, destino e responsável pela autorização. Compare o resultado observado com o requisito que motivou o projeto.
Podemos aceitar a migração pelo funcionamento de uma única tarefa?
Escolha amostras que representem as dependências empresariais e inclua falha e recuperação. Registre o que ficou fora do teste para que o aceite não amplie o escopo por omissão.
O que precisa ficar com a equipe de operação?
Versão, configuração aprovada, acessos por função, critérios de manutenção e retorno, responsáveis e pendências. A entrega deve ser suficiente para uma revisão sem depender do autor do piloto.
Fontes e referências
- Anthropic: anúncio da beta privada
- Anthropic: arquitetura e responsabilidades
- Anthropic: dados e fronteiras de acesso
- Anthropic: diferenças e migração
Análise original da Pentesty, publicada em 12 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.