Repository navigation
Concepts Witnesses and Monitoring
A signed log can prove a lot about itself, but not everything. Two attacks can't be seen from inside: cutting off the end of the log, and rewriting it with the signing key. Both need someone outside who saw an earlier state. Tracekit uses the same design as Certificate Transparency for this: independent witnesses that cosign checkpoints, and a monitor that reads the log. Both are experimental.
In the tamper experiment (E1), the signed log on its own catches edits, deletions, swaps, forged insertions, re-chaining without the key and torn lines in 60 of 60 trials each. It catches truncating the tail and re-signing with the key in 0 of 60: a shorter log still checks out, and whoever holds the key can rebuild a consistent one. With a witness holding checkpoints taken every 10 records, all eight attacks are caught in 60 of 60.
How often you checkpoint matters. Against an attacker who holds the key and edits one record, then re-signs everything after it, a witness catches the edit every time at checkpoints every 1, 5 or 10 records, 90% of the time every 25, and 82% every 50 or 100: records after the last witnessed checkpoint are the window an attacker can still use.
The signer sends each new checkpoint to its witnesses using the C2SP tlog-witness protocol, with a consistency proof from the tree size the witness last cosigned.
- The witness checks the checkpoint's signature with the log key it registered.
- It checks the consistency proof: the new tree must extend the one it saw before.
- If both hold, it returns a cosignature with its own timestamp, and stores the new size.
A witness never sees records, only sizes and root hashes, so it learns nothing about what agents did. It never cosigns
a fork or a rollback, because neither extends the tree it already holds. If a witness is behind or doesn't know the
log, the signer resends from the witness's size or registers first. Witnesses that stop answering for five minutes
become a signed witness_failed gap.
At startup the signer asks each witness for the last size it cosigned. If the local log is shorter than what a witness
has seen, someone rolled the log back: the signer writes trace.tamper{rollback} and refuses client writes until an
operator acknowledges it.
| Class | Who runs it | Counts toward witnessed
|
|---|---|---|
operator |
The party running the signer | No: raises assurance to local only |
customer |
The customer or auditor | Yes |
tracekit |
The Tracekit project | Yes |
public |
A public witness | Yes |
The class is set in the verifier's trust config, not by the witness. A public witness server is written (open registration with rate limits) but not deployed yet, so today independent witnessing means running or arranging one. Setup: witnesses.
At most once an hour, the signer can also anchor a checkpoint in Sigstore's public Rekor log, with an RFC 3161 timestamp. A verifier checks the anchor offline against Sigstore's trusted root. An anchor counts as an independent cosignature and gives an independent time: the verify report shows the earliest independent anchor. Rekor entries are public and permanent.
Witnesses check that the tree only grows; they don't read it. tracekit monitor does. It follows the log's public tiles
and checks:
- no rollbacks and no forks;
- both chains are intact and the tree rebuilds to the signed root;
- each run has exactly one
run.registeredand onerun.final, and nothing after it; - no key appears without being announced;
- registry entries and Rekor anchors match the log.
It signs a report with the size and root it checked, the rules it ran and any conflicts. A verifier given a fresh,
conflict-free report from a pinned independent monitor reaches witnessed+monitored. The monitor catches one thing
witnesses can't: an operator showing two different forks to two different verifiers. Setup: monitor.
There is no consensus, no token and no mining. It is transparency logging: one writer, a Merkle tree, signed checkpoints, and independent witnesses and monitors, as in Certificate Transparency and Sigstore. The difference in Tracekit is that the party being logged (the agent) never holds the key, and the operator running the signer is treated as a separate adversary that witnesses and monitors keep honest.
Witnesses · monitor · the witness client:
tracekit/tlog_witness.py · anchors: tracekit/anchor/
Previous: Verification and assurance · All concepts · Next: Policy
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