Coroid realiza trabalhos de engenharia autônomos no seu código. Esta página aborda onde esse trabalho é executado, quais recursos ele pode acessar, como credenciais e dados são protegidos e quais registros são gerados. Descreve os controles atualmente em vigor. Os controles planejados são identificados como planejados.
Onde o trabalho dos agentes é executado
Cada tarefa é executada em sua própria área de trabalho em nuvem isolada. A área de trabalho é criada para aquela tarefa e desmontada após sua conclusão. Os agentes leem e gravam apenas o repositório que foi verificado nela.
Existem três zonas:
| Zona | Proprietário | O que ela contém |
|---|---|---|
| Área de trabalho do agente | Coroid | Ferramentas de verificação, compilação e teste de uma tarefa específica. Criadas por tarefa e desmontadas após sua conclusão. |
| Plano de controle | Coroid | Agendamento, especificações, evidências e o histórico de decisões. Armazena credenciais restritas ao projeto por meio de configuração criptografada. |
| Sua rede e produção | Você | Não é acessível a partir de uma área de trabalho do agente. |
- Área de trabalho do agenteGerenciado pelo CoroidFerramentas de checkout, compilação e teste de uma única tarefa.
- Plano de controleGerenciado pelo CoroidAgendamento, especificações, evidências e o histórico de decisões. As credenciais permanecem criptografadas.
- Sua rede e produçãoSeuNão é necessária nenhuma extensão IDE, agente local ou acesso à rede.
Um espaço de trabalho de agente não pode acessar sua rede ou produção.
A única saída é um pull request, que sua equipe decide se deve mesclar.
O trabalho sai da área de trabalho em um único formato: um pull request. Sua equipe decide se ele será mesclado, e seu próprio caminho de implantação o utiliza a partir daí. O Coroid não precisa de extensão IDE, nem de agente local, nem de acesso à sua rede privada.
Identidade e acesso
A autenticação é centralizada no gateway. Ele suporta:
- Sessões de usuário baseadas em JWT para acesso ao portal
- Tokens de serviço para serviço com rotação gerenciada
- Chaves API para integrações externas
- Proteções para endpoints de acesso de usuário, serviço e misto
O acesso ao repositório é restrito ao projeto. As credenciais de um projeto não podem ser utilizadas por outro projeto, e o Coroid não precisa de credenciais de toda a organização para trabalhar em um repositório específico. Veja Conecte seu código.
Proprietários e administradores da organização gerenciam membros, sessões e o feed de eventos de segurança em Configurações → Identidade e acesso. O SSO/SAML com provisionamento SCIM faz parte do plano Enterprise, que está em prévia privada.
Proteção de dados
- Os dados são criptografados em trânsito e em repouso.
- As credenciais da sua organização, como chaves de provedor, tokens de repositório e outros segredos de integração, são criptografadas com uma chave de dados própria da sua organização. Um serviço de gerenciamento de chaves criptografa essa chave de dados em seguida. Apenas o corretor de credenciais do Coroid pode descriptografá-las, e ele registra cada uso. Veja Chaves de provedor.
- Os próprios segredos de configuração do Coroid são armazenados criptografados.
- O serviço em nuvem público oferece um Perfil de hospedagem na UE para equipes com requisitos de GDPR ou de residência de dados. O Apenas na UE O perfil do AI mantém a inferência do modelo com provedores hospedados na UE. Veja Perfis do AI.
- Você controla por quanto tempo o histórico de execução, as transcrições e os artefatos são mantidos. Veja Retenção de dados.
O rastro de decisões
Cada alteração autônoma é explicada nos termos que revisores e equipes de Segurança já utilizam:
- a especificação, a atividade do agente, a Revisão e a decisão de aprovação permanecem vinculadas à tarefa
- o rastro de execução registra cada execução do agente, incluindo tentativas falhas e o motivo de sua falha
- O histórico de pull request mostra a evidência final antes da fusão do código
- Evidências de segurança, dependências, cobertura, testes visuais, de ponta a ponta e de navegador podem ser anexadas a uma Revisão. Veja Evidência de Revisão.
As portas de merge mantêm as alterações de produção sob políticas explícitas. Nada é mesclado sem a aprovação do seu portões de qualidade é necessário.
Operações de produção
- Geração de SBOM e varredura de imagens de contêiner em CI
- Endpoints públicos exclusivamente HTTPS com terminação TLS
- Snapshots automatizados de banco de dados e runbooks de restauração
- Monitoramento e alertas em métricas, logs e erros
Opções de implantação
Coroid opera em três modelos operacionais. O fluxo de trabalho é o mesmo em todos; o que muda é onde o tempo de execução, o armazenamento, o acesso ao repositório e as credenciais estão localizados.
| Modelo | Disponibilidade | Onde opera |
|---|---|---|
| Nuvem | Disponível para o público geral | Operado pelo Coroid, com um perfil de hospedagem opcional na UE |
| Nuvem corporativa | Visualização privada | Operado pelo Coroid, com capacidade contratada, SSO/SAML, SCIM e exportação de auditoria |
| Local | Visualização privada | Sua infraestrutura, com Docker Compose ou Kubernetes |
Local
As implantações on-premises permitem que equipes regulamentadas mantenham o acesso ao repositório, armazenamento, credenciais e políticas de rede dentro da infraestrutura que elas gerenciam.
- Docker Compose é indicado para instalações em um único servidor e projetos-piloto. Volumes persistentes armazenam o banco de dados, os repositórios e os logs.
- Kubernetes é adequado para instalações em múltiplos servidores e com escalonamento automático. O Helm gerencia os serviços de aplicação, trabalhadores, sincronização e execução, e funciona com PostgreSQL gerenciado ou auto-hospedado e armazenamento de objetos.
- Redes restritas podem utilizar estratégias de modelo e dependências offline, gerenciamento de segredos auto-hospedado e TLS interno.
O acesso ao Git usa tokens de acesso pessoal em vez de instalação de aplicativos de terceiros e pode apontar para hosts de repositório internos.
Certificações
Coroid atualmente não possui relatório SOC 2 ou outra certificação de segurança de terceiros. O SOC 2 é uma meta de preparação. Não descreveremos um controle como certificado até que ele o seja.