Segurança dos dados no Archyl Cloud: o que protegemos, como, e o que não afirmamos

Em algum lugar do seu questionário de fornecedores há uma linha que diz "Os dados do cliente são criptografados em repouso? Sim / Não". Para o Archyl Cloud, a resposta exata é "sim, e estes são exatamente os campos". O texto da sua arquitetura (nomes, descrições, ADRs, documentação) e as suas credenciais são criptografados pela nossa aplicação antes mesmo que o banco de dados os veja. Os arquivos enviados são criptografados pelo provedor de armazenamento. Identificadores, timestamps, posições nos diagramas e e-mails das contas ficam em claro, porque o banco de dados precisa indexá-los e fazer joins com eles. Um fornecedor que marca "Sim" sem dizer o que é o quê está pedindo que você aceite o resto do questionário na base da confiança.

Este post é a resposta longa. Ele cobre o que criptografamos e como, como os dados circulam, quem pode acessar o quê, o que nosso provedor de IA recebe, como testamos e o que você pode fazer com base no GDPR. Ele também diz claramente onde ainda não chegamos: o Archyl não possui hoje nenhuma certificação de segurança.

Tudo aqui é consistente com o Security Whitepaper (v3.0) e com o Acordo de Processamento de Dados (DPA), ambos atualizados em 27 de setembro de 2026 e ambos linkados a partir do Centro de Confiança. Se algum dia uma frase daqui e uma frase de lá discordarem, avise-nos, porque uma delas está errada.

A versão curta

Para quem está preenchendo um formulário agora mesmo:

O resto do post é o detalhe por trás de cada linha.

Criptografia em repouso, campo a campo

O Archyl criptografa os campos na aplicação, antes que eles sejam gravados no banco de dados. Todo modelo que contém conteúdo de clientes tem um hook de gravação que criptografa seus campos de texto com AES-256-GCM na entrada, e um hook correspondente que os descriptografa na saída. Cada criptografia usa um nonce aleatório novo, de modo que o mesmo valor armazenado duas vezes produz dois textos cifrados diferentes.

Isso cobre o seu conteúdo de arquitetura, não apenas os seus segredos:

• Modelo C4: systems, containers, components e elementos de código (nome, descrição, tags); relacionamentos (descrição, tags)
• Architecture Decision Records: título, contexto, decisão, consequências, tags
• Documentação: título, conteúdo, caminho do arquivo, tags; os comentários sobre ela
• Contratos de API: nome, descrição, conteúdo, endpoint, versão
• Flows e whiteboards: nomes, descrições, rótulos de tecnologia
• Também: overlays, canais de eventos, insights, releases, regras de conformidade, histórico de alterações e snapshots

E toda credencial e segredo que o Archyl armazena:

• Tokens OAuth do GitHub, GitLab e Bitbucket
• Chaves de API
• Segredos de MFA e códigos de recuperação
• Credenciais de integrações e do marketplace
• Tokens de acesso a repositórios
• Configurações de conexões com a nuvem

Isso está sempre ativo. A chave de criptografia é derivada com Argon2id a partir de um segredo configurado, e o servidor encerra na inicialização se esse segredo estiver ausente ou tiver menos de 32 caracteres. Não existe nenhuma configuração em que o Archyl rode e grave esses campos em texto puro.

A consequência prática: uma cópia do banco de dados, sozinha, mostra a forma dos seus dados, mas não as suas palavras. Os nomes dos seus serviços, o raciocínio dos seus ADRs, o corpo dos seus docs, o seu token do GitHub e o seu segredo de MFA também precisam da chave.

As credenciais também nunca voltam a sair pela API. As configurações de integração são ocultadas em toda leitura: depois que você cola uma chave no Archyl, a interface pode dizer que há uma chave armazenada, mas não pode mostrá-la de novo, e nenhuma chamada de API a devolve para mais ninguém na sua organização.

O que isso não cobre

Um banco de dados precisa conseguir encontrar, ordenar e fazer joins de linhas, e não consegue fazer isso sobre texto cifrado. Por isso alguns campos ficam em claro:

• Identificadores e os vínculos entre elementos. O banco de dados sabe que o elemento A pertence ao container B e tem um relacionamento com o elemento C. Ele não sabe como nenhum deles se chama.
• Timestamps e posições nos diagramas.
• Endereços de e-mail, nomes e sobrenomes das contas. O e-mail tem um índice único, para que duas contas não possam reivindicar o mesmo endereço.

Esses campos são protegidos pelos controles de acesso descritos mais adiante e por TLS em trânsito. Este post não afirma nada, nem num sentido nem no outro, sobre a criptografia em nível de disco do banco de dados.

Arquivos enviados

Os arquivos que você anexa à documentação (imagens, PDFs, outros documentos) não ficam no banco de dados. Eles são armazenados no Google Cloud Storage, e:

• Os buckets são privados. Nada neles pode ser lido ou listado publicamente.
• Os arquivos são criptografados em repouso com AES-256 pelo Google Cloud Storage, com chaves gerenciadas pelo provedor.
• Os arquivos só são servidos por meio de URLs assinadas de curta duração. Cada link dá acesso a um único arquivo e expira pouco depois de ser gerado, de modo que um link copiado para um ticket ou um chat deixa de funcionar em vez de virar uma URL pública permanente.
• A região padrão é a UE: Bélgica, europe-west1.

Criptografia em trânsito

O tráfego entre o seu navegador, as suas ferramentas e o Archyl Cloud usa TLS 1.3. A conexão da aplicação com o seu banco de dados PostgreSQL exige SSL, então a aplicação não se comunica com o banco de dados em texto puro.

Quem pode entrar

Pessoas

• A autenticação multifator usa TOTP, os códigos de seis dígitos de um app autenticador. Cada desafio de MFA só pode ser usado uma vez, e os códigos de recuperação são armazenados como hashes bcrypt, de modo que podem ser verificados, mas não lidos de volta.
• O single sign-on suporta SAML 2.0 e OpenID Connect. O login sempre começa no Archyl (somente SP-initiated), e o state que liga a resposta do seu provedor de identidade a essa requisição fica vinculado ao navegador que a iniciou e é válido uma única vez. Nosso post sobre SSO cobre a configuração.
• O login via OAuth está disponível com GitHub, GitLab e Bitbucket.
• Alterar a sua senha ou remover a MFA revoga todas as sessões anteriores. Se você acha que uma senha vazou, alterá-la desconecta todos os outros dispositivos que a estavam usando.
• A redefinição de senha não revela se uma conta existe, e um link de redefinição deixa de funcionar depois de usado.
• Login, MFA e redefinição de senha têm rate limiting, com limites em camadas para que um único IP, uma única conta ou um único desafio só possam ser tentados um número limitado de vezes.

Máquinas: chaves de API e agentes de IA

• As chaves de API são somente leitura por padrão. O acesso de escrita precisa ser concedido, e uma chave pode ser restrita a projetos específicos, de modo que uma chave entregue a um job de CI que só lê o modelo de um projeto pode fazer exatamente isso.
• O servidor MCP, que os agentes de IA usam para ler e atualizar a sua arquitetura, autentica com OAuth e PKCE obrigatório. Toda mutação exige um scope de escrita, de modo que um agente que você conectou para responder a perguntas sobre a sua arquitetura não pode alterá-la, a menos que você tenha concedido acesso de escrita.

Isolamento entre tenants

A falha contra a qual todo produto multi-tenant precisa ser projetado é simples de descrever: o servidor verifica que você está logado e pertence a alguma organização, e depois confia em qualquer identificador que esteja na requisição. Troque o ID na URL e você está lendo os dados de outra pessoa.

O Archyl autoriza cada requisição em relação ao recurso que ela acessa. Pedir um diagrama, um documento ou uma chave significa verificar que o projeto ou a organização dona daquele recurso específico é um ao qual você tem acesso, e não apenas que você está logado. A mesma regra vale para a API HTTP e para o servidor MCP.

Duas propriedades fazem isso se sustentar ao longo do tempo:

• A autorização falha de forma fechada (fail closed). Se não for possível determinar a quem pertence um recurso, a resposta é não.
• Testes automatizados de tenancy rodam no CI e fazem o build falhar se uma verificação de autorização for removida, em vez de esperar que alguém perceba.

O que a IA vê

Os recursos de IA do Archyl Cloud usam a OpenAI, e nenhum outro provedor de IA, a menos que a sua organização configure a própria chave.

Para a descoberta de arquitetura, que lê um repositório e propõe um modelo C4, enviamos assinaturas de código em vez de código-fonte. Aqui está um arquivo como ele está no seu repositório:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

E aqui está a seção que a descoberta monta a partir dele, que é o que entra no prompt:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

A regra de aprovação, o limite e o corpo de Finalize ficam de fora. O que entra: o nome do repositório, a estrutura de arquivos e diretórios, e essas assinaturas (imports, declarações de tipos e funções, constantes exportadas). Isso basta para deduzir que um component de faturamento conversa com a Stripe. Mas não é irrelevante: nomes de funções e tipos descrevem o seu sistema, então trate-os como dados que você está compartilhando.

Dois limites a essa afirmação, para que você não leia nela mais do que ela diz:

• Ela descreve como a descoberta trata o código-fonte. Se a descoberta encontrar no repositório Architecture Decision Records escritos em Markdown, ela envia o texto deles para transformá-los em decisões estruturadas, e envia as primeiras linhas dos arquivos de documentação para dar títulos a eles.
• Outros recursos de IA enviam o que a tarefa deles exige. Um agente de código, por exemplo, trabalha nos arquivos que está alterando, então ele os vê.

Se a sua política diz que o código só pode ir para um provedor com o qual você tem contrato, as organizações podem trazer a própria chave de IA. As requisições de IA passam então a ir para esse provedor, sob o seu contrato. Se absolutamente nada puder sair da sua rede, um Archyl self-hosted pode rodar modelos com Ollama no seu próprio hardware.

Como testamos

No pipeline

Nosso pipeline de CI executa quatro scanners de segurança:

• govulncheck para vulnerabilidades conhecidas nas dependências Go que realmente chamamos
• CodeQL para análise estática do nosso próprio código
• gitleaks para segredos commitados por engano
• Trivy para vulnerabilidades em imagens de containers e na configuração de infraestrutura

Na plataforma

• As requisições de saída são verificadas. Toda integração que chama uma URL fornecida por você (um servidor Git self-hosted, um webhook, um endpoint de IA) é protegida contra server-side request forgery, para que essa URL não possa ser usada para fazer o Archyl alcançar a sua própria rede interna.
• O navegador só executa os scripts que publicamos. Uma Content-Security-Policy estrita lista cada script inline pelo hash, e os scripts carregados de um CDN levam hashes de Subresource Integrity, de modo que uma cópia modificada é recusada.
• Os containers são blindados. Eles rodam como usuário não root, em um sistema de arquivos somente leitura, sem as capabilities do Linux.
• Os eventos de segurança são registrados, incluindo logins com falha, tentativas de MFA com falha e tokens rejeitados.

Testes de penetração

Entre julho e setembro de 2026, realizamos dez rodadas de testes de penetração internos. Cada achado foi corrigido e coberto por um teste de regressão, para que o mesmo problema seja detectado se voltar.

"Internos" significa exatamente isso: nós mesmos executamos esses testes, e nenhuma empresa independente participou. Um teste de penetração independente está planejado como parte da auditoria SOC 2.

Seus direitos com base no GDPR

• Exportação. Você pode exportar os seus dados em JSON.
• Exclusão. Excluir a sua conta exclui tudo o que pertence a ela, em cascata pelos seus dados e incluindo os anexos enviados ao armazenamento de objetos.
• Um DPA para cada cliente. O Acordo de Processamento de Dados está disponível para todos os clientes.
• Notificação de violações em até 72 horas.
• Aviso prévio de 30 dias antes de qualquer mudança nos nossos suboperadores, para que você possa se opor antes que a mudança aconteça.

Estes são os suboperadores hoje:

O DPA informa a localização e as salvaguardas legais de cada um.

O que ainda não afirmamos

Uma página de segurança que só lista pontos fortes deixa para você a tarefa de encontrar as lacunas. Aqui estão elas:

• Nenhuma certificação. O Archyl não é certificado SOC 2 e não é certificado ISO 27001. Para o SOC 2 Type I, a avaliação de prontidão (readiness assessment) está concluída e a auditoria independente está pendente. A ISO 27001 está planejada. Quando existir um relatório de auditoria, o Centro de Confiança dirá isso; até lá, nada do que publicamos deve dar a entender o contrário.
• Ainda não há teste de penetração independente. As dez rodadas descritas acima foram internas. O teste independente vem com a auditoria SOC 2.
• Nem toda coluna é criptografada. Identificadores, timestamps, posições nos diagramas, e-mails e nomes ficam em claro, como descrito acima.

Se o seu processo exige uma certificação que o Archyl ainda não tem, essa é uma restrição real, e preferimos que você saiba agora do que na sexta semana de uma revisão de compras.

Para onde ir agora

• O Centro de Confiança reúne os documentos em um só lugar.
• O Security Whitepaper se aprofunda em cada controle, incluindo os rate limits e os eventos de segurança que registramos.
• O Acordo de Processamento de Dados é a versão contratual da seção sobre o GDPR acima.
• Para dúvidas sobre proteção de dados, ou itens do questionário que este post não responde, escreva para privacy@archyl.com.
• Para relatar uma vulnerabilidade, escreva para security@archyl.com. Confirmamos o recebimento em até 24 horas.

Se você é a pessoa que precisa aprovar o Archyl, preferimos que você encontre uma resposta precisa para cada pergunta do que uma resposta confiante para a maioria delas. Onde algo aqui não for preciso o suficiente para a sua revisão, pergunte, e nós o tornaremos preciso.