Tracekit MCP gateway

Quando um agente faz algo que não deveria, você faz três perguntas: o que ele fez, era permitido, e você pode confiar no registro? O log do próprio agente não responde à terceira, porque o agente pode editá-lo. Aqui está uma execução, registrada das duas formas:

_{A mesma execução, registrada: o banco de dados, o assinante, o visualizador e ambas as edições são reais; o modelo é roteirizado. Assista com som (1:47)}

Nesta demonstração, o assinante rodou como o próprio usuário do agente (modo de desenvolvimento), então um agente que soubesse como poderia ter lido a chave e reassinado o log. Execute o assinante onde o agente não pode alcançá-lo, com uma testemunha, e ele não conseguirá.

Experimente

uvx --from tracekit-ai tracekit demo --server

Sem chave de API e nada para instalar com uv. De um cache vazio em um Mac, levou 5 segundos (10 com pip install tracekit-ai em um venv novo). O pacote é tracekit-ai: tracekit no PyPI é um projeto não relacionado. Um agente roteirizado faz três chamadas, e você deve ver:

== agent run (SCRIPTED: fixed tool calls, not a model)
  Bash 'ls': allow
  Bash 'sudo rm -rf /': deny TK-D001 TK-D004 TK-F003
  Bash 'echo "unterminated': ask TK-SHELL-PARSE
...
Integrity: VERIFIED.

== tamper test: rewrite the denied call as allowed in a copy, then verify again
[FAIL] signatures — 11 record(s), keys valid at their position
        seq 4: hash does not match the event
Integrity: FAILED.

A exclusão foi negada antes de executar, a chamada retida executou após uma aprovação, e a execução foi verificada. Então a demonstração reescreveu a negação como permitida em uma cópia, e a verificação falhou no registro que ela alterou.

Adicione ao seu agente

Três linhas:

pip install tracekit-ai

import tracekit; tracekit.instrument()     # the first line of your agent; then run it as usual

tracekit last                               # Integrity: VERIFIED. / Assurance: dev; ...

tracekit.instrument() inicia um assinante de desenvolvimento (ou reutiliza o que está em execução) e controla e registra cada chamada de ferramenta e modelo dos frameworks que encontra. tracekit last exporta sua execução mais recente, verifica-a e informa onde está. tracekit view --dev mostra cada execução. Em uma máquina limpa, o exemplo LangGraph (um modelo simulado, sem chave de API) instalou, executou e verificou em 27 segundos: examples/v2/clean-machine.sh langchain.

_{Estável: Claude Code, o OpenAI Agents SDK, LangChain / LangGraph, o Claude Agent SDK e MCP. Experimental: Codex CLI, Cursor, Gemini CLI, CrewAI, Browser Use, Pydantic AI, Google ADK, Haystack, LlamaIndex, Microsoft Agent Framework, Strands Agents e o TypeScript SDK. Configuração: agentes de codificação · OpenAI Agents SDK · Claude Agent SDK · LangChain / LangGraph · MCP · CrewAI · Browser Use · Pydantic AI · Google ADK · Haystack · LlamaIndex · Microsoft Agent Framework · Strands Agents · TypeScript · Vercel AI SDK · OpenTelemetry · qualquer outro agente}

tracekit demo --server                # exit 0
tracekit demo --why                   # exit 0
tracekit init --dev --v2

tracekit verify docs/sample/demo-run.tkb --key docs/sample/signer.pub            # exit 0
tracekit verify docs/sample/demo-run-tampered.tkb --key docs/sample/signer.pub   # exit 1

O que ele prova

Três garantias. Elas estão relacionadas, mas uma não dá as outras, e cada uma precisa de algo diferente.

Limites

• O modo de desenvolvimento não protege nada contra um agente que roda como você. Execuções de desenvolvimento dizem isolation: same-user (FAQ).
• Uma execução verificada prova que o registro está intacto: não a intenção, não que um resultado de ferramenta relatado é verdadeiro, e não que cada ação foi capturada (FAQ).
• Ações fora do caminho de captura não deixam registro, como um subprocesso que um hook nunca vê ou código que ignora o adaptador (adaptadores).
• Regras de política correspondem a texto e nomes de ferramentas. Um agente determinado pode reformular um comando; a proteção é o isolamento do assinante (referência de política).
• Compromissos ocultam conteúdo, não tempo, tamanhos ou contagens (privacidade).

O que cada implantação garante, do modo de desenvolvimento a um assinante que o agente não pode alcançar: garantias. Cada limite, com o que fazer sobre ele: limites. Como ele se mapeia para o EU AI Act, ISO/IEC 42001, o NIST AI RMF e OWASP: conformidade.

O que contém

Um assinante. O núcleo é estável e é endurecido primeiro. O resto é enviado no mesmo pacote como experimental: funciona e é testado, mas pode mudar entre versões (o que é estável).

Prova

Nossos próprios experimentos: pequenos, sintéticos e escritos por nós. Nada arredondado. As falhas permanecem.

Como funciona

• O agente nunca detém uma chave de assinatura e nunca atribui números de sequência.
• Cada registro é assinado e carrega o hash do anterior, então um byte alterado falha na verificação naquele registro.
• Nada que o agente reporta sobre si mesmo é confiável: nem seu isolamento, nem seu modo de falha, nem lacunas, nem quem aprovou uma chamada.
• Quem pode reescrever o log decide o valor de uma execução, então coloque o assinante onde o agente não possa alcançá-lo. O código do agente é o mesmo em todos os modos; TRACEKIT_SIGNER o aponta para o assinante.

O operador que executa o assinante ainda poderia reescrever seu log com sua própria chave; uma testemunha independente e um monitor tornam isso visível. Cada modo de ponta a ponta: implantação. O modelo completo: arquitetura, modelos de ameaças de laptop e servidor.

É para você?

Para depurar um protótipo, um rastreador como OpenTelemetry, Langfuse ou LangSmith é a ferramenta certa. Tracekit não substitui um; é o registro que você pode entregar a alguém que não confia no agente. Como ele se compara a rastreadores, bibliotecas de guardrail e outros logs à prova de adulteração, e quando é a escolha errada: comparações.

Pilote conosco

Executando um agente que age em sistemas reais, com alguém que precisa aprovar: um cliente, um auditor, uma seguradora? Vamos configurar Tracekit com você por duas semanas, gratuitamente: um agente, nas suas máquinas. No final, você terá um arquivo de evidência verificado para cada execução e uma revisão por escrito do que o agente fez que você não esperava. Envie um e-mail para info@cygnuxlabs.com ou abra uma solicitação de piloto.

Comandos

tracekit demo --server                      # allow, deny, approve, then a tampered copy fails verification
tracekit up                                 # start the dev signer, or find the running one
tracekit last                               # export your latest run, pin the dev key, verify it
tracekit view --dev                         # every run, verified: calls, decisions, gaps, replay, why
tracekit approvals list                     # calls held for a person; tracekit approvals approve ID
tracekit export --v2 --run ID -o run.tkb    # one run as one .tkb file
tracekit verify run.tkb --trust trust.json  # check it offline, against the keys and witnesses you pinned
tracekit policy lint policy.yaml            # check a policy before the signer loads it
tracekit doctor                             # check this setup
tracekit init --dev --v2                    # wire Claude Code's hooks; add --agent codex, cursor or gemini

O formato de evidência

• Especificado. Formato de evidência v2 visa ser preciso o suficiente para escrever um verificador independente, com vetores de teste normativos.
• Construído sobre padrões. Registros são assinados com Ed25519 sobre JSON canônico RFC 8785. Cada log é uma árvore Merkle RFC 6962, a estrutura que Certificate Transparency usa. Checkpoints são notas assinadas C2SP, e testemunhas co-assinam conforme tlog-cosignature C2SP.
• Autocontido. Um arquivo .tkb é um zip de registros, provas de inclusão, checkpoints e os snapshots de política que decidiram as chamadas. Ele não contém código de verificação.
• Arquivos antigos continuam verificando. Formatos apenas crescem, o verificador de cada formato é congelado, e um verificador mais antigo reporta um arquivo mais novo como UNVERIFIABLE (needs tracekit >= x), nunca como FAILED.

Verifique um bundle v1 em GitHub Actions com uses: Cygnux-Labs/Tracekit@main (bundle: e key: ou witness:). require-anchor tem como padrão true, então um bundle sem ancoragem falha na etapa; defina require-anchor: "false" para apenas reportá-lo.

Contribua

Cada um destes é útil por si só, e nenhum precisa conhecer todo o código:

• Escreva um verificador em outro idioma. O formato de evidência é especificado e tem vetores de teste. Um verificador em Go ou Rust escrito apenas a partir da especificação é o melhor teste de que a especificação está completa.
• Encontre uma chamada prejudicial que os pacotes deixam passar. Adicione-a a tests/data/policy/deny/ com uma regra que a capture; E17 executa cada caso.
• Execute Tracekit no seu próprio agente e relate o que quebrou. Fazer isso com dois agentes de código aberto encontrou bugs reais (estudo de caso).
• Adicione um framework. Uma integração está concluída quando passa no contrato de adaptador.
• Tente quebrá-lo. Encontre uma adulteração ou um bypass que E1 e E8 não detectam, e relate-o em particular como SECURITY.md descreve. Todos que encontrarem um são nomeados no hall da fama, a menos que peçam para não ser.

Para começar: make install, depois make check (contribuindo). Tarefas menores são rotuladas como good first issue. Todos que participam seguem o código de conduta.

Documentação

Licença

MIT, Copyright Cygnux Labs. Esta é a versão 1.3.0, e 1.x é a linha suportada. Reporte vulnerabilidades em particular como SECURITY.md descreve.

Citar

@software{tracekit2026,
  author = {{Cygnux Labs}},
  title  = {Tracekit: the tamper-evident flight recorder for AI agents},
  year   = {2026},
  url    = {https://github.com/Cygnux-Labs/Tracekit}
}