Institutional trust and mathematical trust are 128 bytes apart

Author: Aicent Stack · Part of the Dual-Pillar series · rttp:// (IANA Provisional, CRI 27) × iqa:// (CRI 28)

Between 2025 and 2026, the AI conversation slid from answering questions to executing tasks. Agents book flights, audit invoices, and call APIs on a user's behalf; one step further, agents delegate to agents — across organizations, across domains, strangers to one another. With every step, the shape of "trust" changes: in the chat era we feared the model would talk nonsense; in the agent era we fear it will overstep its authority; in the A2A era a new question arises — after a stranger agent finishes the job, what evidence can it produce?

The industry shouts this question loudly; no one has shipped a mechanism.

1. "Trustworthy" — the slogan with no landing gear

This year, agent standards have landed in rapid succession: runtime frameworks, runtime sandboxes, development platforms, multi-agent orchestration... The China Academy of Information and Communications Technology, in its August 2026 Guide to Building Reliability for Cloud-based AI, contains a sentence written remarkably well — "an AI system with end-to-end reliability can prove to businesses, regulators, and end users that it is predictable, explainable, auditable and accountable, thereby establishing a consensus of trust inside and outside the organization" (the original is public record).

Well said. But read the whole document and the word "prove" never touches ground: no cryptographic mechanism, no independently re-verifiable credential design. Audit logs exist — stored in the operator's own systems. Logs can be edited after the fact, and the verifier has no choice but to trust the operator. That is institutional trust, not mathematical trust.

Overseas, the same. Uber's recently published MCP gateway engineering blog describes a governance platform hosting 800+ MCP servers and 5,000+ tools; authorization, rate limiting, and data masking are spelled out in detail — the verifiability of the audit logs is never mentioned. Docker's MCP gateway, Cloudflare's Agents SDK, Alibaba's Higress: every feature list includes "audit logs", and every one stops at writing them down at home.

2. The shape of the gap

Lay out the trust capabilities of every platform and the gap is the same:

• Identity authentication exists (OAuth / DID)
• Authorization control exists (policy engines / rate limiting)
• Hand-over-able, independently verifiable evidence does not exist (logs locked in the operator's hands)

What verifiers — external auditors, downstream services, compliance frameworks, even the proxied user — need is one thing only: a cryptographic credential produced synchronously with the event, re-verifiable offline by anyone afterwards, with no callback to any online service.

3. A minimal viable form

We open-sourced a minimal implementation of exactly this (Apache-2.0):

• Intent addressing (RTTP): the subject's address is not assigned by a registry but derived deterministically from an authority string via SHA-256 — the address is the identity binding, self-evident on arrival. The scheme is registered with IANA (Provisional · CRI 27);
• The 128-byte attestation envelope (IQA): a fixed layout (magic / version / lease / subject shard / proof / organ / nonce / standing / reserved / extension), issued when the event happens;
• Constant-time, whole-frame verification: HMAC-SHA256 covers the entire frame; any altered byte fails — including actions such as "revocation-induced standing flips", fail-closed;
• Conformance test vectors: fixed inputs and outputs, reproducible byte for byte, verifiable with nothing more than the spec text and one SHA-256 implementation.

The packaged form: four MCP tools (derive_route_shard / parse_envelope / verify_envelope / published_vector); iqa-mcp is published at 1.0.1 (PyPI / npm / crates.io — three registries), callable from any MCP-compatible agent stack; the reference implementation iqa-org ships Python / TypeScript / Rust packages. The specification, draft-li-rttp-iqa-addressing, is under review in the IETF independent submission stream; the same "complementary evidence layer" proposal has been delivered to the official discussion forums of seven international ecosystems (Docker, Cloudflare, Uber, Alibaba Higress, among others).

The self-application goes further: our own website and every published artifact are sealed with the same mechanism — 32 credentials currently hang at iqa.org/attestations/, each re-verifiable offline. The first user is us.

4. The honest boundary

This design deliberately refuses three things: it does not replace any gateway's real-time governance (it only proves things after the fact); it does not specify delegation-chain semantics (explicitly out of scope in this version — community input is welcome); it does not claim to solve real-time risk control — detection is detection's business, evidence is evidence's.

Open questions outnumber answers: is the four-tool split right? How is cross-language vector consistency maintained? Who arbitrates the semantics of the four standing states? How should the 128-bit shard collision margin be analyzed? — Comments welcome.

Dual-pillar status: rttp:// and iqa:// are both registered with IANA (Provisional · CRI 27 / CRI 28). The merged specification draft-li-rttp-iqa-addressing is under review in the IETF independent submission stream; the trilingual reference implementations and byte-level test vectors are all open source.

Repos: github.com/Aicent-Stack · Spec & evidence chain: iqa.org · Addressing pillar: rttp.com

One sentence: the industry has shouted "trustworthy" for two years, and "verifiable" is still an empty field — this may be the last unclaimed plot in agent infrastructure.