PaperlayerView exact revision on arXiv

Source-linked AI summary

Tracekit: Tamper-Evident Intent-Reasoning-Action Auditing for AI Agents

Bravish Ghosh

arXiv:2609.35659v2cs.CEcs.CR

TL;DR

Agent records can be rewritten by the agent or operator, leaving action reviews without independently checkable evidence. TRACEKIT routes calls through an isolated signer and records evidence for offline verification. Its evaluation reports important limits, including policy misses on a blind pool.

  • Problem

    Agent and operator-held records can be rewritten and may not show missed actions or connect an action to the request and model statement it served.

    Source: §1 · p. 2

  • Method

    An out-of-reach signer decides and signs tool calls into a transparency log whose checkpoints witnesses can cosign, producing offline-verifiable run evidence.

    Source: §1 · p. 2

  • Results

    21 experiments retain reported misses, including policy failures on blind wording, text checks that do not generalize, and an unevaluated reviewer-model arm.

    Source: §1 · p. 3

  • Takeaways & Limitations

    TRACEKIT’s conclusion is that it answers incident-review questions about actions, requests, and model statements while stating what its evidence cannot establish.

    Source: §10 · p. 35

    Policy rules remain a tripwire: E21 found half of a blind pool getting through, so protection rests on signer isolation rather than the rules.

    Source: §9.1 · p. 34

Abstract

from arXiv · show

AI agents run shell commands, edit repositories, send email and move money with their operators' credentials, yet the record of what they did is usually a log the agent, or whoever runs it, can edit. We present Tracekit (open source, MIT, version 1.4.1), which turns each agent run into evidence a third party can check offline. A signer that the agent cannot reach outside dev mode decides every tool call against its own policy before it runs, and signs the call, decision and result as Ed25519 records in a per-run hash chain inside an RFC 6962 Merkle tree whose checkpoints independent witnesses can cosign. A run exports as one .tkb bundle that two independent verifiers (Python, and TypeScript, also as a browser page) check against keys the verifier pins, reporting integrity and assurance separately. Disagreements between capture layers become signed records. Tracekit also records the person's request and what the model said before each call, holds calls that break a limit the request stated, compares what was asked, said and done, and finds which input caused an action by replay. Of 21 experiments: a signed log alone detects 6 of 8 tamper classes and a witness the other two; every insider attack in two suites is caught; the signer round trip is 0.45 ms median; no acknowledged record was lost in 60 kill -9 rounds; reconciliation flags 12 of 12 seeded discrepancies; the verifiers reject all 33 forgeries. Policy rules are a tripwire, not the boundary: they stop 570 of 570 harmful calls in our corpus but 211 of 420 (50.2%) written blind to them; the protection is a signer and credentials the agent cannot reach. On a held-out pool, a failed test claimed as passing is found in 86% of sessions with 5 false findings in 1,812 honest calls, and replay names the planted cause in 6 of 6 confirmed harmful runs with a 7B model.

1 Introduction

TRACEKIT addresses agent records that agents or operators can rewrite and that do not connect actions to requests or model statements. It puts a signer outside the agent’s reach in charge of decisions and evidence, then adds intent–reasoning–action checks, capture reconciliation, and replay-based attribution.

Approach

  • The signer decides each tool call before execution and signs its decision and result; outside dev mode, the agent cannot reach its keys.The paper’s version 2 rebuild addresses version 1’s agent-writable ledger and transcript by committing the request and model account through the signer.Source: §1 · pp. 2–3
  • A per-run Merkle log, checkpoints, and independent witnesses support offline verification that separates record integrity from who vouches for it.The paper also describes a v2 evidence format and two independent verifiers that agreed on all 63 E22 bundles.Source: §1 · pp. 2–3
  • The signer records the person’s request and the model’s stated account beside each action, enforces readable request limits, and signs analyzer findings separately from integrity.The analyzer compares what was asked, said, and done.Source: §1 · pp. 2–3
  • Capture layers are compared for disagreements, while replay removes suspect inputs to test which one caused an action.Detected discrepancies become signed records; the attribution method uses statistical tests.Source: §1 · pp. 2–3

The claim this paper defends

  • TRACEKIT’s stated claim is limited to what its capture path recorded and whether that record changed; intent and reasoning mean the request and model’s stated account, not their truth.Against the operator, the claim holds only for history an independent witness has seen, and the design claims detection rather than prevention.Source: §1 · p. 3

Evaluation

  • The evaluation covers 21 experiments and retains reported misses, including policy failures on a blind pool and text checks that do not generalize to unseen wording.The reviewer-model arm had not yet been run.Source: §1 · p. 3

2 Background and related work

TRACEKIT draws on tamper-evident logs, transparency systems, agent observability, and control methods, adapting them to evidence about agent actions. Its distinctions include who holds signing authority, reconciling capture layers, and separating record integrity from assurance.

Tamper-evident logging

  • TRACEKIT applies hash chains, positional key retirement, and witnessed tree heads to agent actions, where the agent is separated from the logging party.Unlike prior schemes described here, the agent is never given a key outside dev mode, while the operator is modeled as a separate adversary.Source: §2 · p. 5

Transparency logs, Sigstore and C2SP

  • Transparency-log standards supply witnessed checkpoints, while TRACEKIT adds rules for action-record contents, writers, and visible missing records.It can anchor checkpoints in Rekor v2 with an RFC 3161 timestamp, described as experimental.Source: §2 · p. 5

Agent observability

  • Agent observability tools support debugging, but their records are not described as signed or independently witnessed; TRACEKIT imports OTLP traces only as proof of receipt.TRACEKIT exports its own records as OpenTelemetry spans carrying entry hashes.Source: §2 · p. 5

Agent evidence layers and control

  • Among agent-evidence systems, TRACEKIT distinguishes itself through pre-execution signer policy, reconciliation of capture layers, and separate integrity and assurance reporting.Its control framing treats model reasoning as testimony and uses input interventions for attribution rather than relying on the model’s account [10] [27] [43].Source: §2 · pp. 5–6

3 Threat model and guarantees

TRACEKIT separates integrity, completeness, execution control, and independent assurance, with distinct assumptions for each. Its protections depend on signer isolation and what independent witnesses have seen.

3.1 Two properties, pursued separately

  • Completeness is reported, not proven: TRACEKIT compares capture layers and records detected disagreements as signed gaps.Integrity instead concerns whether recorded events can be changed, deleted, reordered, or forged under the stated signer and witness conditions.Source: §3.1 · p. 6

3.2 Adversaries

  • The threat model names six adversaries and maps their reach to what TRACEKIT detects or stops, and what it does not.The passage identifies the table as the place where these distinctions are stated for each adversary.Source: §3.2 · p. 6

3.3 Invariants

  • The invariants keep the agent’s identity away from the store, keys, and policy, and keep signing keys and sequence assignment out of its process.Agent-controlled claims about isolation, fail mode, gaps, tampering, and approver identity are not trusted by signer or verifier.Source: §3.3 · p. 6, Table 4 · p. 7

3.4 Three guarantees

  • The paper treats its three guarantees as related but non-substitutable, with different requirements for each.The passage points to the table of guarantees and what each needs.Source: §3.4 · p. 7, Table 5 · p. 7

3.5 Where the signer runs decides what a run is worth

  • Deployment changes who could rewrite the log; the signer records measured isolation, not an agent’s claim.Persistent jobs and API keys are recorded only at creation, people persuaded to act are outside the record, and policy text can be reworded around.Source: §3.5 · p. 7, Table 6 · p. 8

4 System design

TRACEKIT routes tool calls through a signer that makes and records policy decisions, then packages the run for independent verification. It also reconciles capture layers and provides controls, integrations, and review tools around that evidence.

4.1 The signer and the life of a tool call

  • The signer evaluates each tool call before execution and signs its decision; completion must match the decision’s arguments, while outage behavior and missed calls are recorded.The signer assigns sequence numbers and writes records; only deny and ask decisions are remembered for retries.Source: §4.1 · p. 8

4.2 Evidence format v2

  • A .tkb bundle packages a run’s records, keys, proofs, checkpoint, and policy snapshots, but carries neither code nor trust configuration.Formats are versioned; an older verifier reports an unsupported newer critical entry as unverifiable rather than failed.Source: §4.2 · pp. 8–9

4.3 The verifier and its two verdicts

  • Python and independent TypeScript verifiers check bundles and report integrity separately from assurance; malformed bundles produce a failed check rather than a crash.The TypeScript verifier also runs in a self-contained browser page that sends nothing elsewhere.Source: §4.3 · p. 9, Figure 5 · p. 10, Figure 6 · p. 12

4.4 Policy, detection and approvals

  • Policy rules apply the strictest matching outcome, while sequence-based detection can notify, hold, or quarantine a run; approvals bind to exact arguments and are usable once.Live constraints can raise a policy decision to ask, never lower it.Source: §4.4 · pp. 9, 11, 12

4.5 Capture layers and reconciliation

  • TRACEKIT compares reports from capture layers and signs detected disagreements; with a mandatory gateway, a hidden call is recorded as reconcile.hook_missing.Run finalization lists reporting layers, and result verification can flag edited or premature tool results.Source: §4.5 · p. 13, Figure 7 · p. 13

4.6 Containment, custody and effects

  • Recording is not prevention, so TRACEKIT offers experimental containment and custody services, alongside stable Claude Code sandbox rules.The tool executor and MCP gateway provide capture paths for calls; the LLM gateway can detect edited tool results.Source: §4.6 · p. 13, Table 11 · p. 14

4.7 Integrations

  • An integration passes its adapter contract by testing decisions, retries, approval handling, rewritten identifiers, and argument substitution across stable integrations.Signer outages are tested separately.Source: §4.7 · p. 14, Table 12 · p. 14

4.8 The viewer

  • The viewer verifies runs as they load and presents signed records, alerts, decisions, commitments, and integrity and assurance summaries.Replay controls can step through records or jump to the next deny, hold, or gap.Source: §4.8 · p. 14

5 Intent, reasoning and action: what was asked, said and done

TRACEKIT records the person’s stated request, the model’s stated account, and actions so they can be checked together. It can hold calls that violate readable request limits and signs analysis findings separately from the integrity verdict.

5 Intent, reasoning and action: what was asked, said and done

  • TRACEKIT treats intent as the submitted request and reasoning as the model’s stated account, which is self-reported rather than proof of its real reasoning.The model’s account cannot clear a finding merely by mentioning an action; “why” is addressed through interventions.Source: §5 · pp. 14, 16

5.1 Recording the request and the model’s account

  • Hooks record submitted prompts and model messages, while the log commits to their content rather than storing the text by default.When enabled, the encrypted vault binds text to its record; the system also reports how much action reasoning could be read.Source: §5.1 · pp. 16–17, Table 13 · p. 17

5.2 Live constraints

  • The signer checks prompt-derived constraints against later calls and holds violations for approval; constraints can only tighten decisions, and uncertain readings are left unread.The “only change X” constraint is checked after the run, while a rejected held call never ran and is not a finding.Source: §5.2 · p. 17, Figure 14 · p. 19

5.3 Checking asked against said against done

  • The analyzer compares what was asked, said, and done, counts uncheckable cases rather than passing them, and can join machine-side effects when kernel-sensor events are available.Disclosure can clear an unrequested-edit finding, but merely mentioning a file cannot; a reviewer model’s second opinion is warn-only.Source: §5.3 · pp. 17–18, Figure 12 · p. 18

5.4 Signed findings

  • The signer writes each finding as a separately verifiable judgment that cites supporting records and remains outside the integrity verdict.The verifier reports whether a findings run is independent, unpinned, or self-asserted based on its author and the auditor’s trust configuration.Source: §5.4 · pp. 18–19, Figure 15 · p. 19, Table 14 · p. 20

6 Which input caused it: tracekit why

Tracekit why uses replay to test whether removing an input changes how often an action occurs, rather than only tracing whether the input reached it. Its causal conclusions are limited to the rerunnable program and task.

Tracing and graph

  • Argument provenance flags sensitive actions whose arguments appear only in untrusted content, while graph edges distinguish observed, inferred, and replay-tested links.Forward reachability over observed edges gives a blast-radius superset of what an input actually influenced.Source: §6 · p. 20

Replay and attribution

  • Replay removes a suspected input and estimates how often the target action changes across paired runs that differ only by that intervention.The method uses common seeds, recorded tool results, and corrected intervals and tests; it can require many discordant pairs to reach a verdict.Source: §6 · p. 21

Scope and decision replay

  • A causal verdict concerns how often the target happens in the recorded program and task; it does not establish the model’s internal reasons, and stubs may change behavior after unrecorded calls.Decision replay instead rebuilds a recorded model call’s context to measure the item’s direct effect on that call.Source: §6 · p. 21

Example investigation

  • For a rerunnable customer-service demo, removing vendor:portal/notes.md reduced send_email from 80% to 0% of replays (n=40; 95% interval for the drop 63 to 90 points).The note reached the executor through researcher → planner → executor.Source: §6 · pp. 21–22

7 Evaluation

The evaluation examines mechanism behavior across 21 experiments, an attribution benchmark, and a case study, including replay-based causal attribution, real-session capture and verification, and the optional SQL index. The experiments are small, synthetic, and author-written rather than broad evaluations across real agents and projects; threat models have not been externally reviewed, and the real-session experiment does not test whether the gate stops an injection.

7.2 Integrity and verifier tests

  • E1 shows that an unwitnessed ledger cannot detect a cut tail or a signer-key holder’s rewrite; E8 caught every tested insider attack, while E4’s verifier raised no exception on corrupted bundles.E4’s v1 witness misses include a cut at a witnessed checkpoint, reported as a warning that fails under --strict; v2 did not test an attacker holding the real signing key. E22 found and fixed a bundle-export failure above 64 MiB in version 1.4.Source: §7.2.1 · p. 23, §7.2.2 · p. 23, §7.2.3 · p. 24

7.3 Reconciliation and observation

  • Across 30 E10 runs, 12 of 12 seeded discrepancies were flagged with zero false positives; E11 detected tampering in 21 of 21 L1 sources, and all E19 egress-observer cases were as expected.With one layer, a hidden or invented call is invisible. E11 wrappers catch stores changed underneath the agent, but not an agent process that lies consistently.Source: Table 21 · p. 26, §7.3.1 · p. 26, Table 22 · p. 26

7.4 Latency, outages, and durability

  • E2 measured 70 ms median per PreToolUse hook and about 140 ms of hook time per tool call; E14 partitions added about 1,000 ms at p50 and p99 over a 2 ms baseline.E2 also found a full accept queue could make fail-open clients drop events; the queue was enlarged and client retries added. E15 tested kill -9 durability, but its page-cache-preserving setup does not test power-loss durability or the background-sync loss window.Source: §7.4.1 · p. 27, §7.4.2 · p. 27, §7.4.3 · p. 27

7.5.1 E17: policy packs, detection and containment

  • E17 denied or held all 570 harmful calls, held one benign call, and caught all 10 detection and 8 containment scenarios.E17 is a development corpus measuring rules against calls they were written to catch, not unseen calls.Source: §7.5.1 · p. 29, Table 29 · p. 29

7.5.2 E21: policy robustness on a blind pool

  • On E21’s first blind run, default rules caught 211 of 420 (50.2%) harmful calls, while strict.yaml caught 246 (58.6%).Rules were added after this run and the pool was subsequently read, so later E21 results do not measure performance on unseen calls.Source: §7.5.2 · p. 29, Table 30 · p. 29

7.4 and 7.5: Isolation, deployment, and approvals

  • E18 caught all seven tested agent-approver attacks; E12 tested cross-tenant isolation, and E16’s deployment checker is advice rather than evidence.E12’s tests require attempts either to be refused or to reach nothing belonging to the other tenant, with concurrent calls kept within their own runs.Source: §7.4.4 · p. 28, §7.4.5 · p. 28, §7.5.3 · p. 30

7.6.1 E20: asked, said and done

  • E20 found failed-test claims in 86% of held-out sessions and unrequested edits in every session across all phrase sets and covers.On the held-out pool, live constraints held edits for approval in 67–92% of sessions by cover (133 of 168 overall); honest calls produced five findings across 1,812 calls, with one held live. The reviewer-model arm was implemented but not run, and E20 included no real claude -p sessions.Source: §7.6.1 · pp. 31–32, Table 31 · p. 31

7.6.2–7.6.3 Text checks and causal attribution

  • E6’s text detectors caught only 29% of held-out fake-test paraphrases and 40% of push-denied paraphrases, while replay named the planted cause in 6 of 6 confirmed harmful runs.The attribution benchmark used Qwen 2.5 7B; replay produced no false blame when the planted document drove the harm, and called a weak refund-override effect inconclusive in two runs.Source: §7.6.2 · p. 32, §7.6.3 · p. 32, Table 32 · p. 32

7.6.3 Causal attribution

  • An earlier setup named the cause in only 1 of 10 harmful runs; sequential replay, constrained JSON, and “inconclusive” labeling addressed three identified failure modes.That run also found that removing an obvious injection decoy made escalation more likely, because the blatant injection had made the model cautious.Source: §7.6.3 · p. 32
  • At n = 30, replay named the true cause in all 61 harmful simulated runs; success fell to 69% at n = 10 and none at n = 5.This simulated model followed injections with fixed probabilities, testing the pipeline rather than a model; fewer than six discordant pairs could not reach significance at n = 5.Source: §7.6.3 · p. 32, Figure 23 · p. 33

7.6.4 E5 and E7

  • Across 12 real Claude Code sessions, all bundles verified against a git witness, but injections were ignored in all six injected runs, so gate efficacy was untested.Every run fixed its test and ended with run.end; the legitimate rm -rf build was never blocked.Source: §7.6.4 · p. 32
  • On a 1,000,001-event, 604 MB ledger, SQL index build took 36.2 s, every query finished under 1 s, and rebuilding returned identical rows.One run’s tool-call query took 1 ms and a full-text scan took 227 ms; the index is a convenience, not evidence.Source: §7.6.4 · p. 32

8 Case study: two open-source agents

A real-model integration of Tracekit into two open-source agents exposed capture and framework-hook bugs, alongside successful policy and provenance checks. The resulting records also identified design conditions needed for reliable reconciliation and tool decisions.

8 Case study: two open-source agents

  • The integrations followed customer-facing documentation, used fixed task sets with and without Tracekit, and compared signed records against each project’s own logs.Source: §8 · p. 33, Table 33 · p. 33
  • The Agents SDK’s streamed response path initially caused 12 of 12 honest tool calls to be flagged as fabricated; after the capture fix, the count was 0.The verifier had not recorded the model response that requested those calls.Source: §8 · p. 33
  • CrewAI ran a policy-denied tool when the signer was unavailable because its hook swallowed the raised exception.The authors’ rule is that a framework gate must block on any exception.Source: §8 · p. 33
  • Passing the model’s call id into hooks paired all 33 calls with zero reconciliation findings, replacing 66 false findings from invented ids.Source: §8 · p. 33
  • A long-running chat server initially mixed conversations into one run; following the current run preserved policy and provenance checks, while two tools lacked target-defining arguments.A denied account closure and rejected deletion did not run; an approved refund ran once, and an email using an address from an untrusted ticket was held. The authors recommend that consequential tool arguments name their targets.Source: §8 · p. 33

9 Discussion

The discussion traces Tracekit’s redesign from an agent-writable ledger to a separated signer and layered evidence, while distinguishing integrity from completeness and assurance. It also sets out policy, analysis, deployment, and evaluation limits alongside future work.

9.1 From version 1 to version 2

  • Version 2 moves signing and sequence assignment to a separate signer because an agent-readable key would still let the agent rewrite the ledger.The signer records its measured isolation in reports; E8 tests this property on every pull request.Source: §9.1 · p. 34
  • Multiple capture layers and signed disagreement records address completeness, but one layer cannot reveal a hidden call.The authors frame this as a discipline rather than proof of completeness.Source: §9.1 · p. 34
  • Separate integrity and assurance verdicts make clear that intact same-user runs still have same-user isolation and dev assurance.Source: §9.1 · p. 34
  • E21 found that policy packs still missed half of a blind pool, so the authors treat policy as a tripwire and custody of credentials as the stronger control.The packs include a bounded shell parser, two engines that must agree, argument-value provenance, and coverage of 11 tool classes.Source: §9.1 · p. 34
  • E6 text detectors fell from 100% on their own phrasings to 29–40% on held-out paraphrases, motivating blind-pool testing for text checks.E20 demotes a pool to development once it has been read.Source: §9.1 · p. 34
  • Replay tests whether an action still occurs after removing an input, but costs hundreds of model calls and requires a re-runnable program.The authors describe the result as an attribution with an interval; a model’s account of its reasoning is testimony [10] [43].Source: §9.1 · p. 34

9.2 Limitations

  • Completeness and isolation remain bounded: same-user deployments expose keys, harness binding has holes, and actions crossing no capture layer leave no record.Services capture is specified but not shipped, and tool results remain agent-reported unless a gateway verifies them.Source: §9.2 · p. 35
  • Witnessing, analysis, and evaluation also have limits: unwitnessed history can be rewritten, findings are judgments, and tests are mostly synthetic and author-written on one machine.Future work includes public witnesses and monitors, adversarial bypass studies, broader reviewer-model and attribution tests, service capture, and external review.Source: §9.2 · p. 35, §9.3 · p. 35

10 Conclusion

Tracekit places an agent’s actions in a signed, offline-verifiable record, with guarantees stated per deployment and limitations kept visible. Within those limits, it supports incident review of actions, requests, stated reasoning, and input attribution.

10 Conclusion

  • Tracekit signs decisions, approvals, results, and detected capture-layer disagreements into a transparency log that witnesses can cosign, then exports bundles for offline verification against chosen keys.Its stated guarantees are deployment-specific; the log alone cannot see a cut-off tail, policy rules miss half of a blind pool, and text checks depend on tested wording.Source: §10 · p. 35

A Reproducing the results

The paper’s results are tied to a public release and committed result files, with a test checking agreement between documentation and results. The appendix gives commands for installation, use, and reproducing evaluations.

A Reproducing the results

  • The public 1.4.1 repository contains the paper’s evaluation results, and a test fails if documentation and results disagree.Source: A Reproducing the results · p. 38
  • The appendix provides commands to install Tracekit, instrument an agent, export and verify a run, and view it in dev mode.It also shows an example policy extension with tool classes, untrusted sources, deny rules, and ask rules.Source: A Reproducing the results · p. 38
  • Evaluation commands cover quick and full runs, with Linux-specific requirements for some experiments and an E20 reviewer-model arm marked not yet run.Source: A Reproducing the results · p. 38

B Sample verifier output

The sample verifier accepts the original bundle and rejects a copy in which a denied call was rewritten as allowed. Its report separates integrity from assurance and shows that this run had limited capture coverage and dev-level assurance.

Original bundle

  • The original bundle passes offline checks for its manifest, checkpoint, witness quorum, signatures, run chain, and checkpoint inclusion.The verifier uses pinned trust configuration and reports integrity as verified, while assurance remains dev.Source: B Sample verifier output · pp. 38–39

Tamper test

  • Rewriting the denied call as allowed makes verification fail because the event hash no longer matches.The original bundle exits 0; the tampered bundle exits 1.Source: B Sample verifier output · p. 39

Coverage and assurance

  • This sample captures tool calls only, reports same-user isolation, and leaves assurance at dev despite a cosigned witness checkpoint.The held call was approved by the run’s own identity.Source: B Sample verifier output · p. 39

C Finding catalogue

The finding catalogue names checks for unexplained effects, missing expected effects, prompt discrepancies, and say-versus-do mismatches. Some findings can be marked not checkable when required sensors, content, or execution conditions are absent.

Checkability

  • A finding can be not checkable when required content, sensor coverage, path information, or a completed call is unavailable.Table 34 presents findings alongside reasons a call can be not checkable.Source: Table 34 · p. 39, C Finding catalogue · p. 40

Effect findings

  • TK-X206 flags a process, connection, or write observed by a kernel sensor that no action explains or that does not fit its named call.It may be not checkable without a sensor or when the agent process is hook-like or the call is unfinished.Source: C Finding catalogue · p. 40
  • TK-X207 flags a call that returned ok without the expected program, connection, or file-write effect in its window.It may be not checkable when there is no sensor.Source: C Finding catalogue · p. 40

Prompt findings

  • TK-X208 flags a main-transcript prompt line absent from prompts recorded by the hook at submission.The check is not applicable when the harness never submitted the prompt.Source: C Finding catalogue · p. 40

Other findings

  • The catalogue also includes reviewer-model findings and checks for actions the model claimed but did not run, or denied actions that did run.The reviewer finding is warn-only; the say-versus-do checks use signed decisions and results.Source: C Finding catalogue · p. 40

D Glossary

The glossary defines Tracekit’s record, trust, capture, constraint, and replay terms. These distinctions describe what is recorded, who can vouch for it, and how actions are examined.

Core records

  • A signer holds signing keys, assigns sequence numbers, decides policy, and writes records; a run is one agent task registered before its first action and closed by a signed run.final.A .tkb bundle packages a run’s records, proofs, checkpoint, cosignatures, and policy snapshots.Source: D Glossary · p. 40

Trust

  • A verifier pins the trust config, while checkpoints record a log’s size and root hash and witnesses cosign only consistent checkpoints.Transcript assurance describes who vouches for a checkpoint: dev, local, witnessed, or witnessed+monitored.Source: D Glossary · p. 40

Evidence

  • Capture tiers identify who captured a record, while trust tiers describe how far the agent could have written a piece of text.A gap is a signed record that something was not seen, lost, or refused.Source: D Glossary · p. 40

Analysis

  • A live constraint is a prompt limit held by the signer for the run and later session runs; replay reruns a recorded program with paired seeds, recorded results, and one intervention.A scope such as “only change X” is checked only after the run.Source: D Glossary · p. 40
Loading 2609.35659v2…