This release is a pre-release and may not be stable for production use.
Tracekit puts a signer between your agent and its tools: before each tool call runs, the signer decides it against
your policy, and it records every call as a signed, hash-chained event the agent can't edit. Checkpoints of that log go
to witnesses you choose, so even the signer's operator can't quietly rewrite it. A run exports as a .tkb bundle that
anyone can verify offline, with a report that says what it proves and what it can't.
The promise, and its limits
- The agent never holds a signing key or assigns a sequence number; nothing it reports about itself (isolation, fail mode, gaps, who approved) is trusted.
- A missed or lost event becomes a signed gap, never silence. An edited, dropped, reordered or added record fails verification.
- Who can rewrite the log decides what a bundle is worth. A dev signer runs as your own user, so an agent that runs
commands as you can rewrite it: dev bundles say
isolation: same-userandAssurance: dev. Protection against the agent needs a signer it can't reach (deployment modes); protection against the operator needs an independent witness and a monitor. - A verified bundle doesn't prove intent, that every action was captured, or that a tool result the agent reported is true. FAQ and limits lists them all; laptop and server threat models map each to its attacker.
Quickstart (60 seconds)
A dev signer, a LangGraph agent with a mock model (no API key), and a verified bundle:
git clone https://github.com/Cygnux-Labs/Tracekit && cd Tracekit
python3 -m venv .venv && . .venv/bin/activate
pip install '.[signer]' 'langchain>=1.4,<1.5' 'langgraph>=1.2,<1.3'
python examples/v2/langchain/agent.py --scripted
The first call starts a dev signer in the background. One call is allowed, one denied, one held until a second process approves it; then the example pins the signer's key, exports the run and verifies it:
tracekit signer trust -o trust.json
tracekit export --v2 --run <run id> -o run.tkb
tracekit verify run.tkb --trust trust.json # Integrity: VERIFIED. / Assurance: dev; ...
tracekit view --dev # browse the runs: verdicts, denials, approvals, replay
Other frameworks: OpenAI Agents SDK, Claude Agent SDK, MCP client, a custom agent. The v2 quickstart explains each step.
Without a checkout, the same loop in a temp dir (with a witness cosignature and a tampered copy that fails), and Claude Code's hooks wired to a dev signer:
pip install 'tracekit-ai[signer]'
tracekit demo --server # exit 0
tracekit init --dev --v2
Or check the shipped sample bundles (v1) with the verifier alone:
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
Deployment modes
The agent's code is the same in every mode; TRACEKIT_SIGNER points it at the signer.
| Mode | Who can reach the keys and log | Recorded isolation |
|---|---|---|
| Laptop dev | the agent's own user | same-user |
| Laptop system mode (Linux; macOS experimental) | root and the signer's OS user | separate-user |
| Container or Kubernetes sidecar | the signer's uid and the node's administrator | separate-user |
| Central signer over HTTPS (or Docker Compose) | the signer host's administrators | remote |
Each mode end to end, with its commands, its tracekit doctor check and the assurance its bundles reach:
deployment guide. Moving from the v1 signer or from
a laptop to a server: migration.
Docs
- How it fits together: architecture, evidence format v2
- Running it: deployment, doctor, witnesses, monitor, viewer, observability, privacy
- Deciding calls: policy reference, approvals, LLM gateway, OpenTelemetry
- Checking evidence: reading a verify report, auditor guide, evaluation, technical report, FAQ and limits
- Releasing: launch checklist for 1.0
- The v1 laptop signer (
tracekitd,tracekit init --dev,tracekit demo,tracekit observe) and its bundles keep working: coding agents, signing, platforms
Use in CI
Verify a v1 bundle in a GitHub Actions workflow:
- uses: Cygnux-Labs/Tracekit@main
with:
bundle: run.tkb
key: keys/signer.pub # pin the signer; or witness: git:/path/to/clone
require-anchor defaults to true, so an unanchored bundle fails the step; set require-anchor: "false" to only
report it.
Contributing and security
CONTRIBUTING.md: make install, then make check.
Report vulnerabilities privately as described in SECURITY.md.
Licence
MIT, Copyright Cygnux Labs. See LICENSE.
Metadata
Release files for tracekit-ai 1.0.0rc2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| tracekit_ai-1.0.0rc2.tar.gz | 1.7 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| tracekit_ai-1.0.0rc2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 2.3 MB
Release files / tracekit_ai-1.0.0rc2.tar.gz
| Download URL | tracekit_ai-1.0.0rc2.tar.gz |
|---|---|
| Size | 1.7 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f176ee8c074bd0b8b9e87a88dfc454c98020c04af1926f728bc0db30f6ba9f4e
|
|
BLAKE2b-256 checksum How to use checksums |
684333fa83291515a55f340fc970f37c69d666e11a4c1d25be32f6314811ec49
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 10, 2026.
Transparency logRelease files / tracekit_ai-1.0.0rc2-py3-none-any.whl
| Download URL | tracekit_ai-1.0.0rc2-py3-none-any.whl |
|---|---|
| Size | 579.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c9e627bf714f12de218b2edf4a6f564f4df6814ddb39770ee6cfd4e050c8ed23
|
|
BLAKE2b-256 checksum How to use checksums |
6d4a47d7fd8ef05588256e858888cbe85d377493b6609cc20581f6d75a3cd902
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 10, 2026.
Transparency log