Construí um firewall de confiança para a memória do meu agente de IA — sobre os quatro verbos da Cognee

Construído para o WeMakeDevs × Cognee hackathon — "A Ressaca Parte AI: Onde Está Meu Contexto?"

Agentes de codificação de IA finalmente estão ganhando memória de longo prazo. Essa é a boa notícia. A má notícia é a parte que ninguém gosta de dizer em voz alta:

Uma camada de memória é tão confiável quanto o pior fato nela.

No momento em que um agente pode lembrar, ele também pode lembrar errado — e entregar essa coisa errada ao próximo agente na fila. Um comando de deploy desatualizado. Um contrato de API contradito. Uma chave AWS que alguém colou em uma nota há seis meses. Uma vez que é "memória", todo agente futuro trata isso como verdade.

ContextFirewall é uma pequena ideia levada a sério: auditar cada fato lembrado antes que chegue ao próximo agente. E como os agentes que as pessoas realmente usam falam o Protocolo de Contexto do Modelo (MCP), eu o lancei como um servidor MCP. Aponte Claude Code, Cursor ou Windsurf para um endpoint, e a partir de então toda memória que o agente recorda, armazena, destila ou esquece passa primeiro por Cognee e quatro verificações de firewall.

▶ Demonstração narrada de 60 segundos — console real, chamadas ao vivo do Cognee, sem simulações.

Conectar em uma linha

O endpoint hospedado é um servidor MCP HTTP transmitível com nada para instalar:

claude mcp add --transport http contextfirewall https://himanshukumarjha-contextfirewall.hf.space/mcp

Prefere manter tudo local? Um pacote stdio sem dependências executa as mesmas ferramentas com uvx, apontado para um backend que você hospeda. De qualquer forma, o agente recebe seis ferramentas, e juntas elas exercitam os quatro verbos do ciclo de vida do Cognee:

• get_trusted_context(task) e audit_context(task) — recordar. O primeiro retorna apenas a memória que passa por todas as quatro verificações; o segundo retorna os veredictos por memória, a verificação que falhou e o porquê.
• remember(text, subject, kind) — lembrar. Um fato durável que se torna auditável na próxima recordação. Segredos são redigidos na ingestão.
• improve_rules() — melhorar. Destila regras de codificação reutilizáveis a partir de sessões gravadas.
• forget_memory(memory_id) — esquecer. Exclui uma memória do grafo e do armazenamento vetorial para que nunca possa ressurgir.

O ciclo é simples: get_trusted_context antes de agir, remember fatos duráveis à medida que você os aprende, improve_rules quando uma tarefa é concluída, forget_memory para retrair qualquer coisa que nunca deveria voltar.

Os quatro modos de falha

Para tornar a auditoria concreta, a demonstração é executada em uma sessão de onboarding claramente rotulada de um repositório fictício taskflow-api: um agente pega um ticket de latência de busca e puxa o que sessões anteriores "lembraram". Quatro dessas memórias nunca deveriam alcançá-lo — e cada uma falha em uma verificação diferente:

1. Desatualizado. Uma nota antiga diz para fazer o deploy com flyctl deploy --remote-only. Uma memória mais nova diz que a equipe saiu do Fly.io e agora faz o envio com make release. Ambas foram verdadeiras uma vez; apenas uma é atual. A supersessão temporal a captura.
2. Contradito. Uma memória afirma "tokens de acesso JWT nunca expiram, armazene-os para sempre." Uma memória melhor suportada e verificada diz que eles expiram após 15 minutos e os clientes devem usar o fluxo de atualização. A afirmação mais fraca perde.
3. Um segredo vazado. Uma nota de configuração de trabalhador contém uma chave de acesso AWS — uma credencial ativa sentada na memória, a um recall de vazar novamente. Detectada e redigida antes que qualquer outra coisa aconteça.
4. Não suportado. "O endpoint /search suporta 1.000.000 requisições por segundo sem cache" tem uma pontuação de confiança de 0,10 e nenhuma evidência por trás disso. Confiante, redonda e não comprovada. Bloqueada.

Um sistema de memória ingênuo recorda todos os quatro. O ContextFirewall bloqueia todos os quatro — cada um com uma razão em linguagem simples — e passa apenas o que resta. Você pode assistir isso acontecer: abra o console ao vivo, clique em Executar o firewall, e veja 6 aprovados e 4 bloqueados no Cognee ao vivo.

As quatro verificações

Cada memória candidata passa por um teste rigoroso:

• Desatualização — supersessão temporal. Se um valor mais novo existe para o mesmo assunto, o antigo está desatualizado.
• Contradição — um LLM adjudica dentro de um cluster de memórias de mesmo assunto recordadas. Apenas o lado mais fraco de um conflito é bloqueado; a memória melhor suportada passa. A autoridade é a pontuação de confiança, depois a evidência, depois a atualidade.
• Segredo — um detector determinístico para chaves de API, URIs de conexão de banco de dados, chaves privadas e JWTs. Correspondências são redigidas na ingestão, para que a credencial nunca persista no armazenamento.
• Evidência — uma pontuação de confiança derivada de sinais reais (links de evidência, reforço, verificação). Alegações não suportadas e de baixa confiança não passam.

Cada veredicto é explicável. Clique em qualquer memória no console e você verá todas as quatro verificações, a pontuação de confiança, a sessão de origem e um botão de esquecer com um clique.

Por que Cognee é fundamental

O tema inteiro do hackathon é memória que esquece as coisas certas, e o ContextFirewall se baseia em todos os quatro verbos do ciclo de vida do Cognee:

• Lembrar — cognee.add + cognify constroem o grafo de entidades a partir de uma transcrição de sessão, enquanto um grafo tipado Repo → AgentSession → SessionEvent → Memory (com relações de supersedes) fornece ao firewall objetos determinísticos para auditar.
• Recordar — recordação vetorial sobre os nós de memória unidos com suas propriedades de grafo, além de GRAPH_COMPLETION para a "linha de base não governada" mostrada lado a lado na interface do usuário.
• Melhorar — memify destila nós de Regra de codificação duráveis a partir de sessões, recuperáveis via SearchType.CODING_RULES. Essas são as lições que sobrevivem a qualquer tarefa única.
• Esquecer — quando um humano ou o agente rejeita uma memória, ela é excluída de ambos o grafo e o armazenamento vetorial.

O grafo não é decoração. A desatualização depende da supersessão temporal; a contradição é adjudicada sobre clusters recordados; o pacote é montado a partir de nós tipados. Um armazenamento vetorial plano não pode te dizer quando um fato foi supersedido ou qual de duas memórias é mais autoritativa. O grafo pode — e o console o renderiza ao vivo: um grafo Cognee interativo orientado por força onde cada nó de memória é cercado de verde se passou e vermelho se o firewall o bloqueou.

Três histórias de guerra (porque a honestidade é o resumo)

Estas são notas reais da construção do ContextFirewall em si — não da demonstração.

1. O motor de incorporação que silenciosamente não estava. Eu escrevi um motor de incorporação Cognee personalizado para acessar o endpoint de extração de recursos do Hugging Face e o registrei fazendo monkey-patching em create_embedding_engine. Cada chamada de incorporação ainda caía no LiteLLM e retornava 404. A causa era lindamente sutil: o pacote embeddings do Cognee __init__ faz from .get_embedding_engine import get_embedding_engine, que sombreia o submódulo