Witness Ecosystem

Multi-witness Certificate-Transparency-style architecture for AI decision audit trails. Complementary to Cryptographic Integrity.

Why a single witness is not enough

If Adjudon publishes the chain to only one external witness, an adversary that controls Adjudon plus that single witness can present consistent forged chains. This is the analogue of Certificate Transparency's split-view attack.

The standard defence (RFC 6962 §6, BygTH gossip protocol, OpenSSF Rekor omniwitness) is a multi-witness consortium that gossips Signed Tree Heads (STHs) among themselves. If two witnesses observe different STHs at the same height, they detect the operator's split-view attack.

The Datadog CloudTrail bypass

In January 2023, Datadog Security Labs (researcher Nick Frichette) disclosed a method to bypass AWS CloudTrail logging for specific IAM API requests via undocumented APIs (reported to AWS 10 March 2022; fixed 24 October 2022; public disclosure 17 January 2023).

If even AWS's flagship audit log can be silently bypassed, the case for external witness ecosystems on AI decision logs is dispositive.

Adjudon's Audit Trail Phase 1 architecture closes this attack surface by replicating the Certificate Transparency multi-witness model: every daily Merkle anchor is appended to a Trillian Tessera log, and external monitors (Phase 2 deliverable) fetch the published STHs and gossip among themselves.

The Phase 1 + Phase 2 + Phase 3 witness layout

Witness	Status	Operator
Adjudon-operated Tessera log	Live in production since 2026-05-11 at tessera.adjudon.com. Two append-only Merkle logs, Ed25519 signatures, c2sp.org/tlog-checkpoint wire format, Frankfurt eu-central-1, signing key permanent (cannot rotate post-launch without log restart).	Adjudon (Frankfurt Fly.io)
OpenTimestamps Bitcoin (effective public witness)	Live in production since 2026-05-11. Daily Merkle anchor submitted to OpenTimestamps calendars; Bitcoin block reference upgraded asynchronously. Configurable via `OTS_CALENDAR_PRIMARY/FALLBACK/TERTIARY` env vars.	Bitcoin network (decentralised)
External EU witness #1 (TU Darmstadt CYSEC)	Phase 2 LD-4	Prof. Ahmad-Reza Sadeghi research group
External EU witness #2 (Bitkom AI Working Group)	Phase 2 LD-4	Industry association
Big-4 quarterly attestation (PwC Germany)	Phase 2 LD-5	PwC AI Governance practice
TÜViT senior auditor court-witness	Phase 2 LD-10	TÜViT (Enterprise tier retainer)
Named academic court-witness (Sadeghi or Loebenberger)	Phase 2 LD-10	TU Darmstadt or OTH Regensburg (Custom tier retainer)
Munich Re aiSure Audit Trail Insurance underwriter	Phase 3 LD-11	Munich Re (insurance-grade attestation feed)
External witness #3 (open)	Phase 2 fallback	Initiative D21 / Fraunhofer SIT

Public verifier key

Auditors and external witnesses verify Adjudon's Tessera STH signatures using this Ed25519 public key (note-encoded, plain-text — never changes):

tessera.adjudon.com+f64bee39+AdkG8EGhORx/pELSyAqHH1MN2jJfMlaSdUTsZK6pLYn1

Also published as a static file at adjudon.com/keys/tessera-public.txt. Anyone can fetch a checkpoint from https://tessera.adjudon.com/decision/checkpoint, verify the signature against this public key, and confirm Adjudon's commitment to that exact tree state at that exact time — without an Adjudon login.

Public CT-style endpoints

Adjudon publishes three public endpoints (Cardinal Rule #2 documented exception; consistent with CT pattern):

GET /api/audit-witness/sth?namespace=decision|operations|all
GET /api/audit-witness/inclusion-proof?namespace=...&merkleRoot=<hex>
GET /api/audit-witness/consistency-proof?namespace=...&fromSTHRoot=<hex>&toSTHRoot=<hex>
GET /api/audit-witness/status

These endpoints return only Merkle hashes — cryptographic by construction, not personal data. No customer-specific or PII content surfaces.

How an external witness operates

A monitor compatible with Adjudon's Tessera-backed log:

Polls GET /api/audit-witness/sth?namespace=... at a configured interval (Phase 2 default: every 5 minutes)
On STH update, computes H(prev_STH, new_STH) to track the gossip log
Optionally requests consistency proof between the previous STH and the new STH; verifies using the Tessera consistency-proof endpoint
Pushes its observed STH to a peer-witness gossip network (Phase 2 protocol design)
Alerts on any inconsistency via dedicated escalation channel

Witness gossip protocol (Phase 2 — code shipped)

Every new STH is pushed to a public webhook. Witnesses pull and verify; mismatches alert via dedicated escalation channel. The protocol is inspired by:

CT BygTH gossip (RFC 6962 §6)
OpenSSF Rekor omniwitness (Linux Foundation, December 2025 production reference)
Trillian Tessera witness collaboration patterns

Wire-format requirements

The endpoint POST /api/audit-witness/gossip/observe accepts:

{
  "payload": {
    "witnessName": "<registered-witness-name>",
    "chainNamespace": "decision|operations|all",
    "observedRootHash": "<64-char-lowercase-hex>",
    "observedTreeSize": <number>,
    "observedSthSignature": "<base64-or-null>",
    "timestamp": "2026-05-10T15:30:00Z"
  },
  "hmacSignature": "<64-char-lowercase-hex>"
}

payload.timestamp is required and must be within ±10 minutes of server time (configurable via WITNESS_GOSSIP_REPLAY_WINDOW_MS). Outside the window returns 401 with sentinel "outside acceptable replay window" — this prevents captured legitimate observations from being replayed indefinitely. Witness reference monitor implementations must re-sign each push with the current wall-clock time, not cache and re-emit.

The HMAC verification and shared-secret comparison both use crypto.timingSafeEqual (constant-time).

What's still pending

External EU witness recruitment (Phase 2 LD-4) — founder outreach to Sadeghi + Bitkom
Witness gossip protocol (Phase 2 design) — peer-witness M-of-N agreement
Open-source adjudon-verify CLI (Phase 3 LD-13) — Rust reference implementation for independent verification
Audit Trail Insurance feed (Phase 3 LD-11) — insurance-grade attestation feed to Munich Re aiSure underwriting models

Why a single witness is not enough​

The Datadog CloudTrail bypass​

The Phase 1 + Phase 2 + Phase 3 witness layout​

Public verifier key​

Public CT-style endpoints​

How an external witness operates​

Witness gossip protocol (Phase 2 — code shipped)​

Wire-format requirements​

What's still pending​

Further reading​