Visão geral da segurança
Esta página explica como os agentes na nuvem são desenvolvidos e protegidos. Ela mostra o que acontece quando um agente é executado, como o acesso é concedido, onde o código e os dados ficam, como são isolados e criptografados e quais controles você tem sobre cada etapa. Ela responde às perguntas que surgem quando uma equipe avalia os agentes na nuvem com base em seus requisitos de segurança.
Para a referência de configuração, incluindo tipos de segredo, modos de acesso à rede e faixas de IP de saída, consulte Segredos e rede. Para federar uma VM à AWS, GCP, Azure ou a um verificador personalizado sem chaves de longa duração, consulte tokens OIDC. Esta página explica o modelo por trás desses controles; aquelas páginas mostram como configurá-los.
Este é um complemento ao material mais amplo de segurança do Cherri Code. Consulte o Trust Center para informações sobre certificações, subprocessadores e arquitetura, e a referência Security and Privacy Hardening para os controles que estão sob sua responsabilidade em todo o Cherri Code. O Cherri Code está em conformidade com o SOC 2 Type 2 e se compromete a realizar testes de invasão pelo menos uma vez por ano por terceiros de boa reputação.
Como os Cloud Agents funcionam
Um Cloud Agent é um agente de programação executado em uma máquina virtual na nuvem do Cherri Code, em vez de no laptop de um desenvolvedor. A VM contém um ambiente de desenvolvimento completo: o repositório clonado, as dependências instaladas, os segredos configurados e o acesso à rede.
Uma execução passa por estas etapas:
- Início. Um usuário ou uma integração inicia uma tarefa pelo app web, IDE, CLI, API, Slack ou por uma issue ou pull request vinculada.
- Provisionamento. O Cherri Code provisiona uma VM isolada para esse agente e clona nela o repositório autorizado.
- Execução. O agente executa código e ferramentas dentro da VM e transmite ao usuário seu progresso, saída e artefatos.
- Persistência. O estado da conversa, os metadados e os artefatos são salvos em um armazenamento gerenciado pelo Cherri Code para que você possa revisar e retomar a execução.
- Transferência. O agente envia sua branch e abre uma pull request em rascunho para revisão humana antes de qualquer merge.
- Reciclagem. Os recursos de tempo de execução da VM são hibernados e depois excluídos por temporizadores do ciclo de vida quando a execução fica ociosa.
Acesso e autorização
Cloud Agents acessam seu código pelo app do Cherri Code no GitHub ou GitLab, não pelas credenciais de uma única pessoa.
- Admins instalam o app. Habilitar Cloud Agents exige privilégios de admin tanto no Cherri Code quanto no seu provedor de Git. Um admin instala o app Cherri Code na sua organização do Git e concede acesso apenas aos repositórios que você escolher.
- Usuários conectam a própria conta. Depois que o app é instalado, cada usuário que quiser iniciar um agente conecta a própria conta do Git. Essa é uma segunda camada por usuário, além da instalação no nível da organização.
- O acesso é herdado, nunca ampliado. Um Cloud Agent só pode acessar repositórios aos quais o usuário que o acionou já tinha acesso. Iniciar um agente nunca concede acesso a um repositório ao qual o usuário ainda não tinha acesso.
Admins da equipe podem ir além e vincular uma organização do Git à sua organização do Cherri Code com Escopos Git protegidos, para que apenas suas equipes possam iniciar Cloud Agents nos repositórios dela. Você também pode manter repositórios sensíveis totalmente de fora com uma lista de bloqueio de repositórios.
Funcionários da Cherri Code não têm acesso ao código dentro das VMs dos Cloud Agents. As tentativas de acesso são monitoradas pela equipe de segurança da Cherri Code.
Isolamento e infraestrutura
Cada agente roda em sua própria VM, não em um sandbox de processo compartilhado. Um agente não pode ver o código, o ambiente nem o estado de outro agente.
- VMs por agente. Cada agente recebe um ambiente dedicado, isolado de outros agentes e de outros usuários.
- Isolamento por microVM. Os espaços de trabalho de tempo de execução rodam em uma infraestrutura de microVM baseada no Firecracker.
- Separação no nível da conta. As VMs do Cloud Agent rodam em uma conta AWS separada do restante da infraestrutura de produção do Cherri Code, de modo que o ambiente de execução de código fique isolado dos outros serviços do Cherri Code.
Criptografia
O Cherri Code criptografa os dados do Cloud Agent em trânsito e em repouso.
- Em trânsito. TLS 1.2 ou superior para tráfego entre serviços e entre cliente e serviço.
- Em repouso. AES-256, com uma chave por agente, para que os dados de sessão de cada agente sejam criptografados com sua própria chave.
- Chaves gerenciadas pelo cliente. Equipes corporativas podem associar uma chave KMS gerenciada pelo cliente (CMEK/BYOK) à criptografia do lado do servidor no Cloud Agent, para que você controle a rotação e o acesso às chaves. Consulte Criptografia de dados.
Quais dados são armazenados, onde e por quanto tempo
Um Cloud Agent envolve quatro tipos de dados. Cada um é armazenado em um local diferente e segue sua própria regra de retenção.
| Dados | O que contém | Onde fica | Retenção |
|---|---|---|---|
| Espaço de trabalho em tempo de execução | O repositório em checkout, artefatos de build e o contexto de execução das ferramentas de uma execução em andamento | A VM isolada do Cloud Agent | Reciclado automaticamente depois que a execução fica inativa; o temporizador é renovado quando você envia mensagens de acompanhamento |
| VM snapshots | Cópias do disco da VM em um determinado momento (incluindo código clonado), usadas para iniciar e retomar sem clonar novamente | Camada de snapshots e cache fora da VM ativa, criptografada | Janela móvel de 90 dias de inatividade; cada início ou retomada estende esse prazo, seguido de exclusão automática |
| Estado da conversa | Prompts, respostas do modelo, chamadas de ferramenta, contexto de diff e artefatos de demonstração que compõem a transcrição | Backend do Cherri Code, criptografado com chaves por agente | Mantido indefinidamente por padrão para que você possa revisitar e retomar execuções; pode ser excluído sob demanda |
| Segredos e tokens | Segredos do Cloud Agent, tokens OAuth e credenciais de API que você configurar | Cofres de credenciais criptografados no backend do Cherri Code | Mantidos até que você os exclua ou remova |
A Delete Agent API remove, sob demanda, a transcrição da conversa e os artefatos de um agente. Snapshots não podem ser excluídos sob demanda; eles seguem a janela de 90 dias de inatividade acima. Equipes corporativas também podem limitar a retenção de conversas com políticas de retenção. Para ver todos os detalhes sobre retenção e exclusão, consulte Retenção de dados.
Privacidade e dados do modelo
Os agentes em nuvem são executados em Privacy Mode. Com o Privacy Mode ativado, o Cherri Code nunca treina com o código acessado pelos agentes em nuvem nem com os prompts e respostas gerados durante suas execuções. A maioria dos modelos também é executada sob os acordos de retenção zero de dados do Cherri Code, então os provedores não armazenam nem usam solicitações e respostas para treinamento. Consulte Privacidade e dados para ver os detalhes de cada modelo e as exceções.
O Privacy Mode legado não é compatível com agentes em nuvem, porque os agentes precisam armazenar código e dados de ambiente na nuvem durante a execução. Aplique o Privacy Mode padrão em toda a organização para que todas as execuções herdem suas garantias de retenção zero de dados.
Autonomia e injeção de prompt
Agentes em nuvem executam comandos de terminal automaticamente para iterar em testes sem precisar parar para pedir aprovação a cada etapa. Isso é mais autônomo do que o agente em primeiro plano e muda o modelo de risco: um invasor que plante instruções no conteúdo que o agente lê (um ataque de injeção de prompt) pode tentar fazer o agente exfiltrar código para um host externo. Veja a explicação da OpenAI sobre o risco de injeção de prompt para agentes em nuvem.
As camadas que mitigam esse risco:
- Controles de saída de rede. Restrinja o tráfego de saída a um conjunto padrão mais sua lista de permissão, ou a Allowlist only, para que um agente comprometido não tenha para onde enviar dados. Administradores corporativos podem bloquear essa política em toda a organização. Veja Acesso à rede.
- Runtime Secrets ocultados. Marque segredos como Runtime Secrets para que seus valores sejam removidos da transcrição, da saída da ferramenta e dos commits, sem nunca chegar ao modelo.
- Exclusão de arquivos. Adicione caminhos sensíveis a
.cursorignorepara mantê-los fora do contexto do agente. - Transferência para revisão humana. Agentes abrem pull requests em rascunho. Nada é mesclado até que uma pessoa revise a alteração.
- Commits assinados. Todo commit do agente é assinado com uma chave Ed25519 com suporte de HSM e exibe o selo "Verified", para que alterações feitas pelo agente sejam atribuíveis e possam atender à proteção de branch com commits assinados. Veja Commits assinados.
Para uma defesa mais profunda, combine isso com hooks para aplicar políticas e registrar atividades em pontos do lifecycle do agente, e faça com que Bugbot ou Agentes de Segurança revisem a saída do agente antes de ela ir para produção.
Considerações de risco
| Risco | Mitigação |
|---|---|
| Base de código completa na nuvem | VMs isoladas por agente, criptografia AES-256 e exclusão automática de VMs e snapshots com temporizadores do ciclo de vida. |
| Acesso de terceiros ou interno | Nenhum funcionário da Cherri Code tem acesso ao código nas VMs dos agentes, e as tentativas de acesso são monitoradas. As VMs rodam em uma conta AWS separada dos outros serviços da Cherri Code. |
| Autonomia do agente | Escopo restrito ao repositório e ao acesso do usuário que acionou a execução. O acesso externo se limita a ferramentas configuradas e comandos de terminal, sujeitos a controles de saída de rede e revisados por PRs em rascunho. |
| Acesso à rede e exfiltração | O acesso à internet fica ativado por padrão, mas pode ser restrito a domínios da lista de permissão, até o modo somente lista de permissão, e bloqueado em toda a organização. |
| Exposição de segredos | Armazenamento criptografado de segredos, segredos de tempo de execução ocultados e mantidos fora do modelo, e segredos apenas de build com escopo limitado ao build do Docker, e tokens OIDC para federação na nuvem de curta duração. |
Auditabilidade
A atividade do agente em nuvem é registrada em logs e pode ser atribuída.
- Registro de sessões. As execuções são registradas em logs, e os admins da equipe podem revisar a atividade no dashboard do Cloud Agents.
- Alterações atribuídas. Todo commit e pull request criado por um agente fica atribuído e visível no seu histórico do Git, com commits assinados e verificados.
- Logs de auditoria. Eventos de autenticação e administrativos vão para seus logs de auditoria, que equipes corporativas podem encaminhar para um SIEM, webhook ou S3.
- Run Diagnostics. O Cherri Code Cloud MCP integrado expõe transcrições, eventos da execução, detalhes do ambiente e logs de configuração de uma execução.
Exclusão de dados
| Mecanismo | O que remove | Como |
|---|---|---|
| Arquivar | Oculta um agente do dashboard | Arquive pelo dashboard |
| Delete Agent API | A transcrição da conversa e os artefatos de um agente | Delete Agent API |
| Expiração de snapshots | Snapshots da VM e código em cache | Automática após 90 dias de inatividade |
| Política de retenção (Corporativo) | Conversas mais antigas do que o período escolhido | Políticas de retenção |
| Exclusão da conta | A conta e seus dados associados | Excluir conta |
FAQ
Eles têm um perfil de risco diferente, não pior. Executar um agente sem supervisão em um sandbox isolado, com restrições de saída e permissões mínimas, pode ser mais seguro do que no laptop de um desenvolvedor, que normalmente tem acesso irrestrito à internet e privilégios elevados.
Não. O Cherri Code clona o repositório para executar o agente, e esse clone pode permanecer em snapshots de VM para acelerar futuras inicializações, mas não é mantido indefinidamente. Os snapshots são excluídos após 90 dias de inatividade.
Não. O acesso é controlado pelo acesso Git do desenvolvedor que disparou a execução. Um agente na nuvem não pode acessar um repositório ao qual o desenvolvedor já não tenha acesso.
Sim. Os agentes na nuvem só podem acessar repositórios que você autorizar por meio da conexão com seu provedor de Git. Você controla quais repositórios ficam disponíveis, e admins podem bloquear escopos com Escopos Git protegidos ou excluir repositórios com uma blocklist.
Configure os segredos pela aba Secrets no seu dashboard. Eles são criptografados em repouso com KMS, criptografados em trânsito e injetados como variáveis de ambiente em tempo de execução. Marque valores sensíveis como Runtime Secrets para mantê-los fora da transcrição, da saída das ferramentas e dos commits. Como prática, mantenha segredos fora do repositório; se arquivos sensíveis precisarem ficar lá, adicione-os ao .cursorignore. Para funções na nuvem, gere tokens OIDC na VM em vez de armazenar chaves de acesso de longa duração.
Sim. As sessões ficam registradas em log, admins podem revisar a atividade no dashboard, e todo commit e pull request que um agente cria é atribuído no seu histórico Git. Equipes corporativas podem transmitir logs de auditoria para um SIEM.
Arquive um agente no dashboard ou use a Delete Agent API para remover sua transcrição e artefatos. A exclusão completa da conta e as políticas corporativas de retenção removem dados em um cronograma mais amplo.
Páginas relacionadas
- Segredos e rede para tipos de segredo, modos de acesso à rede, faixas de IP de saída e commits assinados.
- Tokens OIDC para JWTs de curta duração e federação na nuvem.
- Privacidade e dados para fluxos de dados, Privacy Mode e criptografia.
- Security and Privacy Hardening para os controles que você configura no Cherri Code.
- Trust Center para certificações, subprocessadores e arquitetura.