Skip to main content
O ChatCLI implementa uma arquitetura de segurança em profundidade (defense-in-depth) com mais de 30 controles de segurança distribuídos em todas as camadas da aplicação — da autenticação e criptografia até a prevenção de injeção, hardening de infraestrutura e auditoria estruturada.
Todas as proteções listadas nesta página estão ativas por padrão. A filosofia do ChatCLI é secure-by-default: você não precisa configurar nada para obter um nível elevado de segurança.

Visão Geral das Proteções


Autenticação e Autorização

O ChatCLI suporta dois modelos de autenticação: JWT (recomendado para produção) e Bearer Token legado (para desenvolvimento e compatibilidade).

Autenticação JWT

O JWT (JSON Web Token) fornece autenticação stateless com claims estruturados. O ChatCLI valida iss (issuer), aud (audience), exp (expiração) e o claim customizado role para autorização.

RBAC — Controle de Acesso Baseado em Roles

O claim role no JWT determina as permissões do usuário. O sistema segue o princípio do menor privilégio.
O role readonly não pode enviar mensagens nem executar comandos. Ideal para dashboards de monitoramento e integrações que apenas consomem dados.

Rate Limiting de Autenticação

Tentativas de autenticação falhadas são limitadas a 5 por minuto por IP. Após exceder o limite, o IP recebe 429 Too Many Requests com backoff progressivo.

OAuth PKCE + Device Flow

Para autenticação com provedores externos (Anthropic, GitHub, Google), o ChatCLI implementa:
  • PKCE (Proof Key for Code Exchange): Previne interceptação do authorization code
  • Device Flow: Para ambientes sem browser (SSH, containers, CI/CD)
Veja a documentação completa de OAuth em Autenticação OAuth.

Criptografia e Proteção de Dados

AES-256-GCM para Credenciais

Todas as credenciais OAuth e tokens são armazenados com criptografia AES-256-GCM (Galois/Counter Mode), que fornece tanto confidencialidade quanto autenticidade dos dados.

Criptografia de Sessão em Repouso

Os dados de sessão são criptografados antes de gravar em disco usando uma chave derivada via HKDF (HMAC-based Key Derivation Function) a partir da chave mestre.

TLS 1.3 para gRPC

Em produção, o servidor gRPC exige TLS 1.3 com cipher suites fortes.
Se o carregamento do certificado TLS falhar, o erro é escrito em stderr e no log estruturado, incluindo os caminhos do certificado e da chave. Em containers, isso garante que o erro seja visível via kubectl logs mesmo que o logger estruturado não consiga fazer flush antes do crash.
Quando TLS não está configurado, o servidor emite um log de warning a cada startup. O comportamento funcional não muda, mas a comunicação trafega em texto plano.

Redação de Variáveis de Ambiente

O ChatCLI detecta e redacta automaticamente variáveis de ambiente sensíveis antes de exibir ou enviar ao LLM.
Exemplo de saída:

Redação do Histórico de Conversas

O histórico de conversas passa por redação automática antes de ser persistido. Padrões detectados incluem:
  • API keys (formato sk-..., pk_..., ghp_...)
  • Tokens JWT (formato eyJ...)
  • Connection strings com credenciais
  • IPs privados em contextos sensíveis
  • Números de cartão de crédito (Luhn validation)

Integração com OS Keychain

Quando disponível, o ChatCLI armazena a chave mestre no keychain do sistema operacional em vez do arquivo .auth-key.
A integração com keychain é automática quando o backend está disponível. Use CHATCLI_DISABLE_KEYCHAIN=true para forçar o armazenamento em arquivo.

Segurança do Modo Agente

O modo agente permite que a IA execute comandos no seu sistema. O ChatCLI implementa múltiplas camadas de proteção para garantir que apenas operações seguras sejam executadas.

Allowlist de Comandos

O sistema mantém uma allowlist com 150+ comandos organizados em 8 categorias. Apenas comandos nesta lista são permitidos sem confirmação do usuário.
Operações destrutivas como git push --force, git reset --hard e git clean -f nunca estão na allowlist.
Comandos de rede que podem modificar configurações (iptables, route add, ip link set) são bloqueados.

Modo Strict vs Permissive

  • Apenas comandos da allowlist executam sem confirmação
  • Qualquer comando fora da lista requer aprovação explícita do usuário
  • Recomendado para produção e ambientes compartilhados

Bloqueio de Caminhos Sensíveis

O agente não pode ler arquivos em caminhos considerados sensíveis, independentemente da allowlist:
Tentativas de leitura desses caminhos são silenciosamente bloqueadas e registradas no audit log. A IA recebe uma mensagem genérica informando que o arquivo não está acessível.

Shell Config Sourcing

Por padrão, o agente não carrega arquivos de configuração do shell (.bashrc, .zshrc). Isso previne execução de código arbitrário que possa existir nesses arquivos.

Input guard — proteção contra typeahead em prompts de segurança

Quando uma security box aparece (modo coder/agent), três camadas defendem contra digitação acidental ser consumida como resposta y/n:
  1. Flush kernel TTYTCIFLUSH (Linux) / TIOCFLUSH (BSD/Darwin) / FlushConsoleInputBuffer (Windows) descarta bytes na fila do kernel antes de renderizar a box.
  2. Drain channel — esvazia o canal centralizado de stdin não-bloqueante (buffer de 10 linhas que o reader goroutine usa).
  3. Intent debounce — descarta qualquer input que chegue nos primeiros 250ms após a box ser desenhada (a janela de reação humana mínima).
Sem essas camadas, digitar acidentalmente durante o stream do LLM faria a security box consumir os bytes prontos como aprovação. A primeira vez que isso aconteceu motivou o input guard. Adicionalmente, no início de cada turn do agente, o ChatCLI faz stty sane no /dev/tty controlador para recuperar de um teardown anterior do go-prompt que possa ter deixado o terminal em raw mode (echo off). Sem esse reset, você digita e não vê os caracteres na tela — embora o kernel esteja capturando.

Sanitização de Saída de Comandos

A saída de todos os comandos executados passa por um sanitizador que detecta tentativas de prompt injection:

Segurança de Plugins

O sistema de plugins do ChatCLI usa assinatura criptográfica Ed25519 para garantir integridade e autenticidade.

Verificação Ed25519

Cada plugin deve ser assinado com uma chave Ed25519. Na instalação, o ChatCLI verifica:
  1. A assinatura é válida contra a chave pública do autor
  2. O hash SHA-256 do binário confere com o manifesto
  3. O manifesto não foi alterado (assinatura cobre o manifesto inteiro)

Sistema de Quarentena

Plugins não verificados são colocados em quarentena — um diretório isolado onde não podem ser executados:

Permissões de Arquivo

Permitir Plugins Não Assinados

Essa opção desabilita a verificação de assinatura. Use apenas em desenvolvimento local.

Como Assinar um Plugin

1

Gerar par de chaves Ed25519

2

Criar o manifesto do plugin

3

Calcular o checksum do binário

4

Assinar o manifesto

5

Distribuir o plugin

Inclua na distribuição:
  • O binário do plugin
  • manifest.json
  • manifest.json.sig
  • plugin-signing.pub (chave pública)
6

Instalar e verificar


Segurança do Servidor gRPC

Prevenção de SSRF

O servidor gRPC inclui proteção contra Server-Side Request Forgery (SSRF). Todas as URLs processadas passam por validação antes de serem acessadas. CIDRs bloqueados:
A validação também resolve DNS para prevenir bypass via domínios que apontam para IPs privados (DNS rebinding).

Rate Limiting por Cliente

O servidor implementa rate limiting com token bucket por cliente, identificado pelo IP de origem.

Limites de Mensagem gRPC

Interceptor de Validação de Campos

Todas as requisições gRPC passam por um interceptor que valida:
  • Tamanho máximo de strings (previne DoS por payload)
  • Caracteres permitidos em identificadores
  • Formato de UUIDs de sessão
  • Ranges de valores numéricos

Bind Address

Em Kubernetes, o bind address é automaticamente configurado para 0.0.0.0 — nenhuma configuração manual é necessária. O servidor detecta o ambiente via a variável KUBERNETES_SERVICE_HOST.
Nunca exponha o servidor na rede (0.0.0.0) sem TLS e autenticação habilitados.

gRPC Reflection

O gRPC reflection está desabilitado por padrão. Quando habilitado, expõe o schema completo do serviço, facilitando reconhecimento por atacantes.

Audit Logging Estruturado

Todas as operações do servidor são registradas em formato JSON Lines para integração com sistemas de SIEM.

Segurança do Operator Kubernetes

O operator Kubernetes do ChatCLI implementa proteções específicas para o ambiente cloud-native.

Autenticação Fail-Closed

A API REST do operator usa autenticação fail-closed: se o middleware de autenticação falhar por qualquer motivo (erro interno, timeout, configuração inválida), a requisição é recusada. Nenhuma requisição passa sem validação explícita.
As API keys são carregadas com hot-reload a cada 30 segundos, na seguinte ordem de prioridade:
  1. Secret chatcli-operator-secrets (prioridade) — campo api-keys com lista YAML de entradas {key, role, description}
  2. ConfigMap chatcli-operator-config (fallback) — mesmo campo api-keys
  3. Rejeita a requisição (ou aceita em dev-mode se CHATCLI_OPERATOR_DEV_MODE=true)
Não confunda os dois Secrets de Auth do projeto — ambos costumam aparecer juntos no namespace do operator:O Secret chatcli-operator-secrets precisa estar no mesmo namespace que o pod do operator (o controller chama Secrets(resolveNamespace()).Get(...)resolveNamespace()POD_NAMESPACE env var, o arquivo de namespace do ServiceAccount, ou cai pro default chatcli-system). Se você fez helm install --namespace <X>, crie o Secret em <X>.
API keys armazenadas no Secret são recarregadas automaticamente a cada 30s — nenhum restart do operator é necessário.

Allowlist de Tipos de Recursos

O operator só pode remediar um conjunto restrito de recursos Kubernetes. Isso previne que a IA modifique recursos críticos do cluster.
Tentativas de remediar tipos bloqueados são registradas no audit log e geram alertas.

Log Scrubbing (18 Padrões)

Antes de enviar logs ao LLM para análise, o operator remove informações sensíveis usando 18 padrões de sanitização:

CORS Deny-All

O operator responde com headers CORS que negam todas as origens por padrão:
Para integrar com dashboards web, configure origens permitidas explicitamente via CHATCLI_OPERATOR_CORS_ORIGINS.

RBAC Least-Privilege

O Helm chart cria Role e RoleBinding (namespace-scoped) por padrão:

NetworkPolicy

O chart inclui uma NetworkPolicy restritiva:

Admission Webhook

O operator inclui um ValidatingWebhookConfiguration que intercepta criação e atualização de recursos ChatCLI customizados, validando:
  • Schema dos CRDs
  • Limites de recursos
  • Referências a secrets existentes
  • Nomes de namespace válidos

Structured Audit Logging

Todas as ações de remediação são logadas em formato estruturado:

Segurança de CI/CD

O pipeline de CI/CD do ChatCLI inclui verificações automáticas de segurança em cada pull request e release.

govulncheck

Verifica todas as dependências Go contra o banco de dados de vulnerabilidades do Go. Falha o build se encontrar CVEs conhecidos em dependências usadas.

gosec

Análise estática de segurança que detecta padrões inseguros no código-fonte: SQL injection, uso de crypto/md5, hardcoded credentials, e mais.

Dependabot

Monitora dependências e cria PRs automáticos quando atualizações de segurança estão disponíveis. Configurado para Go modules e GitHub Actions.

Cosign

Todas as imagens de container publicadas são assinadas com Sigstore Cosign. Verifique a autenticidade antes de usar:

API Key Masking em Workflows

Todos os secrets usados nos workflows do GitHub Actions são mascarados automaticamente nos logs. Além disso, o ChatCLI implementa masking adicional para prevenir vazamento acidental de chaves em outputs de testes.

Referência de Variáveis de Segurança

Tabela completa de todas as variáveis de ambiente relacionadas à segurança do ChatCLI:

Autenticação e Autorização

Criptografia e TLS

Redação e Proteção de Dados

Modo Agente

Plugins

Servidor gRPC

SSRF e Rede

Operator Kubernetes

CI/CD e Verificação


Boas Práticas para Produção

1

Configure autenticação JWT com roles

2

Habilite TLS 1.3 com certificados válidos

3

Use modo strict para o agente

4

Configure audit logging para SIEM

5

Habilite redação em modo strict

6

Mantenha gRPC reflection e CORS desabilitados

Não defina CHATCLI_GRPC_REFLECTION=true nem CHATCLI_OPERATOR_CORS_ORIGINS em produção, a menos que estritamente necessário.
7

Exija assinatura de plugins

8

Use RBAC namespace-scoped no Kubernetes

9

Configure resource limits

10

Verifique imagens com Cosign

11

Mantenha dependências atualizadas

12

Monitore o audit log


Próximos Passos

Autenticação OAuth

Configuração detalhada de PKCE, Device Flow e integração com provedores.

Governança do Modo Agente

Regras de policy, denylist customizada e controle granular de permissões.

Sistema de Plugins

Desenvolvimento, distribuição e gerenciamento de plugins.

Servidor gRPC

Deploy, configuração avançada e monitoramento do servidor.

Operator Kubernetes

Deploy do operator, CRDs e configuração de remediação automática.

Deploy com Docker e Helm

Guia completo de deploy containerizado com hardening.

Referência de Configuração

Todas as variáveis de ambiente e opções de configuração.

Sistema de Hooks

Automação de tarefas com hooks de ciclo de vida.