A two-layer verification architecture for autonomous AI agents — cryptographic timestamp sealing and formal-logic verification for AI agent decisions.
Specification. draft-helmprotocol-tttps-08, IETF Independent Submission stream. Stream history, read directly off the datatracker document-history page (12 August 2026): submitted 14 March 2026 as -00; ISE stream assigned, Submission Received, 30 June 2026; In ISE Review 25 July 2026, same day Response to Review Needed; revisions -07 (26 July) and -08 (29 July) followed in direct response.
Interim presentation. Presented live at the IETF Dispatch/SecDispatch interim session, 30 June 2026 — the same day as the ISE stream assignment above. Two local artifacts confirm this independently: the session slide deck (draft-helmprotocol-tttps-04, 9 slides) and a same-day follow-up email to secdispatch@ietf.org quoting dispatch chair Jim Fenton's live comment that “ISE is a viable option,” and John Klensin's related remark. We do not claim presentation at a numbered IETF meeting week; the confirmed event is this interim session.
Companion paper. Proof-of-Time: Byzantine-Resilient Temporal Ordering in Untrusted Networks, Heime Jorgen, SSRN 6467220.
Systems that log their own AI agent decisions are self-attesting: nothing external prevents a record from being written, or rewritten, after the fact. TTTPS (TLS TimeToken Protocol Suite) closes this gap by sealing a record's timestamp and content binding at generation time, using mechanisms already deployed in TLS (RFC 5705 Keying Material Exporters) rather than a new handshake extension.
Two integrity layers are defined. The mandatory-to-implement layer (0x0001, arity-2) is an unkeyed SHA-256 commitment: recomputation mismatch is an immediate tamper verdict, and this algorithm carries no encumbrance. A second layer, GRG (0x0100, arity-3: Golomb‑Rice → Reed‑Solomon(4,6) → Golay(23,12,7)), was fully specified with proven coding-theoretic bounds in draft versions -06 and -07 and operated experimentally for six months; as of -08 its registry slot is reserved rather than assigned, because it is the subject of a pending patent application by the author, deliberately separated from the royalty-free mandatory-to-implement path under IETF BCP 79.
A second, independent component, K-Lean Vault, is a Lean 4 library of 2,593 theorems, each checked sorry-free and axiom-free, used where a claim benefits from deterministic formal verification rather than a cryptographic receipt alone.
A system that attests its own timestamps proves nothing about when a record was actually sealed. Backdating a self-attested log is, by construction, undetectable from inside that system. TTTPS's design question is where the seal happens: before a record enters any system-controlled store (pre-ingestion), or after (post-ingestion — the class SCITT and Certificate Transparency belong to). TTTPS is pre-ingestion by design (draft §2.5, requirement R3); post-ingestion systems were not designed to satisfy that requirement, and the two are complementary rather than competing.
Stage 1 — mandatory integrity layer (0x0001 SHA-256). The active standards-track algorithm registered in -08 §3.3.2 is arity-2, unkeyed SHA-256 over the full record fields. Any recomputation mismatch is an immediate, unconditional tamper verdict; this is the only algorithm in the current mandatory-to-implement table, and it carries no licensing encumbrance.
Stage 2 — next-generation high-resilience layer (0x0100 GRG). GRG is not an incomplete design; it is a fully specified three-stage pipeline (Golomb-Rice → Reed-Solomon(4,6) → Golay(23,12,7)) present in -06 §6, reconstructing the original from any 4 of 6 shards and auto-correcting up to 3 bit errors per 23-bit block — with named coding-theoretic bounds this whitepaper cites precisely rather than re-derives.
The stage order G₁ → R → G₂ → H is not arbitrary: the companion paper's Theorem 1 requires G₁ output to be byte-aligned for R's symbol boundaries to be optimal, and Theorem 2 requires R's fixed-size shards for G₂'s lossless encoding, with combined failure probability P(fail) = P(R)·P(G₂) < P(R) + P(G₂). HMAC-SHA256 (H) is checked before the Ed25519 double-seal because it is roughly fifteen times cheaper (about 6 microseconds versus about 100 microseconds, per -06 §6.5).
Because every stage operates on a fixed-size block, verifying one record's integrity does not depend on how many other records exist in the ledger: per-record verification cost is O(1) in total ledger size, unlike schemes that require replaying a full hash chain or walking a Merkle path whose depth grows with the ledger.
-08 §10, verbatim: “The integrity algorithm for which Section 9.3 reserves 0x0100 (GRG) is the subject of a pending patent application by the author … This document is fully implementable without GRG. The mandatory-to-implement integrity algorithm is unkeyed SHA-256 (0x0001), which is unencumbered … This arrangement is deliberate: the specification does not require any implementer to obtain a licence.”
This is the standard IETF pattern of separating a royalty-free mandatory path from a RAND-licensed optional extension under BCP 79, not evidence of an unfinished design.
The draft was presented live at the IETF Dispatch/SecDispatch interim session on 30 June 2026, the same day the ISE (Independent Submission Editor) stream assignment was recorded on the datatracker document-history page. Dispatch chairs, including Jim Fenton (DKIM co-author), and IETF security-area participants including Eric Rescorla and John Klensin gave real-time technical feedback — on blockchain dependency, CVE-2026-33697 applicability, the relationship to SCITT and Certificate Transparency, and the post-quantum roadmap. This was an interim session, not a numbered IETF meeting week; that distinction is kept here rather than blurred.
| Date | Event | Draft version |
|---|---|---|
| 14 Mar 2026 | Initial submission (-00) | -00 |
| 30 Jun 2026 | IETF Dispatch/SecDispatch interim presentation; ISE stream assigned, Submission Received | -04 (slide deck) |
| 25 Jul 2026 | In ISE Review; Response to Review Needed (same day) | — |
| 26 Jul 2026 | Revision in response to review | -07 |
| 29 Jul 2026 | Revision in response to review | -08 |
K-Lean Vault is a deterministic verification library: 2,593 theorems across 1,491 modules and, per its own indexer, 16 domains, each checked sorry-free and axiom-free by the Lean 4 kernel.
It answers a different question than TTTPS: TTTPS proves when a record was sealed and that it has not been altered since; K-Lean Vault proves that a stated rule (a policy bound, a compliance constraint) holds deterministically, rather than being asserted by a probabilistic model. The two compose — TTTPS seals the record of an inference; K-Lean Vault can certify that the inference obeyed a formally stated rule — but neither substitutes for the other. This whitepaper does not claim K-Lean Vault verifies the correctness of an underlying AI model's output in general, only of formally stated properties checked against it.
Each adapter attaches the same TTTPS receipt to work the framework was already doing. Every import name below is copied from the package's own source (__init__.py / __all__), not reconstructed — ollama-openttt is a reverse proxy rather than an importable callback, and ttt-otel is a standard OpenTelemetry SpanProcessor rather than a framework-specific adapter; both are shown as they actually are rather than forced into the same shape as the rest. A ninth package, ethoca-openttt, is built but not yet published to PyPI.
pip install smolagents-openttt
from smolagents import CodeAgent
from smolagents_openttt import ttts_pot_step_callback_kpp_live
agent = CodeAgent(
tools=[],
model=your_model,
step_callbacks=[ttts_pot_step_callback_kpp_live],
)
result = agent.run("your task")
for step in agent.memory.steps:
print(getattr(step, "tttps_receipt", None))
pip install litellm-openttt
import litellm
from litellm_openttt import TTTPSTimestampLoggerKPPLive
litellm.callbacks = [TTTPSTimestampLoggerKPPLive()]
resp = litellm.completion(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "hi"}],
)
print(resp.tttps_receipt)
pip install llamaindex-openttt
from llama_index.core.callbacks import CallbackManager
from llamaindex_openttt import TTTPSTimestampCallbackHandlerKPPLive
Settings.callback_manager = CallbackManager([TTTPSTimestampCallbackHandlerKPPLive()])
resp = llm.complete("hi")
print(resp.additional_kwargs["tttps_receipt"])
Not a Python import: ollama-openttt is a reverse proxy that sits in front of ollama serve and seals the final NDJSON line of a stream. Point any Ollama client at the proxy port instead of the daemon port.
pip install ollama-openttt
export KPP_API_KEY=...
ollama serve & # upstream, port 11434
ollama-openttt --port 11435 # or: python -m ollama_openttt
curl http://127.0.0.1:11435/api/chat -d '{
"model": "qwen2.5:0.5b",
"messages": [{"role": "user", "content": "hi"}],
"stream": false
}'
ASGI middleware — wraps any Starlette/FastAPI app in front of a vLLM server and attaches a receipt to each request span.
pip install vllm-openttt
from starlette.applications import Starlette
from vllm_openttt import TTTPSMiddleware
app = Starlette(routes=your_routes)
app.add_middleware(TTTPSMiddleware)
A DeepEval metric — seals the test case and scores whether its receipt has valid TTTPS provenance structure.
pip install deepeval-openttt
from deepeval.test_case import LLMTestCase
from deepeval_openttt import TTTPSProvenanceMetric
metric = TTTPSProvenanceMetric()
score = metric.measure(your_test_case)
A Ragas metric — same provenance-scoring shape as the DeepEval adapter, for teams already standardized on Ragas evaluation.
pip install ragas-openttt
from ragas import evaluate
from ragas_openttt import TTTPSProvenanceMetric
results = evaluate(your_dataset, metrics=[TTTPSProvenanceMetric()])
A standard OpenTelemetry SpanProcessor — AutoGen's runtime tracing is built on OTel already, so this attaches to any TracerProvider AutoGen (or any other OTel-instrumented Python stack) is already using, no framework-specific adapter needed. On every span end it extracts the trace/span id, model name, and a BLAKE3 hash of the input/output (never the raw text itself) and seals that into the Proof-of-Time chain in a background thread — export is never blocked.
pip install ttt-otel
from opentelemetry.sdk.trace import TracerProvider
from ttt_otel import TTTSpanProcessor
provider = TracerProvider()
provider.add_span_processor(
TTTSpanProcessor(api_key="<YOUR_TTT_API_KEY>") # or os.environ["TTT_API_KEY"]
)
It runs alongside your existing OTLP exporter — you don't replace your observability backend, you add a second processor next to it. Confirmed compatible today:
| Backend | OTLP/HTTP endpoint | Auth header |
|---|---|---|
| Langfuse | cloud.langfuse.com/api/public/otel/v1/traces | Authorization: Basic base64(pk:sk) |
| Arize Phoenix | local :6006/v1/traces · cloud app.phoenix.arize.com/v1/traces | cloud: Authorization: Bearer <key> |
| MLflow 3.6+ | <tracking-server>/v1/traces | x-mlflow-experiment-id: <id> |
Verifying a seal later — if a span's output was edited after sealing, this returns valid: false:
from ttt_otel import verify
from ttt_otel._hash import canonical_fields_from_span
result = verify(canonical_fields_from_span(span), api_key="<YOUR_TTT_API_KEY>")
print(result["valid"], result["chain_intact"])
All eight are published on PyPI. LangChain is also supported, covered separately on the TTTPS product page.
Both layers add a cryptographically sealed, tamper-proof record on top of existing requirements — a decisive evidence layer for audits, investigations, and disputes.
FDA 21 CFR Part 11 §11.10(e). TTTPS combines an automated audit trail with a cryptographic seal applied before the record is admitted into any system-controlled store (pre-ingestion, §2.5 requirement R3) — retroactive backdating is structurally excluded, even for an administrator of that store.
EU AI Act Art. 12/53. TTTPS provides an independent, tamper-proof integrity proof for high-risk AI systems' decision records, closing the record-keeping requirement with cryptographic evidence rather than a self-attested log.
SEC Rule 17a-4 / DORA. 17a-4 requires WORM storage; DORA does not name a cryptographic mechanism. TTTPS is the cryptographic layer that strengthens WORM-based audit trails for AI-agent transaction records — sealed at generation, verifiable by any third party.
The SHA-256 tamper-detection property is unconditional and needs no qualification. The GRG bounds (Shannon, Singleton, Hamming) are proven in the cited draft sections, not re-derived in this paper. The 2,593-theorem count is machine-counted against K-Lean Vault's own indexer.
Six months of field deployment produced 70,612 verified PoT records (55% AI-agent-originated), exercising the O(1) verification path and BFT timestamp sealing described above.
See also the companion paper: Proof-of-Time: Byzantine-Resilient Temporal Ordering in Untrusted Networks, Heime Jorgen, SSRN 6467220.