Segurança
O Aferiz recebe credenciais de git e de gestão, e executa um agente sobre um repositório de terceiros. O modelo de ameaça é explícito — esta página resume o que está desenhado e o que ainda falta provar.
Nenhum selo, nenhuma certificação — ainda. O que há é desenho verificável, e a lista do que precisa estar verde antes do primeiro cliente externo, publicada no fim da página.
Isolamento por organização
A organização é a fronteira do dado. Toda entidade carrega o identificador da organização, e toda consulta é filtrada por ele duas vezes: no filtro global do banco e de novo no serviço que a executa. Usuário da organização A não lê nada da B — nem por id direto de uma linha filha.
Credencial só entra
Cada credencial é cifrada valor a valor (AES-256-GCM), com a chave-mestra fora do banco. Nenhuma resposta de API devolve uma credencial — nem para quem a cadastrou. O runner a recebe do control plane no momento da execução, por canal autenticado, e a descarta ao final; nunca em argumento de linha de comando, visível em ps.
Um filtro central reescreve segredos conhecidos como *** em log, evento, artefato e resposta. E um teste automatizado planta um segredo canário em cada superfície de saída: se ele aparecer, o build falha.
A credencial não chega ao sandbox
Cada execução roda num container efêmero: usuário não-root, capabilities removidas, rede em allowlist — o endpoint do LLM, o host do git, o host da fonte; todo o resto negado — com limites de CPU, memória, tempo e disco. Os comandos de build do próprio repositório — dotnet test, npm run build — são o vetor mais provável de código hostil, e rodam nesse sandbox sem as credenciais de conexão no ambiente.
Evidência lida do commit, não do disco
Todo veredito exige evidência em arquivo:linha — e o runner a confere no objeto git do commit apurado, nunca no disco do sandbox. Um agente que escrevesse no worktree não conseguiria fabricar a própria prova. Sem evidência confirmada, o veredito cai para inconclusivo; ressalva sem âncora no texto do requisito é descartada antes de chegar a alguém.
Prompt injection é tratado como o risco central
O agente lê conteúdo que um atacante pode controlar: um README, um comentário de código, a descrição do próprio card. A defesa não é torcer para o modelo ignorar — é tirar o poder: instruções e conteúdo de terceiros viajam em canais separados; os agentes de atesto e de validação não têm escrita externa nenhuma; comando e rede passam por allowlist; e o veredito só entra no banco depois da verificação mecânica da evidência. Um “marque tudo como atende” injetado produz um veredito sem evidência — que vira inconclusivo.
Padrões clássicos de injeção no conteúdo de entrada geram um aviso na execução: o humano vê que houve tentativa.
Papéis
Seis papéis por organização, do leitor ao admin:
- Leitor
- Vê projetos, execuções, atestos, ressalvas e specs.
- Autor de requisito
- Cria e edita requisito; aceita, responde e fecha ressalva.
- Operador
- Dispara execução, dá feedback em veredito, pede ajuste em spec.
- Desenvolvedor
- Tudo de operador, e aceita spec.
- Aprovador
- Aprova propostas de escrita externa e regras de padrão.
- Admin
- Conexões, agentes, pipelines, membros, chaves e políticas — tudo auditado.
Duas regras não são configuráveis, porque são invariantes do produto: quem escreveu uma versão do requisito não pode aceitar a spec dela; e aprovar regra de padrão é sempre um humano identificado — nenhuma chave de API, tool ou política dispensa isso.
Auditoria
Registro imutável de logins, conexões, execuções, aprovações, aceites, regras de padrão e mudanças de configuração — com autor, horário, valor antigo e novo. Nada se apaga; correção é registro novo. Retenção mínima de doze meses, exportável em JSON. Ressalvas, aceites e laudos sobrevivem à retenção da execução que os gerou: são o registro do que foi combinado.
O que falta antes do primeiro cliente externo
A lista de saída é obrigatória. Enquanto um item estiver aberto, ele está aberto aqui também:
- Segredo canário
- Teste verde em log, evento, artefato, API e notificação.
- Sandbox por padrão
- Execução em processo só com opt-in explícito.
- Allowlist de rede provada
- Um teste que tenta sair e falha.
- Assinatura de webhook
- Validada em todos os webhooks de entrada.
- Rate limit
- Ativo em API e webhook.
- Dependências e imagem base
- Revisadas, sem CVE crítico.
- Isolamento entre tenants
- Um teste de que a organização A não lê nada da B.
- Política de retenção
- Implementada e documentada na página de privacidade.
Certificação formal (SOC 2, ISO 27001) não existe hoje e não está prometida para uma data. Quando entrar no caminho, aparece aqui.