Repository navigation
Quickstarts MCP
Every tool call is decided by the v2 signer before it runs and recorded after, as a signed event. This page adds it to the agent you have in three steps. It uses the dev signer, which runs as your own user (see what dev assurance means).
pip install tracekit-ai 'mcp>=2.3,<2.4'import tracekit; tracekit.instrument() # first
import asyncio
from mcp import Client, StdioServerParameters
async def main():
async with Client(StdioServerParameters(command="my-mcp-server")) as client:
result = await client.call_tool("create_issue", {"title": "..."}) # recorded as mcp:<server>/create_issue
print(result.content)
asyncio.run(main())Every ClientSession.call_tool goes through the signer, whichever client or transport made the session. A denied
call comes back as a result with isError: true and the refusal as its text. An ask waits up to five minutes in
call_tool for a person to decide. The coding pack only flags MCP calls; write your own policy for real tools.
tracekit lastIt exports the most recent finished run, pins the dev signer's key, verifies the bundle and says where it is (the v2 quickstart).
from tracekit.integrations.mcp import TracekitSession
from tracekit.sdk.client import Client
client = Client()
run = client.register_run({"agent": {"name": "my-agent"}})
session = TracekitSession(session, client, run) # an initialized ClientSession; mcp 1.x: add server="<name>"
result = await session.call_tool("create_issue", {"title": "..."}) # recorded as mcp:<server>/create_issueA denied call comes back as a result with isError: true and the refusal as its text. The coding pack only flags MCP
calls; the example's deny and ask come from the dev policy's demo rules (TK-DEMO-DENY, TK-DEMO-ASK). Write your own
policy for real tools.
An offline run of all this (a mock model, no API key), with an approval: python examples/v2/mcp/agent.py --scripted from a checkout.
[PASS] manifest — every file is listed with its SHA-256 and nothing else is in the bundle
[PASS] checkpoint — tracekit.local/... at tree size 12, signed by its pinned log key
[PASS] witness quorum — 0 pinned cosignature(s), 0 required
[PASS] signatures — 11 record(s), keys valid at their position
[PASS] run chain — run '...' of tenant 'default', contiguous from run_seq 0
...
Integrity: VERIFIED.
Assurance: dev; records ed25519; checkpoint Ed25519 only (...); no witness cosignature; approvals: self; ...
Integrity: VERIFIED means every record was signed by the log key in trust.json, the run is one unbroken chain, and a
checkpoint signed by that key includes it: nothing was edited, dropped or reordered after signing. Change one byte of
the bundle and it reads Integrity: FAILED, naming the check (tracekit demo --server shows this). Assurance: dev
says no pinned witness cosigned the checkpoint and the approval was a self-approval. The v2
quickstart explains every line.
- System mode runs the signer as its own OS user, so the agent can't reach its keys, store or policy, and approvals come from another account: system mode.
-
Witnesses cosign the signer's checkpoints from another host, so a rolled-back or forked log shows:
witnesses. Pin them in the trust config and the report reads
Assurance: witnessed. -
Your own policy: the dev signer uses the coding pack plus two demo rules (
tracekit/policy2/packs/dev.yaml); a configured signer takespolicy:insigner.yaml. - Reference: the MCP integration, with every option and what it doesn't cover.
Generated from docs/ at v1.4.1. Edit the docs in the repository, not here.
Get started
- Quickstart: the v2 signer
- Quickstarts
- Quickstart: Claude Agent SDK
- Quickstart: a custom agent
- Quickstart: LangChain and LangGraph
- Quickstart: MCP client
- Quickstart: OpenAI Agents SDK
- Coding agents other than Claude Code
- tracekit doctor
- Walkthrough: Tracekit end to end
How it works
- How Tracekit works
- Overview
- The life of a tool call
- The evidence format
- Verification and assurance
- Witnesses and monitoring
- Policy
- Approvals
- Detection and containment
- Capture and completeness
- Custody
- Provenance and tracekit why
- Deployment and isolation
- Storage, durability and performance
- Integrations
- Security model
- Architecture
- tracekit why: architecture
Integrations
- Integrations
- Adapters
- OpenTelemetry
- Remote clients
- Kubernetes agent-sandbox
- agentgateway
- agentsh and Tracekit
- Browser Use
- Claude Agent SDK
- Claude Code's sandbox
- Codex's sandbox
- CrewAI
- Docker MCP Gateway
- E2B
- Falco
- Gemini CLI's sandbox
- Google ADK
- Haystack
- LangChain v1
- LiteLLM
- LlamaIndex
- MCP client
- microsandbox
- Microsoft Agent Framework
- OpenAI Agents SDK
- NVIDIA OpenShell
- Pydantic AI
- sandbox-runtime's proxy on its own
- Strands Agents
- Tetragon
- Vercel AI SDK
- Wassette
Policy and approvals
- Policy reference
- Approvals
- Findings
- Reading the model's reasoning
- Incidents and containment
- Webhooks
Deploy and operate
- Deploying the signer
- The signer as a container
- The signer on Kubernetes
- The compose stack
- Identity
- Tool executor
- MCP gateway
- LLM gateway
- Egress observation
- Witnesses
- Log monitor
- Record-key issuer
- Signer observability
- Viewer
- tracekit why: causal investigation and replay
- Migrating
- Platforms
Verify the evidence
- Reading a v2 verify report
- Evidence format v2
- Auditor guide
- Sample evidence bundle
- Signing
- What Tracekit guarantees
Security and privacy
- Threat model: the v2 signer
- Threat model: the v1 laptop signer
- HTTP security checklist
- Threat-model review packet
- Privacy
- Known limits and trade-offs
- What's stable
Compliance
- Compliance mapping
- EU AI Act
- ISO/IEC 42001
- NIST AI RMF and the Generative AI Profile
- OWASP Top 10 lists for LLM and agentic applications
Evaluation
Demos
- Demos
- Agent approvers within bounds
- Completeness and tamper evidence
- Detection and containment
- Network coverage: an egress observer
- Guardrails: allow, deny, or ask a person
- MCP tools, gated and recorded
- Prompt injection held by provenance
- Why: which input caused the action
Help