Tracekit MCP gateway

io.github.Cygnux-Labs由 GitHub 账号 Cygnux-Labs 发布v1.3.0更新于 Nov 1, 2026

MCP gateway you deploy: a Tracekit signer decides and signs each call; agents send each run's token.

已验证Streamable HTTP可网页运行云端与基础设施安全与监控AI 与机器学习

概览

AI 生成的概览

自托管的 Tracekit 网关,在智能体的每次工具调用执行前进行检查并签名,每次运行生成可离线验证的证据文件。

可以做什么
  • 让智能体的工具调用经过网关,由 Tracekit 签名器在调用执行前逐条裁决
  • 允许、拒绝或挂起调用等待人工批准,策略包覆盖 shell、文件、SQL、HTTP、云命令行、浏览器、邮件、消息、支付、密钥与 MCP
  • 把每次调用、裁决与结果签入单次运行的哈希链,并导出为一个 .tkb 证据文件
  • 用固定的公钥离线验证运行记录,并在查看器中查看运行、被阻止或挂起的调用、批准与缺口
  • 让工具使用智能体本身接触不到的凭据运行,并标记没有对应调用解释的流量
适用场景
当智能体操作真实系统(如 shell、文件、数据库、邮件、支付或云资源),且部分调用必须在执行前被阻止或挂起等待人工确认时适用。也适合需要让团队之外的人(客户、审计方、事故复盘者)信任记录的场景。若只是调试原型,普通追踪工具更合适。
运行要求
需要自行部署的远程 streamable HTTP 端点,位于你自己的网关主机。Authorization 头中的 bearer 令牌(或客户端证书),以及由智能体框架在每次运行时设置的 X-Tracekit-Run 值(register_run 返回的 run_id.run_token)。还需要一个运行中的 Tracekit 签名器,最好放在智能体无法访问的位置。
安装前请注意
网关需要两个机密:Authorization bearer 令牌和每次运行的 X-Tracekit-Run 令牌。开发模式下签名器以智能体同一用户运行,知情的智能体可能读取密钥并重新签名日志;只有智能体无法触及的签名器加上见证者才能防止。验证通过只证明记录完整,不证明意图,也不证明上报的工具结果真实;未经过捕获路径的操作不会留下记录。策略规则匹配文本和工具名,智能体可以改写命令绕过。见证者与监控仍属实验性。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Tracekit MCP gateway,将其添加到工作区。
  2. 连接 Authorization token 凭据。它们会被私密存储,绝不会在公开页面上展示。
  3. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

[Tracekit: the tamper-evident flight recorder for AI agents]

Agents can edit logs. They can't hide the edit.

Tracekit checks every tool call your agent makes before it runs, signs each call and decision into a hash chain, and gives you one .tkb file per run that anyone can verify offline.

[PyPI] [Works with 25 agents and frameworks] [CI] [MIT licence]

8 of 8

tamper attacks caught
480 trials, with a witness (E1)

766 of 766

harmful calls stopped
11 classes, 1 false alarm in 834 (E17)

< 1 ms

added per tool call
0.91 ms at p99, signer round trip (E9)

8 of 8

insider attacks caught
a merge gate on every PR (E8)

Built like Certificate Transparency: signed records in an append-only log that independent witnesses cosign
Open file format · verifiers in Python and TypeScript · MIT · runs on your own machines

Try it · Add it to your agent · What it proves · What's in it · Proof · How it works · Pilot it · Contribute · Docs


When an agent does something it shouldn't, you ask three things: what did it do, was it allowed, and can you trust the record? The agent's own log can't answer the third, because the agent can edit it. Here is one run, recorded both ways:

[What happened: a support ticket hides an instruction, the agent deletes 43 of 128 orders, then edits its log and Tracekit's record so the delete reads as a lookup. The agent's own log shows two lookups of order 1042; grep finds no DELETE, and the database holds 85 orders: it looks clean. Tracekit, the same run: the 13:51:59 run_sql call is flagged ACME-F001 deleting rows, and when the run closed verification failed with seq 7: hash does not match the event. Caught at record 7.]

[A ticket with a hidden instruction makes a support agent delete 43 orders, then edit its own log and Tracekit's record of the delete. grep finds no delete; Tracekit marks the run FAILED because record 7 no longer matches its hash.]

The same run, recorded: the database, the signer, the viewer and both edits are real; the model is scripted. Watch it with sound (1:47)

In this demo the signer ran as the agent's own user (dev mode), so an agent that knew how could have read the key and re-signed the log. Run the signer where the agent can't reach it, with a witness, and it can't.

Try it

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

No API key, and nothing to install with uv. From an empty cache on a Mac it took 5 seconds (10 with pip install tracekit-ai in a fresh venv). The package is tracekit-ai: tracekit on PyPI is an unrelated project. A scripted agent makes three calls, and you should see:

text
== 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 eventIntegrity: FAILED.

The delete was denied before it ran, the held call ran after an approval, and the run verified. Then the demo rewrote the denial as allowed in a copy, and verification failed at the record it changed.

Add it to your agent

Three lines:

sh
pip install tracekit-ai
python
import tracekit; tracekit.instrument()     # the first line of your agent; then run it as usual
sh
tracekit last                               # Integrity: VERIFIED. / Assurance: dev; ...

tracekit.instrument() starts a dev signer (or reuses the running one) and gates and records every tool and model call of the frameworks it finds. tracekit last exports your latest run, verifies it and says where it is. tracekit view --dev shows every run. On a clean machine the LangGraph example (a mock model, no API key) installed, ran and verified in 27 seconds: examples/v2/clean-machine.sh langchain.

[Works with Claude Code, Codex CLI, Cursor and Gemini CLI; the Python and TypeScript SDKs; the OpenAI Agents SDK, Claude Agent SDK, LangChain, LangGraph, MCP, CrewAI, Browser Use, Pydantic AI, the Vercel AI SDK and OpenTelemetry]

Stable: Claude Code, the OpenAI Agents SDK, LangChain / LangGraph, the Claude Agent SDK and MCP. Experimental: Codex CLI, Cursor, Gemini CLI, CrewAI, Browser Use, Pydantic AI, Google ADK, Haystack, LlamaIndex, Microsoft Agent Framework, Strands Agents, the Vercel AI SDK, NVIDIA OpenShell, E2B, microsandbox, agentgateway, Wassette, LiteLLM's MCP gateway, Docker's MCP Gateway and the TypeScript SDK. In NVIDIA OpenShell sandboxes, Tracekit decides and signs each HTTP request OpenShell lets out, and signs OpenShell's own blocks, process events and policy changes into the same run. Setup: coding agents · OpenAI Agents SDK · Claude Agent SDK · LangChain / LangGraph · MCP · Wassette · CrewAI · Browser Use · Pydantic AI · Google ADK · Haystack · LlamaIndex · Microsoft Agent Framework · Strands Agents · NVIDIA OpenShell · LiteLLM · TypeScript · Vercel AI SDK · agentgateway · microsandbox · E2B · Docker MCP Gateway · OpenTelemetry · any other agent

Other ways in: coding agents, without uv, the why demo, the sample bundles, TypeScript

Coding agents: tracekit init --dev --v2 wires Claude Code's hooks to a dev signer; add --agent codex, cursor, gemini or opencode for the others (experimental). With Claude Code's sandbox on, Tracekit holds each unsandboxed retry for a person (Claude Code's sandbox); with Codex's, see what Tracekit sees and the settings to use (Codex's sandbox); with Gemini CLI's tool sandbox, Tracekit holds each sandbox expansion for a person (Gemini CLI's sandbox). Running sandbox-runtime's proxy on its own, Tracekit decides each request it forwards (experimental, sandbox-runtime). Sandboxed with agentsh? tracekit follow signs each decision agentsh logs, as it writes it (experimental, agentsh). Without uv: pip install tracekit-ai, then tracekit demo --server. --why (experimental) shows a held email whose cause is found by replay and cited by its signed record:

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

From a checkout, the shipped sample bundles (v1) check with the verifier alone (pip install --no-deps tracekit-ai is enough), and python examples/v2/langchain/agent.py --scripted runs a LangGraph agent with a mock model:

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

TypeScript needs Node 18 or newer: npm install @cygnuxlabs/tracekit, and npx @cygnuxlabs/tracekit up starts a dev signer without Python on Apple Silicon Macs, Linux and Windows (TypeScript SDK). Python 3.9 to 3.13; the framework integrations need 3.10 or newer.

What it proves

Three guarantees. They're related, but one doesn't give you the others, and each needs something different.

GuaranteeWhat you getWhat it needs
Evidence integrityA record that was edited, deleted, swapped or inserted fails verification at that recordOnly the signed log. Cutting off the end of the log, or re-signing it with a stolen key, takes a witness to catch
Execution controlEach call is checked before it runs. A denied call is blocked; a held call runs only after a yes, with exactly the arguments that were approvedThe call goes through Tracekit: an SDK, a hook or a gateway. Code that skips it isn't stopped
Independent assuranceAn operator who rewrites or forks its own log is caughtA witness the operator doesn't control, and a monitor. Both are experimental, and no public witness is running yet

Limits

  • Dev mode protects nothing against an agent that runs as you. Dev runs say isolation: same-user (FAQ).
  • A verified run proves the record is intact: not intent, not that a reported tool result is true, and not that every action was captured (FAQ). tracekit analyze --v2 compares what was asked, what the model said and what ran, but what the model said is its own account, and findings are an opinion beside the integrity, never part of it (findings).
  • Actions outside the capture path leave no record, such as a subprocess a hook never sees and no kernel sensor import covers, or code that skips the adapter (adapters).
  • Policy rules match text and tool names. A determined agent can reword a command; the protection is the signer's isolation (policy reference).
  • Commitments hide content, not timing, sizes or counts (privacy).

What each deployment guarantees, from dev mode to a signer the agent can't reach: guarantees. Every limit, with what to do about it: limits. How it maps to the EU AI Act, ISO/IEC 42001, the NIST AI RMF and OWASP: compliance.

What's in it

One signer. The core is stable and is hardened first. The rest ships in the same package as experimental: it works and is tested, but may change between releases (what's stable).

CoreWhat it doesMeasured
RecordEvery tool call, decision and result in one signed hash chain per run. A lost event becomes a signed gap, never silence6 of 8 tamper attacks caught by the log alone (E1)
DecideAllow, deny, or hold each call for a person, before it runs. Packs for shell, files, SQL, HTTP, cloud CLIs, browsers, email, messaging, payments, secrets and MCP766 of 766 harmful calls stopped, 1 false alarm in 834 (E17)
ApproveA held call runs only after a yes from the command line, bound to its exact arguments and used once (approvals)Edited arguments, a replayed snapshot or another run's approval: refused, in the contract tests every stable framework integration runs
Provetracekit verify checks a run's file offline against keys you pinned8 of 8 insider attacks caught (E8)
Watchtracekit view: every run verified, blocked and held calls, approvals, gaps, replay and a run review (viewer)Not measured
ExperimentalWhat it doesMeasured
WitnessIndependent witnesses cosign each checkpoint; a monitor watches the log for rewrites and forks8 of 8 tamper attacks caught with a witness (E1)
Cross-checkThe signer compares the calls the model asked for, as an LLM gateway or the session transcript saw them, with the calls the agent reported. A skipped hook or a made-up call is flagged12 of 12 seeded discrepancies flagged, 0 false (E10)
ContainSigned incidents hold or quarantine a run. Tools run on credentials the agent never holds (executor, MCP gateway). An egress observer flags traffic no call explains. A kernel sensor import records the processes, connections and file writes Tetragon or Falco saw8 of 8 containment and 10 of 10 detection checks (E17)
ExplainWhere each argument came from, and tracekit why: which input caused an action, found by replaying the run without it6 of 6 true causes named, 0 false blames, one 7B model, small sample
Checktracekit analyze --v2, signed: an action with nothing said before it, an edit of a file nobody named or said they were changing, a write outside the project, a broken "don't touch X", data sent out, files deleted or a package added without telling the person, a prompt line the harness never submitted, and how much of the run's reasoning could be read (which agents' reasoning is readable); --review adds a reviewer model's second opinion (warn only). Live constraints hold the call that would break "don't touch X" for approvalOn a blind pool scored once (E20 pool v3, synthetic; the final review's fixes to the checks after that run moved none of its numbers): unrequested edits behind generic, sealed or reviewer-addressed cover text, or named innocently, caught in every session when no request names the file; after a "don't touch X", 79-100% by cover (67-92% held before the edit ran); a failed test run claimed as passing, 86%; a file sent out or deleted, or a package added and pushed, with nothing said of it, 96-100% by cover, except a file sent out under an innocent mention of it (33%); an appended prompt line flagged every time; 5 false findings and 1 call held in 1,812 honest calls. On the development pools, read while fixing the checks, after a "don't touch X": 88-96% on pool v2 (29-75% before) and 54-92% on pool v1
More approversA web page with passkeys, Slack, or a reviewer agent that approves within bounds7 of 7 abuse cases against agent approvers caught (E18)

Proof

Our own experiments: small, synthetic and written by us. Nothing rounded up. The misses stay in.

[Tamper detection, 60 trials per attack. The signed log alone catches editing, deleting, swapping or inserting a record, re-chaining without the key and a torn last line in 60 of 60 trials, and misses truncating the tail and re-signing with the key (0 of 60). With a witness, all eight are caught in 60 of 60.]
ExperimentSetupResult
E1 tamper detection120-record signed logs, 8 attacks, 60 trials each, re-run on 1.26 of 8 caught by the log alone, 8 of 8 with a witness
E8 insider attacksReal unprivileged users against a Linux system-mode signer: a decoy signer, a stopped signer, a swapped policy, fabricated runs8 of 8 caught, a merge gate on every pull request
E17 policy packs766 harmful and 834 benign tool calls in 11 classes, decided by both regex engines766 of 766 stopped; 1 false alarm, a draft email held for a person
E21 policy robustness420 harmful and 432 benign calls written blind to the rules; 130 developer-session callsserver pack: 211 of 420 stopped or held on the one blind run, 248 after rules were added that target the pool (read since); 18 of 432 false alarms, 2 of 130 in sessions; p99 185 µs
E10 reconciliation30 runs, 12 with a seeded discrepancy: a missing hook, a fabricated call, changed arguments12 of 12 flagged, 0 false positives
E9 overheadSigner round trip over a Unix socket, file storage, macOS quick run0.45 ms p50, 0.91 ms p99 per call; 5,356 events/s
E3 the v1 regex gate, on a rougher set16 harmful and 20 benign calls written after the rules11 of 16 caught, 1 false alarm. Rules are tripwires, not a sandbox

The two E1 misses are the design: a log can't see its own tail cut off, and whoever holds the key can re-sign it. Only a copy of the head held elsewhere, a witness, catches those, so an unwitnessed run verifies as dev. The test sets were written by us, and no one outside has reviewed the threat models yet. Every experiment, and what isn't measured: evaluation · technical report.

How it works

[1. Your agent, through its SDK or hook, asks the signer to decide each call; it holds a run token, never a key. 2. The signer, out of the agent's reach, allows, denies or asks a person, and signs every call, decision and result into one hash chain per run. 3. Witnesses cosign each checkpoint. 4. Each run exports as run.tkb, which tracekit verify checks offline: VERIFIED, or FAILED at the record that changed.]
  • The agent never holds a signing key and never assigns sequence numbers.
  • Each record is signed and carries the hash of the one before it, so a changed byte fails verification at that record.
  • Nothing the agent reports about itself is trusted: not its isolation, its fail mode, gaps, or who approved a call.
  • Who can rewrite the log decides what a run is worth, so put the signer where the agent can't reach it. The agent's code is the same in every mode; TRACEKIT_SIGNER points it at the signer.
Where the signer runsWho can reach the keys and logRecorded isolation
Laptop devthe agent's own usersame-user
Laptop system mode (Linux; macOS experimental)root and the signer's OS userseparate-user
Container or Kubernetes sidecarthe signer's uid and the node's administratorseparate-user
Docker Compose stack (deploy/compose/)the Docker host's administratorsseparate-user
Central signer over HTTPSthe signer host's administratorsremote

The operator who runs the signer could still rewrite its log with its own key; an independent witness and a monitor make that visible. Each mode end to end: deployment. The full model: architecture, laptop and server threat models.

Is it for you?

Use Tracekit whenA plain tracer is enough when
Your agent acts on real systems: a shell, files, databases, email, payments, the cloudIt only reads, or runs in a throwaway sandbox
Some calls must be stopped or held for a person before they runSeeing what happened afterwards is enough
Someone outside the team has to trust the record: a customer, an auditor, an incident reviewOnly your team reads the logs, to debug

For debugging a prototype, a tracer such as OpenTelemetry, Langfuse or LangSmith is the right tool. Tracekit doesn't replace one; it's the record you can hand to someone who doesn't trust the agent. How it compares with tracers, guardrail libraries and other tamper-evident logs, and when it's the wrong choice: comparisons.

Pilot it with us

Running an agent that acts on real systems, with someone who has to sign off on it: a customer, an auditor, an insurer? We'll set up Tracekit with you for two weeks, free: one agent, on your machines. At the end you have a verified evidence file for every run and a written review of what the agent did that you didn't expect. Email [email protected] or open a pilot request.

Commands

sh
tracekit demo --server                      # allow, deny, approve, then a tampered copy fails verificationtracekit up                                 # start the dev signer, or find the running onetracekit last                               # export your latest run, pin the dev key, verify ittracekit view --dev                         # every run, verified: calls, decisions, gaps, replay, whytracekit approvals list                     # calls held for a person; tracekit approvals approve IDtracekit export --v2 --run ID -o run.tkb    # one run as one .tkb filetracekit verify run.tkb --trust trust.json  # offline, against the keys you pinned in trust.json                                            # (tracekit signer trust -o trust.json, or the one tracekit last wrote)tracekit policy lint policy.yaml            # check a policy before the signer loads ittracekit doctor                             # check this setuptracekit init --dev --v2                    # wire Claude Code's hooks; add --agent codex, cursor, gemini or opencode

Nothing to install for whoever checks a run: the browser verifier, one page, takes the .tkb and its trust file, sends nothing anywhere, and says VERIFIED, FAILED or UNVERIFIABLE with what it means and what to do next.

The evidence format

  • Specified. Evidence format v2 aims to be precise enough to write an independent verifier, with normative test vectors.
  • Built on standards. Records are signed with Ed25519 over RFC 8785 canonical JSON. Each log is an RFC 6962 Merkle tree, the structure Certificate Transparency uses. Checkpoints are C2SP signed notes, and witnesses cosign them per C2SP tlog-cosignature.
  • Self-contained. A .tkb file is a zip of records, inclusion proofs, checkpoints and the policy snapshots that decided the calls. It holds no verification code.
  • Old files keep verifying. Formats only grow, each format's verifier is frozen, and an older verifier reports a newer file UNVERIFIABLE (needs tracekit >= x), never FAILED. Verify such a file with uvx --from "tracekit-ai>=x" tracekit verify run.tkb --trust trust.json, npx -y @cygnuxlabs/tracekit@latest verify run.tkb --trust trust.json (Node 20.12 or newer), or the browser verifier, which checks it in your browser and sends nothing. From 1.4.0, an addition an older verifier can leave unread is non-critical: the bundle verifies, and the report names what that verifier didn't interpret.

Verify a v1 bundle in GitHub Actions with uses: Cygnux-Labs/Tracekit@main (bundle: and key: or witness:). require-anchor defaults to true, so an unanchored bundle fails the step; set require-anchor: "false" to only report it.

Contribute

Each of these is useful on its own, and none needs to know the whole codebase:

  • Write a verifier in another language. The evidence format is specified and has test vectors. A Go or Rust verifier written from the spec alone is the best test that the spec is complete.
  • Find a harmful call the packs let through. Add it to tests/data/policy/deny/ with a rule that catches it; E17 runs every case.
  • Run Tracekit on your own agent and report what broke. Doing that with two open-source agents found real bugs (case study).
  • Add a framework. An integration is done when it passes the adapter contract.
  • Try to break it. Find a tamper or a bypass that E1 and E8 miss, and report it privately as SECURITY.md describes. Everyone who finds one is named in the hall of fame unless they ask us not to.

To start: make install, then make check (contributing). Smaller tasks are labelled good first issue. Everyone taking part follows the code of conduct.

Docs

ToStart here
Read your first verify reportTracekit for auditors
See every step on a clean installwalkthrough (recorded on 1.2.0) · recorded demos · viewer tour
Wire up an agentv2 quickstart · coding agents · TypeScript SDK
Put the signer out of reachdeployment · compose · container · Kubernetes · agent-sandbox · doctor
Decide callspolicy reference · approvals · incidents · webhooks
Check evidencereading a verify report · auditor guide · witnesses · monitor · compliance mapping
Ask why an action happenedtracekit why · its architecture
Understand the designhow Tracekit works · architecture · evaluation · technical report · case study
Know what's stablesupport · limits · FAQ · security checklist · changelog
Run the v1 laptop signercoding agents · signing · v1 adapters

License

MIT, Copyright Cygnux Labs. This is 1.5.2, and 1.x is the supported line. Report vulnerabilities privately as SECURITY.md describes.

Cite

The paper: Tracekit-v2-paper.pdf (arXiv:2609.35659).

bibtex
@misc{ghosh2026tracekit,  author        = {Bravish Ghosh},  title         = {Tracekit: Tamper-Evident Intent-Reasoning-Action Auditing for AI Agents},  year          = {2026},  eprint        = {2609.35659},  archivePrefix = {arXiv},  url           = {https://arxiv.org/abs/2609.35659},  note          = {Code: \url{https://github.com/Cygnux-Labs/Tracekit}}}

Agents can edit logs. They can't hide the edit. A star costs nothing and helps other teams find Tracekit.

Website · Evaluation · Limits · Contributing · Issues

来源:README.md,提交 93857b0

工具

0
该服务器需要 API 密钥等凭据,因此 SourceWeft 无法在没有凭据的情况下读取其工具,也未收录。

版本历史

1
  1. v1.3.0最新Oct 18, 2026

评分

已满足适用检查项的 60%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式必需10 分
  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分