TTTPS — Byzantine Audit API

AI Agent Control Plane

From Byzantine audit to every AI agent's receipt.

The same commitment mechanism above (the audit trail for this Byzantine-detection engine) is being extended to seal outputs from open-source LLM agent frameworks, one content-hash timestamp receipt per call, issued the same way: an operator-independent seal that proves when, order, and tamper-evidence, not correctness.

Where this stands today: smolagents connects natively via MCP with zero adapter code; LangChain’s integration (langchain-openttt) is published to PyPI and installable now; LiteLLM and LlamaIndex integrations are verified in local testing and not yet published; vLLM’s middleware injection path is confirmed but not yet built; Ollama has no plugin API, so only a reverse-proxy wrapper is possible. This is a control plane under construction, not a finished one.[TARGET]

Explore the Provenance API →

Capabilities

What the engine does, end to end.

Detection, the lattice commitment pipeline, the audit query surface, and Prometheus metrics — all converging on a single Ed25519 commitment check.

Attack Detection Matrix

Thirteen attack classes — replay, drift, forgery, flood, ordering, Sybil, GPS spoofing, BGP/DNS, and more — each reduced to a commitment mismatch and logged with attack_type, agent_id, ctx_id, and timestamp.

Lattice Pipeline

A lattice-coded commitment pipeline binds payload and Roughtime chain_digest into a single cryptographic hash, signed with Ed25519. Every attack ultimately converges here.

Audit API

Query the Byzantine trail over any context and window via GET /audit — totals, ratio, and per-type attack breakdown, verifiable with the published public key.

Prometheus Metrics

Per-type attack counters and Byzantine ratio exposed at GET /metrics — drop straight into your existing observability stack.

Add-on · Zero-day Sentinel

TTTPS records who called. Sentinel refuses when the caller isn’t who they say.

Signed receipts after the fact are not enough for defense, finance, and regulated deployments. When an AI agent escapes its sandbox and reaches a service it was never authorized to reach, the block must happen before the receipt is issued.[TARGET]

(a) Sandbox identity bound

Sandbox identity — cgroup path, AppArmor / SELinux label, optional TPM 2.0 or Intel TDX / AMD SEV quote — is a mandatory field in every PoT record. No receipt is issued without it.

(b) Real-time deviation gate

Each agent enrolls a signed identity anchor at spawn. On every seal the caller’s attest is checked against the enrolled anchor. Mismatch is a deviation event, logged with the exact fields that diverged.

(c) Pre-issue reject

On mismatch the request returns 403 IDENTITY_MISMATCH. The receipt itself is not issued — the escape is blocked, not merely recorded. Prometheus exposes escape_attempt_count and escape_blocked_count.

Honest limit

If an escaped agent also compromises the sandbox runtime signing key, anchor forgery is possible. Hardware attestation (TPM 2.0 / Intel TDX / AMD SEV) is the hardening tier — the signing key is sealed to the hardware and cannot be exfiltrated.

Sentinel is an enterprise on-demand engagement, not a self-serve tier. For defense, regulated finance, and other environments that need pre-issue reject with hardware attestation, contact us. Base TTTPS keeps the PoT record field open for sandbox identity; Sentinel provides the enrollment, verification, and pre-issue block engine.[TARGET]

Thirteen attack classes. One commitment check.

Replay, drift, forgery, flood, ordering, Sybil, GPS spoofing, BGP, DNS — every one of them collapses to the same place: an Ed25519 commitment mismatch no one can forge without the issuer key.

Detection

Attack Detection Capability Matrix

All detected attacks are logged with attack_type, agent_id, ctx_id, and timestamp. Query via GET /audit.

Attack	Detection Mechanism	Lattice Layer	Log Field
Token Replay Reuse of a previously valid PoT token	seen_tokens HashMap — duplicate token hash detected on verify. ✅ Live.	Application	`REPLAY`
Timestamp Drift NTP manipulation, clock skew injection	±60s window check against server time; Roughtime chain_digest bound into lattice commitment — any timestamp deviation causes commitment mismatch. ✅ Live.	chain_digest → FORGE	`DRIFT` / `FORGE`
Signature Forgery Fake issuer, tampered token body	Ed25519 signature verification against published pubkey — computationally infeasible to forge without issuer private key. ✅ Live.	Ed25519	`FORGE`
Flood / DDoS Request rate abuse, resource exhaustion	Per-IP and per-agent rate limiting (requests/min); excess requests rejected with 429. ✅ Live.	Application	`FLOOD`
Ordering Attack Out-of-sequence token submission	Fleet cross-reference — token sequence validated across agent set. ✅ Live.	Application	`ORDERING`
Cross-Pool Replay Token from Pool A submitted to Pool B	Context-bound cryptographic commitment — cross-pool commitment mismatch is computationally infeasible to conceal under standard cryptographic assumptions. ✅ Live.	Commitment	`FORGE`
Sybil Attack Multiple fake agent IDs from same node	Service context commitment binding — each context has a unique cryptographic key; cross-context token reuse fails verification. ✅ Live.	Commitment	`FORGE`
GPS Spoofing Falsified satellite time signals	Roughtime chain spread violation → commitment diverges when timestamp differs across sources. Multi-source Roughtime chains ≥3 operator-independent servers (int08h · roughtime.se · txryan), nonce-chained median per draft-ietf-ntp-roughtime-19 §5.4. ✅ Live.	chain_digest → FORGE	`FORGE`
NTP Injection Rogue NTP server, synchronized clock bias	Roughtime chain_digest is lattice-committed alongside payload — manipulated timestamp shifts chain_digest, breaking Ed25519 signature. Full Roughtime cross-validation live: roughtime_k=3, chain_digest bound into Ed25519 commitment. ✅ Live.	chain_digest → Ed25519	`FORGE`
BGP Hijacking Route manipulation, man-in-the-middle	Intercepted tokens cannot be re-signed without issuer private key — any modification invalidates Ed25519 signature. ✅ Live.	Ed25519	`FORGE`
DNS Poisoning Redirected API endpoint, fake issuer	Issuer pubkey is pinned and published out-of-band; tokens from any other key fail Ed25519 verification. ✅ Live.	Ed25519	`FORGE`
SDN Flow Manipulation Packet reordering via SDN controller	ORDERING cross-reference detects sequence anomalies; lattice integrity layer recovers partial data corruption. ✅ Live.	Lattice + ORDERING	`ORDERING`
Protocol Violation Malformed token, missing fields	Schema validation on all fields; multi-layer ECC detects bit-level corruption. ✅ Live.	ECC	`INVALID`

Lattice Pipeline

All attacks ultimately converge to a commitment mismatch, caught at the Ed25519 layer.

Input Payload (P)
  └─ Lattice-coded commitment pipeline (proprietary)
      └─ Context commitment (ctx_id bound)
          └─ Lattice_Commitment (cryptographic hash over payload + chain_digest)
              └─ Ed25519 signature

API

Query the trail. Export the metrics.

Operator-independent verification: anyone with the published public key can replay the audit trail. Metrics drop into your existing stack.

Audit Log — GET /audit

curl "https://api.kenosian.com/audit?ctx_id=<ctx_id>&window=3600" \
  -H "X-API-Key: <your-api-key>"

{
  "ctx_id": "dlr-poc",
  "window_secs": 3600,
  "total_requests": 142,
  "byzantine_total": 3,
  "byzantine_ratio": 0.021,
  "attack_breakdown": {
    "REPLAY":   2,
    "DRIFT":    1,
    "FORGE":    0,
    "FLOOD":    0,
    "ORDERING": 0,
    "INVALID":  0
  }
}

Prometheus — GET /metrics

tttps_attack_total{type="replay"}   2
tttps_attack_total{type="drift"}    1
tttps_attack_total{type="forge"}    0
tttps_byzantine_ratio               0.021
tttps_valid_count                   139

Quick Start

Generate, verify, audit — four calls.

API access by request. The same engine that runs the case studies above runs live on api.kenosian.com.

Request API Access →

# API access by request — contact peter@kenosian.com

# 1. Health check
curl https://api.kenosian.com/health

# 2. Generate PoT token
curl -X POST https://api.kenosian.com/pot/generate \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"<agent_id>","ctx_id":"<ctx_id>"}'

# 3. Verify + Byzantine detection
curl -X POST https://api.kenosian.com/pot/verify \
  -H "X-API-Key: <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"token":"<token>","agent_id":"<agent_id>","ctx_id":"<ctx_id>"}'

# 4. Audit report
curl "https://api.kenosian.com/audit?ctx_id=<ctx_id>&window=3600" \
  -H "X-API-Key: <your-api-key>"

Trust Mark

TTTPS

Verifiable
WHEN

certified

“TTTPS-certified” — the time-integrity standard (proposed)

A proposed trust mark for verifiable when: a system that can produce a tamper-rejecting record of when its events and the actions above them happened. Conditional on TTTPS being adopted as the standard, with Kenosian as the root of trust.[TARGET]

Illustrative mark for explanation only. Any certification authority, mark, or “certified” status is proposed and conditional (“could / if adopted”), and would operate under the Kenosian root — not a present-day certification program.[TARGET]

Try it

Seal something, then check it yourself.

A public demo runs the protocol end to end from the browser. Type any text; it is hashed with SHA‑256 on your own machine and only the digest is sent. What comes back is a receipt with who, what and when — and the when carries the Roughtime quorum's chain digest when the quorum is live.

Verification needs no key and no account, so anyone you hand a receipt to can check it without asking us for anything.

Open the live demo → API console →

What a receipt does not say is as fixed as what it does. It attests when a digest was sealed, its order against other seals, and that it has not changed since. It does not attest that the content is correct, and none of the integrations below certify compliance with any regulation on their own.

Core Verification Oracle

One package. The kernel’s verdict.

This is the core SDK: it queries kenosian‑vault directly for an O(1) lookup of a Lean 4 kernel-verified result, returned with the TTTPS T₀ timestamp receipt for that answer. It is a different layer from the framework integrations below, which seal general LLM and agent output rather than check a specific mathematical claim against the kernel. See the kenosian-vault page →

Framework/Language	Status	Install	What it does
Python	✅ Published.	`pip install --upgrade kenosian-vault`	theorem()/verify()/stats()/impact() — direct HTTP client, zero dependencies.
TypeScript / Node.js	In progress.	`npm i @kenosian/vault`	theorem()/verify()/stats()/impact() — direct HTTP client, zero dependencies.
Rust	In progress.	`cargo add kenosian-vault`	theorem()/verify()/stats()/impact() — direct HTTP client, zero dependencies.

Integrations

Eight frameworks, one line each.

Every adapter attaches the same receipt to work the framework was doing anyway. All eight are published on PyPI.

Framework	Install	Version	What it seals
LangChain	`pip install langchain-openttt`	0.3.0	Callback handler. Seals each chain run.
LiteLLM	`pip install litellm-openttt`	0.1.0	Success callback. Seals the completion.
LlamaIndex	`pip install llamaindex-openttt`	0.1.0	Callback handler. Seals query and response.
smolagents	`pip install smolagents-openttt`	0.1.0	Step callback. Seals each agent step.
vLLM	`pip install vllm-openttt`	0.1.0	ASGI middleware. Carries W3C traceparent into the receipt.
Ollama	`pip install ollama-openttt`	0.1.0	Reverse proxy. Seals the final NDJSON line of a stream.
DeepEval	`pip install deepeval-openttt`	0.1.0	BaseMetric. Cross-checks the receipt against the backend.
Ragas	`pip install ragas-openttt`	0.1.0	SingleTurnMetric. Carries the receipt id through the sample.

Read the Technical Whitepaper →