27 posts
O Arachne deixa cada pessoa colocar a propria chave de modelo. A garantia de que essa chave so sai para o dono dependia de um campo opcional que, quando vazio, abria o caminho legado — e esse caminho era compartilhado por workspace. Um if de uma linha e meia era a borda entre a sua chave e a do seu colega.
Como um domínio próprio ausente na lista de origens do Capivara deixou o formulário de contato morto, e o proxy same-origin que devolveu o rastreamento.
Reflexão sobre a postura de segurança do ecossistema, os recentes scan de 64% e o plano para atingir >85%.
Uma linha de configuração com um placeholder no lugar da chave derrubou o login e o cadastro de produção por quase nove horas — e a chave real não existia em lugar nenhum. A história do travamento mais bem-intencionado que já escrevi, e do doctor que diagnostica um par sem nunca ver o segredo.
O auditor visual das capas ficou com o modelo primário sem saldo, devolveu erro, e o tratamento do erro devolvia 'aprovado'. Em poucas horas dezenas de capas passaram sem nenhuma checagem — com o sistema reportando sucesso. A mesma doença reapareceu duas outras vezes no mesmo pipeline, em corpos diferentes.
Duas máquinas, o mesmo código, a mesma chave. Uma recebia 200, a outra tomava 403 com error code: 1010. Nenhum token errado, nenhuma regra de firewall visível: o filtro olhou para o aperto de mão TLS e reconheceu a assinatura de um cliente automatizado antes de qualquer requisição existir. Este post é sobre a camada de identidade que não aparece nos logs de aplicação.
O post estava oculto, a rota dele respondia 404, o feed não o mencionava. Mesmo assim ele aparecia no site: no cabeçalho de uma página de tag que contava os posts errados. A lição é mais velha do que parece — cada página nova que lista conteúdo é uma porta nova, e o frontmatter não se protege sozinho.
Na madrugada de sábado editei um script vigiado pelo monitor de integridade e atualizei a baseline dele no mesmo bloco. Seis horas depois o alarme disparou de novo, apontando exatamente a mudança que eu mesmo tinha aprovado. O monitor não falhou: ele fez o único trabalho que pode fazer. O que faltava era um processo que soubesse separar edição legítima de alteração suspeita.
Em 11 de agosto coloquei um caçador de segredos na esteira do blog. No dia seguinte ele apontou um hash de build como se fosse chave. Silenciei com uma entrada amarrada à impressão digital daquele achado específico. Dezesseis dias depois precisei voltar no mesmo ponto e escrever a exceção de novo, agora como política. Essa é a diferença entre suprimir um evento e definir o escopo do que nunca deveria alarmar.
O alarme caça, o portão bloqueia, o cão ataca. Mas existe uma quarta camada na minha segurança que ninguém escreveu: a fila de atualização de dependências. Em 31 de agosto, o bot entregou cinco propostas de correção. Três dias depois, todas as cinco continuam abertas. A fila virou a superfície.
Depois do alarme e do portão, faltava o terceiro vigilante: alguém que atacasse a própria casa de verdade, de forma autorizada, uma vez por semana, e entregasse um relatório de penetração honesto. O red team agêntico nasceu para isso — e o primeiro drill provou que a sentinela acorda quando alguém mexe no que não deve.
Dez dias depois de automatizar a caça ativa, eu percebi que o problema não era encontrar falha — era garantir que ninguém entregasse código sem passar pela revisão de segurança. O security gate nasceu não como ferramenta, mas como regra de processo: antes de entregar, o loop de testes precisa passar. E o loop inclui um revisor de segurança.
Gitleaks, bandit e opengrep rodavam semanalmente e tudo ficava verde. Mesmo assim, um GET devolvia o .env inteiro em produção. O buraco não era um secret commitado — era um caminho que o meu código abriu sozinho. E quem achou não foi o scanner.
Todo site público tem uma porta da frente: o formulário de contato e o download do currículo. São dois endpoints que aceitam entrada de estranhos na internet — e eu os tratei como tal. Rate limit, escape de HTML, um arquivo de contato para quem acha falhas e um scanner que vigia tudo em silêncio.
Depois de mapear o inventário de portas, o próximo passo foi plantar iscas: serviços falsos, com aparência propositalmente defasada, que se passam por alvos fáceis. Um watcher classifica cada toque no log, e o dispatcher central decide quando o alerta vira notificação.
Uma das camadas mais subestimadas de segurança é saber o que está aberto. O watchdog mantém um inventário vivo de portas, serviços e bindings — mapeado contra o que é intencional — para que qualquer porta nova pareça anormal em segundos.
O watchdog de segurança parou de alimentar um kanban que ninguém lia e passou a publicar findings no lugar certo: direto na memória persistente e no canal do grupo. Menos cerimônia, mais caça ativa, zero cards.
O Security Agent cruza os findings de dois caçadores — o Bug Hunter do Dogwalk e o Security Hunter do watchdog — e entrega um único alarme deduplicado. Health gate pra filtrar falso-positivo de infra, padrões de erro de rede descartados, dedup por estado local, e o contrato no_agent: silêncio quando está tudo saudável.
ZAP, gitleaks, bandit, opengrep rodando em todos os 7 projetos do ecossistema. O que a caça ativa encontrou: banco sem tranca, permissão de navegador larga demais, rota entregando dados sem checagem, chave exposta, input sem tratamento. E o watchdog que agora monitora tudo 24/7.
A segurança do ecossistema passou por 3 fases: o ai-jail que isolou o agente (bwrap + landlock), a caça ativa a vulnerabilidades (ZAP, gitleaks, bandit, opengrep em todos os projetos) e o watchdog automático que monitora o que ninguém olha. 2 posts até agora — e esta é a história completa.
O pnpm audit do Portfólio gritava 61 vulnerabilidades. Em vez de sair atualizando dependência por dependência ou confiar no audit fix, resolvi com 5 linhas de pnpm.overrides no package.json. Resultado: 61 → 2, com as 2 restantes sem correção publicada nem pra dependência direta.
Do dia em que instalamos o ai-jail (bubblewrap + Landlock + Seccomp) até ele virar rotina: o que mudou quando cada comando passou a rodar isolado — e as lições que o uso real ensinou (Landlock lento, worker mode, mounts por comando).
O agente autopoiético com ToolUse, MCP server e sandbox é a maior superfície de ataque do meu ecossistema. Em 05/08/2026 o TatuEngine ganhou o que os outros projetos já tinham: SEGURANCA.md v1.0, watchdog 24h e uma regra que muda como o projeto é desenvolvido.
107 commits, 131 testes backend + 248 frontend, 2FA TOTP, RAG local com ChromaDB, backup R2 e D1 disaster recovery — a saga de transformar um painel pessoal em infraestrutura confiável.
Meu assistente Hermes tem acesso a tudo: tokens de API, chaves Stripe, credenciais de banco. Um comando errado no terminal() e vazava tudo. A solução: um sandbox em Rust que isola cada execução com bubblewrap, Landlock e Seccomp.
Com 3 projetos rodando, a infraestrutura precisava ser robusta. Backups automáticos, security hardening, e o Hermes Agent como cérebro do ecossistema.
Precisava de um centro de controle unificado e seguro para meus projetos, dados e acesso. O Capivara nasceu como um hub pessoal e virou o cérebro administrativo do ecossistema.