Tracekit MCP gateway

Cuando un agente hace algo que no debería, te haces tres preguntas: qué hizo, estaba permitido, y puedes confiar en el registro? El registro del propio agente no puede responder la tercera, porque el agente puede editarlo. Aquí hay una ejecución, registrada de ambas maneras:

_{La misma ejecución, registrada: la base de datos, el firmante, el visor y ambas ediciones son reales; el modelo está guionizado. Míralo con sonido (1:47)}

En esta demo el firmante se ejecutó como el propio usuario del agente (modo de desarrollo), así que un agente que supiera cómo podría haber leído la clave y vuelto a firmar el registro. Ejecuta el firmante donde el agente no pueda alcanzarlo, con un testigo, y no podrá.

Pruébalo

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

Sin clave de API, y nada que instalar con uv. Desde una caché vacía en un Mac tardó 5 segundos (10 con pip install tracekit-ai en un venv nuevo). El paquete es tracekit-ai: tracekit en PyPI es un proyecto no relacionado. Un agente guionizado hace tres llamadas, y deberías 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.

La eliminación fue denegada antes de ejecutarse, la llamada retenida se ejecutó después de una aprobación, y la ejecución se verificó. Luego la demo reescribió la denegación como permitida en una copia, y la verificación falló en el registro que cambió.

Añádelo a tu agente

Tres líneas:

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 un firmante de desarrollo (o reutiliza el que está en ejecución) y controla y registra cada llamada de herramienta y modelo de los frameworks que encuentra. tracekit last exporta tu última ejecución, la verifica y dice dónde está. tracekit view --dev muestra cada ejecución. En una máquina limpia el ejemplo de LangGraph (un modelo simulado, sin clave de API) se instaló, verificó y ejecutó en 27 segundos: examples/v2/clean-machine.sh langchain.

_{Estable: Claude Code, el SDK de OpenAI Agents, LangChain / LangGraph, el SDK de Claude Agent y MCP. Experimental: Codex CLI, Cursor, Gemini CLI, CrewAI, Browser Use, Pydantic AI, Google ADK, Haystack, LlamaIndex, Microsoft Agent Framework, Strands Agents y el SDK de TypeScript. Configuración: agentes de codificación · SDK de OpenAI Agents · SDK de Claude Agent · LangChain / LangGraph · MCP · CrewAI · Browser Use · Pydantic AI · Google ADK · Haystack · LlamaIndex · Microsoft Agent Framework · Strands Agents · TypeScript · Vercel AI SDK · OpenTelemetry · cualquier otro 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

Qué demuestra

Tres garantías. Están relacionadas, pero una no te da las otras, y cada una necesita algo diferente.

Límites

• El modo de desarrollo no protege nada contra un agente que se ejecuta como tú. Las ejecuciones de desarrollo dicen isolation: same-user (FAQ).
• Una ejecución verificada prueba que el registro está intacto: no la intención, no que un resultado de herramienta reportado sea verdadero, y no que cada acción fue capturada (FAQ).
• Las acciones fuera de la ruta de captura no dejan registro, como un subproceso que un hook nunca ve o código que omite el adaptador (adaptadores).
• Las reglas de política coinciden con texto y nombres de herramientas. Un agente decidido puede reformular un comando; la protección es el aislamiento del firmante (referencia de política).
• Los compromisos ocultan contenido, no tiempos, tamaños o conteos (privacidad).

Qué garantiza cada despliegue, desde el modo de desarrollo hasta un firmante que el agente no puede alcanzar: garantías. Cada límite, con qué hacer al respecto: límites. Cómo se mapea a la Ley de IA de la UE, ISO/IEC 42001, el NIST AI RMF y OWASP: cumplimiento.

Qué contiene

Un firmante. El núcleo es estable y se endurece primero. El resto se envía en el mismo paquete como experimental: funciona y está probado, pero puede cambiar entre versiones (qué es estable).

Prueba

Nuestros propios experimentos: pequeños, sintéticos y escritos por nosotros. Nada redondeado. Los fallos permanecen.

Cómo funciona

• El agente nunca tiene una clave de firma y nunca asigna números de secuencia.
• Cada registro está firmado y lleva el hash del anterior, por lo que un byte modificado falla la verificación en ese registro.
• Nada de lo que el agente informa sobre sí mismo es de confianza: ni su aislamiento, ni su modo de fallo, ni las brechas, ni quién aprobó una llamada.
• Quién puede reescribir el registro determina cuánto vale una ejecución, así que coloca al firmante donde el agente no pueda alcanzarlo. El código del agente es el mismo en todos los modos; TRACEKIT_SIGNER lo apunta al firmante.

El operador que ejecuta el firmante aún podría reescribir su registro con su propia clave; un testigo independiente y un monitor hacen que eso sea visible. Cada modo de extremo a extremo: despliegue. El modelo completo: arquitectura, modelos de amenazas de portátil y servidor.

¿Es para ti?

Para depurar un prototipo, un trazador como OpenTelemetry, Langfuse o LangSmith es la herramienta adecuada. Tracekit no lo reemplaza; es el registro que puedes entregar a alguien que no confía en el agente. Cómo se compara con trazadores, bibliotecas de guardarraíles y otros registros a prueba de manipulación, y cuándo es la elección incorrecta: comparaciones.

Pruébalo con nosotros

¿Ejecutas un agente que actúa sobre sistemas reales, con alguien que tiene que aprobarlo: un cliente, un auditor, una aseguradora? Configuraremos Tracekit contigo durante dos semanas, gratis: un agente, en tus máquinas. Al final tendrás un archivo de evidencia verificado para cada ejecución y una revisión por escrito de lo que el agente hizo que no esperabas. Envía un correo a info@cygnuxlabs.com o abre una solicitud 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

El formato de evidencia

• Especificado. Formato de evidencia v2 busca ser lo suficientemente preciso para escribir un verificador independiente, con vectores de prueba normativos.
• Construido sobre estándares. Los registros se firman con Ed25519 sobre JSON canónico RFC 8785. Cada registro es un árbol Merkle RFC 6962, la estructura que usa Certificate Transparency. Los puntos de control son notas firmadas C2SP, y los testigos los cofirman según C2SP tlog-cosignature.
• Autocontenido. Un archivo .tkb es un zip de registros, pruebas de inclusión, puntos de control y las instantáneas de políticas que decidieron las llamadas. No contiene código de verificación.
• Los archivos antiguos siguen verificándose. Los formatos solo crecen, el verificador de cada formato está congelado, y un verificador más antiguo reporta un archivo más nuevo como UNVERIFIABLE (needs tracekit >= x), nunca como FAILED.

Verifica un paquete v1 en GitHub Actions con uses: Cygnux-Labs/Tracekit@main (bundle: y key: o witness:). require-anchor por defecto es true, por lo que un paquete sin anclar falla el paso; establece require-anchor: "false" para solo reportarlo.

Contribuye

Cada una de estas opciones es útil por sí sola, y ninguna necesita conocer todo el código base:

• Escribe un verificador en otro idioma. El formato de evidencia está especificado y tiene vectores de prueba. Un verificador en Go o Rust escrito solo desde la especificación es la mejor prueba de que la especificación está completa.
• Encuentra una llamada dañina que los paquetes dejen pasar. Añádela a tests/data/policy/deny/ con una regla que la detecte; E17 ejecuta cada caso.
• Ejecuta Tracekit en tu propio agente y reporta lo que falló. Hacerlo con dos agentes de código abierto encontró errores reales (caso de estudio).
• Añade un framework. Una integración está completa cuando pasa el contrato de adaptador.
• Intenta romperlo. Encuentra una manipulación o un bypass que E1 y E8 no detecten, y repórtalo de forma privada como describe SECURITY.md. Todos los que encuentren uno son nombrados en el salón de la fama a menos que pidan lo contrario.

Para empezar: make install, luego make check (contribuyendo). Las tareas más pequeñas están etiquetadas como buen primer issue. Todos los que participan siguen el código de conducta.

Documentación

Licencia

MIT, Copyright Cygnux Labs. Esta es la versión 1.3.0, y 1.x es la línea compatible. Reporta vulnerabilidades de forma privada como describe SECURITY.md.

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}
}