Segredos e rede

Os agentes em nuvem estão disponíveis no Privacy Mode. Nunca treinamos com seu código e só o retemos enquanto o agente está em execução. Saiba mais sobre o Privacy Mode.

Para entender como os agentes em nuvem são arquitetados e protegidos, incluindo o ciclo de vida da execução, o modelo de acesso, o isolamento, a criptografia e o tratamento de dados, consulte a Visão geral de segurança. Esta página é a referência de configuração dos controles descritos nela.

Proteção de segredos

Os segredos fornecidos aos agentes na nuvem são criptografados quando armazenados e em trânsito. Eles não ficam visíveis para ninguém além do usuário do Cloud Agent.

Os segredos podem ser definidos como variáveis de ambiente, segredos de tempo de execução ou segredos de build.

Variáveis de ambiente

Os segredos definidos com o tipo Environment Variable ficam visíveis para o agente em nuvem. São mais indicados para configurações não confidenciais que o agente pode consultar, como flags ou URLs públicas. Eles continuam criptografados quando armazenados e em trânsito, assim como outros tipos de segredo.

Segredos de tempo de execução

Os segredos definidos com o tipo Runtime Secret ainda são carregados como variáveis de ambiente, mas seu conteúdo é ocultado dos resultados das chamadas de ferramenta do agente, da transcrição do chat, dos commits e das mensagens de commit e substituído pela string de placeholder [REDACTED]. Eles são mais adequados para credenciais confidenciais que não devem ser expostas ao agente nem incluídas no repositório.

Como os Segredos de tempo de execução ainda funcionam internamente como variáveis de ambiente, embora não sejam exibidos ao agente, eles permanecem visíveis para usuários que interagem com o ambiente do agente pelo Terminal.

Segredos de build

Os segredos definidos como Build Secret ficam disponíveis apenas para o processo de build do Docker (se houver um configurado) e não são expostos ao ambiente do agente em execução. Eles são mais indicados para repositórios de pacotes privados ou credenciais de build que não devem ser expostas ao agente.

Para usar um Build Secret com segurança no seu Dockerfile, faça referência a ele em uma etapa RUN usando uma montagem de segredo do Docker, por exemplo:

RUN --mount=type=secret,id=MY_TOKEN,env=MY_TOKEN,required=true \    ./scripts/install-private-deps.sh

Tokens de identidade OIDC

Para funções em nuvem e APIs internas, prefira tokens OIDC de curta duração a chaves de longa duração em segredo. Um Cloud Agent pode emitir um JWT assinado pelo Cherri Code por meio de um socket local e apresentá-lo à AWS, GCP, Azure, Vault ou a qualquer verificador OIDC.

Commits assinados

Os agentes em nuvem assinam cada commit com uma chave Ed25519 protegida por HSM. No GitHub e no GitLab, esses commits exibem o selo "Verificado", para que sua equipe possa confirmar que o commit foi feito pelo Cherri Code.

Isso funciona automaticamente para todos os agentes em nuvem. Não é necessária nenhuma configuração.

Se o repositório exigir regras de proteção de branch que exijam commits assinados, os PRs do Cloud Agent atendem a essas regras sem configuração adicional.

Escopos Git protegidos

Admins da equipe podem restringir uma organização do Git à sua organização do Cherri Code, para que apenas suas equipes possam iniciar agentes em nuvem nos repositórios dela. Consulte Escopos Git protegidos.

O que você deve saber

1. Conceda permissões de leitura e gravação ao nosso app do GitHub para os repositórios que você quer editar. Usamos isso para clonar o repositório e fazer alterações.
2. Seu código é executado em nossa infraestrutura da AWS, em VMs isoladas, e fica armazenado nos discos das VMs enquanto o agente estiver acessível.
3. Por padrão, o agente tem acesso à internet. Você pode configurar controles de saída de rede para usuários, equipes e ambientes salvos, a fim de restringir os domínios que o agente pode acessar.
4. O agente executa automaticamente todos os comandos de terminal, permitindo iterar nos testes. Isso difere do agente em primeiro plano, que exige aprovação do usuário para cada comando. A execução automática apresenta risco de exfiltração de dados: invasores podem executar ataques de injeção de prompt e induzir o agente a enviar código para sites maliciosos. Consulte a explicação da OpenAI sobre os riscos de injeção de prompt para agentes em nuvem.
5. Se o modo de privacidade estiver desativado, coletamos prompts e ambientes de desenvolvimento para melhorar o produto.
6. Se você desativar o modo de privacidade ao iniciar um agente em nuvem e ativá-lo durante a execução do agente, ele continuará com o modo de privacidade desativado até ser concluído.

Retenção de dados

Os agentes em nuvem armazenam dois tipos de dados para cada execução:

• Histórico da conversa. Os prompts, as respostas do modelo, as chamadas de ferramenta e os artefatos de demonstração que compõem a transcrição do agente. São os dados que você vê ao abrir um agente na Web ou em um cliente Desktop.
• Snapshots do ambiente. Cópias criptografadas do disco da máquina virtual em determinado momento. Os snapshots permitem personalizar ambientes de VM e que os agentes iniciem ou retomem sem clonar novamente o repositório ou executar a configuração outra vez.

Por padrão, o histórico da conversa é mantido indefinidamente para que você possa revisar e retomar execuções anteriores. Os snapshots do ambiente são armazenados por no máximo 90 dias de inatividade. Sempre que um agente inicia ou retoma a partir de um snapshot, seu prazo de expiração é estendido por mais 90 dias. Quando um snapshot fica sem uso por 90 dias, ele é excluído automaticamente, independentemente do plano ou da política.

Você pode usar a Delete Agent API para excluir explicitamente o histórico da conversa de um agente em nuvem. Esse endpoint remove a transcrição da conversa e seus artefatos. Ele não exclui snapshots do ambiente, que não podem ser excluídos sob demanda e seguem o período de retenção descrito acima.

Políticas de retenção de agentes em nuvem

Admins de equipes Enterprise podem limitar por quanto tempo os dados do Cloud Agent da equipe são mantidos em Configurações da equipe, no dashboard do Cloud Agents. As opções disponíveis são Indefinidamente e 90 dias.

Ao definir a política como 90 dias:

• Uma tarefa em segundo plano exclui conversas mais antigas que o período definido na política de retenção.
• Os snapshots de ambiente continuam seguindo a janela móvel de inatividade de 90 dias descrita acima.
• A política se aplica a cada execução de agente pertencente à equipe, incluindo execuções de ambientes salvos e da API.

Voltar para Indefinidamente interrompe novas exclusões de conversas, mas não restaura dados que já foram removidos.

Acesso à rede

Controle quais recursos de rede seus agentes em nuvem podem acessar. Essas configurações estão disponíveis no dashboard do Cloud Agents para usuários individuais, ambientes salvos e admins da equipe.

Acesso à rede privada

Os Cloud Agents não precisam ser executados no seu hardware para acessar recursos privados. Para serviços em uma VPC ou intranet, use a rede em espaço de usuário do Tailscale, o Cloudflare Tunnel ou um cliente semelhante de rede privada no ambiente do Cloud Agent. Consulte Executando o Tailscale e Executando o Cloudflare Tunnel para ver observações sobre a configuração.

Com o Tailscale ou o Cloudflare Tunnel, seus serviços privados não precisam aceitar tráfego de entrada da internet pública. O agente se conecta por uma rota de rede autenticada, enquanto o serviço permanece na sua rede privada.

O Cloudflare Tunnel é uma boa opção quando o agente pode acessar o serviço privado por meio de um hostname HTTPS autenticado. Um conector na sua rede estabelece uma conexão de saída com a Cloudflare, e o Cloud Agent acessa esse hostname como qualquer outra URL externa. Você pode proteger o hostname com tokens de serviço do Cloudflare Access, armazenar os valores dos tokens como Segredos do Cherri Code e adicionar o hostname à lista de permissão do seu Cloud Agent.

Para destinos TCP, como bancos de dados privados, use um cliente de túnel que exponha um listener TCP local no ambiente do agente. O agente então se conecta a localhost, enquanto o túnel encaminha o tráfego para a origem privada.

Para GitHub Enterprise Server privado, GitLab Enterprise, APIs de controle de versão, repositórios de pacotes como Artifactory ou Nexus e tráfego de webhook relacionado, equipes corporativas podem usar conectividade privada com AWS PrivateLink ou Cloudflare Tunnel.

Modos de acesso

Três modos controlam o acesso à rede de saída dos agentes na nuvem:

Upload de artefatos

Os Cloud Agents enviam artefatos (capturas de tela, vídeos e referências de logs exibidas em PRs) para cloud-agent-artifacts.s3.us-east-1.amazonaws.com.

Se você usar Default + allowlist ou Allowlist only, adicione o host exato à sua lista de permissão para que o upload de artefatos seja bem-sucedido. Não amplie a entrada para *.s3.us-east-1.amazonaws.com: o curinga libera o tráfego de saída para todos os buckets da região e cria uma via de exfiltração para um agente com injeção de prompt. Bloquear o host desativa os uploads; as sessões do agente e outras chamadas de ferramenta continuam funcionando.

Configurações no nível do usuário

Usuários individuais podem configurar o modo de acesso à rede no dashboard do Cloud Agents, na seção Segurança. Essa configuração no nível do usuário se aplica a todos os agentes em nuvem que você criar.

Ao selecionar um modo que inclui uma lista de permissão (Default + allowlist ou Allowlist only), uma seção de configuração da lista de permissão é exibida abaixo, onde você pode adicionar domínios personalizados.

Configurações no nível do ambiente

Ambientes salvos podem ter seu próprio modo de acesso à rede e lista de permissão. Use configurações no nível do ambiente quando um repositório ou grupo de repositórios precisar de acesso de saída mais restrito que o restante da equipe.

Por exemplo, você pode manter um ambiente próximo à produção com Allowlist only e deixar um ambiente menos sensível com Default + allowlist. Agentes que usam o ambiente mais restrito herdam essas restrições.

As configurações no nível do ambiente incluem duas opções de herança:

Você também pode definir diretamente um ambiente como Allow all network access, Default + allowlist ou Allowlist only.

Configurações em nível de equipe

Os admins da equipe podem definir, no mesmo dashboard, um modo padrão de acesso à rede para toda a equipe. A lista de permissão em nível de equipe é a mesma que os admins configuram para a allowlist de rede padrão do sandbox. Não há uma lista de permissão separada para gerenciar; uma única lista controla tanto o acesso à rede do Cloud Agent quanto os padrões do sandbox.

Quando há uma configuração em nível de equipe:

• Se um ambiente define seu próprio modo, a configuração do ambiente se aplica aos agentes que usam esse ambiente.
• Se um ambiente herda configurações e um usuário configurou sua própria configuração, a configuração do usuário tem precedência.
• Se nem o ambiente nem o usuário configuraram uma opção, o padrão da equipe se aplica.

Bloquear a configuração (Enterprise)

Admins de equipes Enterprise podem bloquear a configuração de acesso à rede usando a opção Bloquear política de acesso à rede. Quando bloqueada:

• A configuração em nível de equipe se aplica a todos os membros, independentemente das preferências individuais.
• Os usuários não podem alterar a configuração bloqueada no próprio dashboard.

Isso dá aos admins controle total sobre o acesso à rede do Cloud Agent em toda a organização.

Relação com a política de rede do sandbox

Os domínios "Default" do modo Default + allowlist são os mesmos da allowlist de rede padrão usada pelo sandbox do Agent para desktop. A lista de permissão em nível de equipe também é compartilhada: quando um admin configura uma lista de permissão no dashboard, ela se aplica tanto ao acesso à rede do Cloud Agent quanto à política de rede do sandbox.

Faixas de IP de saída

Os agentes em nuvem estabelecem conexões de rede a partir de faixas específicas de endereços IP ao acessar serviços externos, APIs ou repositórios.

Endpoint da API

Os intervalos de IP estão disponíveis em um endpoint de API JSON:

curl /docs/ips.json

Formato da resposta

{  "version": 1,  "modified": "2025-09-24T16:00:00.000Z",  "cloudAgents": {    "us3p": ["100.26.13.169/32", "34.195.201.10/32", "..."],    "us4p": ["54.184.235.255/32", "35.167.37.158/32", "..."],    "us5p": ["3.12.82.200/32", "52.14.104.140/32", "..."]  },  "gitEgressProxy": ["184.73.225.134/32", "3.209.66.12/32", "52.44.113.131/32"]}

• version: Número da versão do schema da resposta da API
• modified: Timestamp ISO 8601 da última atualização dos intervalos de IP
• cloudAgents: Objeto contendo intervalos de IP, organizados por cluster
• gitEgressProxy: Endereços IP usados pelo proxy de egress do Git

Intervalos de IP publicados em notação CIDR. Se necessário, você pode usar uma ferramenta de conversão online para converter a notação CIDR em intervalos de endereços IP.

Uso dos intervalos de IP

Estes intervalos de IP publicados podem ser usados por agentes em nuvem para:

• Clonar e fazer push para repositórios remotos (a menos que esteja usando o proxy de egress do Git)
• Baixar pacotes e dependências
• Fazer chamadas de API para serviços externos
• Acessar recursos da web durante a execução do agente

Se sua organização usa regras de firewall ou listas de permissão de IP para controlar o acesso à rede, talvez seja necessário incluir estes intervalos de IP na lista de permissão para garantir que os agentes em nuvem possam acessar seus serviços corretamente.

Considerações importantes:

• Fazemos alterações em nossos endereços IP periodicamente para atender às necessidades operacionais e de escalonamento.
• Não recomendamos usar listas de permissão por endereço IP como principal mecanismo de segurança.
• Se precisar usar estes intervalos de IP, recomendamos fortemente monitorar regularmente o endpoint da API JSON.

Proxy de saída do Git e lista de IPs permitidos

O Cherri Code oferece uma funcionalidade semelhante, mas distinta: usar um proxy de saída do Git para listas de IPs permitidos. Esse proxy direciona todo o tráfego do Git por um conjunto mais restrito de IPs e funciona com todos os hosts Git, incluindo GitHub, GitLab, Azure DevOps e Bitbucket.

Para hosts Git, recomendamos especificamente a configuração de lista de IPs permitidos descrita no link acima, pois ela se integra diretamente ao app do Cherri Code no GitHub.

Se precisar adicionar os IPs do proxy diretamente a uma lista de permissão, use estes endereços:

184.73.225.1343.209.66.1252.44.113.131

IPs do Origin

Se sua equipe usa agentes na nuvem junto com o Origin, adicione estes IPs à lista de permissão, além dos IPs do proxy de saída do Git mencionados acima:

34.192.39.18250.16.106.25544.217.29.1243.223.245.20154.164.185.1034.194.133.2335.170.116.221