Como o Rationale protege o que sua equipe decide

Dois tipos de dados, mantidos separados

O Rationale separa o que precisa para operar o serviço do que sua equipe escreve. O primeiro tipo (identificadores, estados, âncoras, marcas de tempo, nomes de repositórios, branches e arquivos, handles de tarefas) pode ser lido pelo servidor, porque o roteamento, os avisos e a auditoria precisam dele. O segundo tipo é criptografado no banco de dados com chaves guardadas no ambiente do deploy, nunca no banco nem no repositório: o texto das decisões (pergunta, escolha, critérios, opções descartadas, premissas, condições de revisão e citações), notas, tarefas, repasses, resumos, digests e títulos de sessão; títulos, descrições e threads de revisão de pull requests; tokens de conectores; e os nomes, nomes de usuário, endereços de e-mail e fotos que o Jira e o GitHub fornecem sobre as pessoas.

O conteúdo do segundo tipo nunca passa para colunas, logs, eventos ou mensagens de erro do primeiro. Os logs de requisições filtram o texto das decisões e as credenciais, e os eventos de auditoria carregam apenas ids, números e estados. O conteúdo das decisões é somente de acréscimo: uma edição adiciona uma versão e não sobrescreve nada.

O que fica nas suas máquinas

• Transcrições. O cliente extrai as decisões na máquina da pessoa, com o agente que ela já usa. Recebemos as decisões, citações curtas das próprias palavras da pessoa e metadados (id da sessão, números de turno, repositório, branch, commit, hora, custo equivalente). A transcrição em si não vai a lugar nenhum além do provedor do próprio agente, como sempre foi.
• Repositórios. Nunca os clonamos e não guardamos arquivos. Uma decisão é ancorada a caminhos; quando uma decisão cita uma classe, uma tabela ou a chave de um ticket, a comparação com o conteúdo de um arquivo acontece na máquina, sobre no máximo 512 KB de texto, e esse conteúdo nunca sai dela.
• Caminhos de arquivos. Quando seu agente lê ou edita um arquivo, o hook compara o caminho com um índice local de decisões ancoradas e só consulta o servidor se houver correspondência. Um caminho ao qual nenhuma decisão está ancorada nunca sai da máquina.
• Segredos. O valor de um segredo nunca entra em uma decisão, uma nota ou um repasse: é recusado no que pessoas e agentes escrevem e removido do texto capturado e das citações. A varredura procura chaves privadas, chaves de nuvem e de API, tokens do GitHub, GitLab, Slack e Stripe, JWTs, senhas dentro de URLs e valores escritos depois de palavras como password ou token; o servidor registra apenas o tipo de segredo recusado, nunca o valor. Hosts, URLs e onde um segredo mora (um caminho de vault, o nome de uma variável de ambiente) são bem-vindos.

Em trânsito

• Toda conexão com o Rationale usa HTTPS, com certificados da Let's Encrypt e HTTP Strict Transport Security incluindo subdomínios; HTTP sem criptografia é redirecionado.
• O cliente verifica TLS com o repositório de certificados da sua plataforma, então um proxy corporativo com seu próprio certificado raiz funciona sem enfraquecer nada.
• Entregas de webhooks do GitHub e do Jira só são aceitas com uma assinatura válida do provedor.
• Os e-mails que enviamos saem por uma conexão criptografada até nosso provedor de e-mail.
• Este site não define cookies, não carrega scripts de terceiros e envia uma Content-Security-Policy que permite apenas seus próprios scripts, por hash. O app define apenas o cookie assinado que mantém você conectado; nenhum dos dois carrega rastreadores.

Login

• Sem senhas. O Rationale não guarda nenhuma. As pessoas entram com um link enviado ao seu e-mail, que funciona uma vez, por 15 minutos; o token viaja depois do # do endereço, que os navegadores nunca enviam a um servidor, então nunca chega aos nossos logs nem ao proxy de ninguém. Uma sessão de navegador dura 30 dias.
• Dispositivos. rationale init faz o login de uma máquina com um código de dispositivo: o cliente mostra um código de oito letras, você o digita no app já conectado, escolhe o workspace e permite ou nega. Os códigos expiram em 10 minutos e são guardados como digests. O token do dispositivo é entregue uma vez, guardado como digest SHA-256, limitado a um workspace, para de funcionar após 90 dias sem uso e pode ser revogado a qualquer momento na página Devices; remover um membro revoga os dele.
• Clientes MCP. Claude, ChatGPT, Cursor e qualquer cliente MCP se conectam com OAuth 2.1: registro dinâmico de clientes, apenas clientes públicos, PKCE com S256 obrigatório, endereços de redirecionamento em HTTPS ou loopback. Códigos de autorização duram 5 minutos e são de uso único, tokens de acesso duram uma hora, tokens de atualização rotacionam a cada uso e duram 90 dias. Na página de consentimento você escolhe quais workspaces o cliente pode alcançar; sua participação é verificada de novo em cada requisição, e a conexão é revogada na mesma página Devices.
• Sem chaves de API para pessoas. Não existe chave pessoal para colar em um arquivo de configuração ou vazar em um repositório. As únicas credenciais são o token de um dispositivo e os tokens de uma conexão MCP, cada um revogável por si.
• Conectores. Jira e GitHub são conectados por OAuth com a conta de cada membro, nunca com um token compartilhado ou uma senha. A ida e volta usa um state aleatório de uso único, que dura 10 minutos e está vinculado à sessão de navegador que o iniciou.
• Limites de taxa. Links de login, códigos de dispositivo, os endpoints de OAuth e MCP e o script de instalação têm limite de taxa por endereço ou por token.

Quem pode ver o quê

• Workspaces. Todo registro pertence a um workspace e só é acessado por meio dele: um workspace do qual você não faz parte é indistinguível de um que não existe. Os proprietários gerenciam os membros, os conectores e o log de auditoria.
• Sua própria visão do Jira e do GitHub. Os conectores usam OAuth com a conta de cada membro, nunca um token compartilhado, então cada pessoa vê no Rationale apenas os tickets, projetos, repositórios e pull requests que a própria conta pode ver.
• Registros privados. Uma decisão, um repasse, uma tarefa criada no Rationale ou uma sessão inteira pode ser privada: visível para a sua pessoa e os próprios agentes dela, nunca para a equipe, proprietários incluídos. A pessoa decide, com um clique ou com as próprias palavras por meio do agente; um agente nunca muda a visibilidade por conta própria.
• Agentes agem como eles mesmos. Um agente trabalha pelo dispositivo ou pela conexão MCP de um membro, identificado como agente, em nome desse membro. Ele nunca vê mais do que a pessoa para quem trabalha.

O que nossa equipe pode e não pode ver

A equipe do Rationale usa um painel administrativo em seu próprio host, aberto por um link de e-mail exclusivo da equipe em uma sessão de 8 horas atrás de um cookie restrito a esse host; uma sessão de membro nunca o abre. Ele mostra a maquinaria de cada cliente em números: capturas, falhas, dispositivos, jobs, métricas.

• Não consegue descriptografar. Cada requisição ao painel roda com um provedor de chaves que não tem chaves, então ler qualquer atributo criptografado gera um erro em vez de exibi-lo. Um teste percorre todas as páginas do painel com conteúdo sentinela e falha se esse conteúdo aparecer, em claro ou criptografado.
• Cada olhada fica no seu log. Cada página do painel que mostra dados de um workspace escreve um evento staff.viewed no log de auditoria desse workspace, onde os proprietários o leem no filtro Staff.
• Sem entrar como outra pessoa. A equipe não tem como abrir seu workspace como você. Nenhuma página, API ou ferramenta MCP pode conceder a marca de equipe: ela só muda a partir do console de produção auditado.
• Consoles são registrados. Um console de produção pode ler conteúdo, então abrir um escreve um evento ops.console_opened com o operador antes de aceitar qualquer entrada; se o evento não puder ser escrito, o console não abre. Abrimos um apenas para um suporte que você pediu, uma solicitação de privacidade ou um incidente.
• As ferramentas de privacidade também são auditadas. Exportar ou apagar uma pessoa, exportar ou excluir um workspace passa por ferramentas auditadas que escrevem seus próprios eventos, sem conteúdo; a exportação de um workspace é enviada apenas a um de seus proprietários.

Cada leitura fica registrada

Cada criação, leitura e confirmação de uma decisão escreve um evento de auditoria: uma decisão aberta, uma lista ou busca exibida, contexto entregue a um agente, um aviso mostrado. Os eventos carregam ids, números e estados, nunca conteúdo, e são somente de acréscimo. Os proprietários leem o log do seu workspace em Configurações, com a atividade de membros, agentes e equipe, o canal (web, cliente, MCP) e o endereço IP, filtrado por mudanças, leituras ou acessos da equipe.

A procedência é explícita em cada registro: observado, derivado, inferido por um agente ou confirmado por uma pessoa. Um registro só passa a confirmado por uma ação humana: um clique no app, as próprias palavras da pessoa em uma sessão (o cliente as verifica contra a transcrição antes de enviar e descarta qualquer coisa que um agente tenha escrito sobre alguém confirmar), ou o merge no GitHub do pull request que carregou a decisão em sua branch. Um agente dizer que alguém confirmou não é uma confirmação.

O cliente

• Um binário, sem runtime. Ele se instala no seu diretório pessoal sem sudo e nunca edita os arquivos do seu shell. A primeira instalação confia no TLS até o host dos arquivos, como todo curl | sh; cada atualização seguinte é verificada pelo próprio cliente contra um manifesto assinado.
• Cada versão é assinada com minisign. Duas chaves públicas vêm compiladas em cada binário: a chave de release, que assina cada manifesto, e uma chave de reserva offline usada só para rotacionar a primeira; as chaves secretas nunca vão para um repositório nem para um servidor. Uma atualização que nenhuma das duas assinou, um manifesto reproduzido ou um downgrade são recusados; o tamanho e o SHA-256 de cada arquivo são verificados; um binário novo que falha no autoteste é revertido, e rationale update --rollback devolve a versão anterior quando você pedir.
• Sua configuração só pode ser lida pelo seu usuário (modo 600). Os hooks nunca bloqueiam seu agente: cada um faz no máximo uma requisição curta, de até dois segundos, e o que falha termina em silêncio.
• rationale uninstall remove os hooks e o watcher; revogar o dispositivo no app invalida o token dele.

Onde o serviço roda

Um servidor e um banco de dados PostgreSQL gerenciado na DigitalOcean, acessado pela rede privada, com backups diários e sete dias de recuperação pontual no tempo. O firewall permite apenas SSH, HTTP e HTTPS; o SSH é só por chave; as atualizações de segurança são instaladas automaticamente. Os segredos chegam ao servidor como variáveis de ambiente no deploy, legíveis apenas pelo root, nunca no repositório nem no banco. Toda mudança passa pelos testes, Brakeman, bundler-audit e importmap audit no CI antes do merge. Nossas contas nos provedores usam autenticação de dois fatores.

Estamos estabelecidos em Portugal, então as transferências para os Estados Unidos são feitas sob o RGPD: a certificação da DigitalOcean no EU-U.S. Data Privacy Framework (com suas extensões para o Reino Unido e a Suíça) e as Cláusulas Contratuais Padrão do seu acordo de processamento de dados; as Cláusulas Contratuais Padrão e o Data Privacy Framework para a Resend. Cada provedor está sob um acordo escrito de processamento de dados. A política de privacidade mantém a lista oficial.

Por quanto tempo guardamos os dados

O conteúdo do workspace (decisões, tarefas, notas, repasses) fica enquanto o workspace existir e é excluído em até 30 dias após o pedido de um proprietário ou 90 dias após o fim do serviço; os backups expiram em sete dias. Os dados pessoais têm prazos publicados, aplicados por um job diário:

A política de privacidade é a lista oficial. Os proprietários podem pedir uma exportação do workspace inteiro (descriptografada, enviada apenas a um proprietário) ou sua exclusão; uma pessoa pode pedir a própria exportação ou o próprio apagamento em privacy@rationalehq.com.

Se algo der errado

Mantemos um plano escrito de resposta a incidentes, de responsabilidade do gerente da empresa. Ele cobre um segredo ou token vazado, um laptop ou uma conta de provedor roubados, acesso não autorizado, dados enviados à pessoa errada, dados perdidos ou corrompidos e uma vulnerabilidade explorada. Na dúvida, tratamos um evento como incidente e o escrevemos no registro.

1. Conter, na primeira hora: rotacionar o que vazou, revogar dispositivos e conexões, desligar um conector, bloquear um endereço, tirar um servidor do ar se preciso; copiar os logs antes que rotacionem.
2. Escrever no registro de violações, com horários em UTC, só fatos, guardado por pelo menos cinco anos.
3. Avaliar quais dados, de quem, e se estavam criptografados: o conteúdo das decisões é criptografado com chaves fora do banco de dados, então uma cópia do banco sem as chaves expõe apenas identificadores e estados.
4. Notificar: os proprietários de cada workspace afetado em 48 horas, por e-mail, com o que aconteceu, quais dados, o que fizemos e o que devem fazer; a autoridade portuguesa de proteção de dados em 72 horas quando o RGPD exigir, e as pessoas afetadas sem demora indevida quando o risco para elas for alto; a Atlassian em 48 horas quando o conector do Jira estiver envolvido; os residentes nos EUA conforme a lei do seu estado.
5. Recuperar a partir dos backups (sete dias de recuperação pontual no tempo), fazer o deploy de novo, verificar.
6. Aprender: causa raiz, correção, atualizar o plano e o registro das atividades de tratamento.

O registro não tem entradas na data desta página. O plano prevê um exercício pelo menos uma vez por ano, anotado no registro.

Conformidade e certificações

O Rationale é um serviço de uma empresa portuguesa e opera sob o RGPD para todo mundo, onde quer que esteja. A política de privacidade nomeia cada provedor, cada finalidade e cada prazo de retenção. Os termos incluem Termos de Processamento de Dados, com notificação de um incidente de segurança que afete dados pessoais sem demora indevida e em até 48 horas, e Termos de Privacidade para os Estados dos EUA. Não vendemos dados pessoais, não exibimos publicidade, não usamos análise de terceiros e não treinamos modelos de IA com seu conteúdo.

Certificações: nenhuma ainda. Não temos certificação SOC 2 nem ISO 27001, e nenhuma auditoria está em andamento. O SOC 2 está planejado para quando o Rationale tiver a tração que o justifique; esta página dirá quando uma auditoria começar e quando houver um relatório disponível. Até então, esta página, a política de privacidade e os termos são a evidência, e respondemos a questionários de segurança sob demanda em security@rationalehq.com.

O que ainda falta

Dito com clareza, para você não precisar perguntar:

• SOC 2 e ISO 27001. Sem relatório e sem auditoria em andamento. Planejado com tração.
• SSO com SAML e provisionamento SCIM. Não construídos. Pertencem ao plano Business, que não é vendido até que existam. Hoje cada membro entra com um link por e-mail, e os proprietários adicionam e removem membros à mão.
• Exportação do log de auditoria. Os proprietários leem o log em Configurações; ainda não há download. Planejado para o plano Business.
• Um segundo fator nosso. O login é por link de e-mail, então a proteção da sua caixa de entrada é a da sua conta; o Rationale não adiciona um segundo fator próprio.
• Notarização da Apple do binário para macOS. As versões são assinadas com minisign e verificadas pelo próprio cliente, mas ainda não notarizadas pela Apple; instale com o comando ou com o Homebrew em vez de um download pelo navegador.
• Windows. O cliente roda em macOS e Linux; no Windows o instalador avisa e para.
• Hospedagem fora dos Estados Unidos. Os dados ficam nos Estados Unidos sob os mecanismos de transferência acima; ainda não há uma região na UE.

Reportar uma vulnerabilidade

Escreva para security@rationalehq.com. Confirmamos o recebimento em um dia útil, mantemos você informado enquanto corrigimos e não tomamos medidas contra pesquisas de boa-fé que respeitem os dados de outros clientes. Nosso security.txt diz o mesmo, em formato legível por máquina.

• Inclua o host, os passos para reproduzir e o que você observou.
• Não acesse, altere nem guarde dados que não sejam seus; pare assim que o problema estiver demonstrado.
• Dê a nós um tempo razoável para corrigir antes de tornar público.