Repository navigation
[Proposal] Complementary evidence layer: portable offline-verifiable attestation for agent sessions (iqa-mcp) #163
Description
ADR's five capabilities cover the agent security lifecycle impressively — Discovery, Observability, Benchmark, Detection, Prevention. One gap worth considering, from the Observability component's perspective:
The gap: ADR captures intents, tool usage and execution traces — but these artifacts live inside ADR itself. They answer "what happened" for the operator; they cannot be handed to an external party (auditor, downstream service, compliance framework) as independently verifiable evidence. A log can be edited after the fact; the verifier has no choice but to trust the operator. This gap is industry-wide: even a governance platform at the scale of 800+ MCP servers and 5,000+ tools (Uber's recent MCP Gateway write-up) leaves audit verifiability unaddressed — captured events and governance decisions stay inside the operator's own systems.
Suggested direction: pair ADR's observability output with a post-hoc evidence layer — compact cryptographic attestations produced when events are captured, verifiable offline by anyone, forever, with zero round-trips. We open-sourced a minimal reference implementation:
-
iqa-mcp (Apache-2.0, on PyPI): four MCP tools —
derive_route_shard(intent-address derivation from any authority, no registry) /parse_envelope(128-byte AE-128 attestation envelope) /verify_envelope(constant-time HMAC-SHA256 full-frame verification + lease check, fail-closed) /published_vector(conformance test vectors for byte-level self-checks) -
Reference implementation: iqa-org v1.3.1 (PyPI / npm / crates.io)
-
Specification: IETF Independent Submission draft draft-li-rttp-iqa-addressing (in review)
Positioning — complement, not replacement: ADR decides in the moment (detection, prevention); the evidence layer proves after the fact (portable, offline-verifiable). It adds no detection logic to ADR and depends on no ADR internals — the two can be deployed independently.
The published_vector tool follows the same spirit as ADR's REPRODUCIBILITY.md: results anyone can re-verify byte-for-byte, not just trust.
Happy to draft a short integration sketch (Sensor output → envelope emission) if useful, or to be pointed to a better-fitting home.
Activity
Paraphern commentedon Oct 21, 2026
This proposal describes a primitive we already run in production, and the field data supports the gap it names. rugsnare (Apache-2.0) pins agent-facing contracts (MCP tool contracts, skill files) with Ed25519-signed artifacts: pin stores verifiable against a committed public key, plus release hashes pinned append-only on-chain (Base mainnet, live since our 1.0.0). Verification is third-party by construction: pin verification is offline (an auditor needs the public key and the artifact, nothing else), and the on-chain record adds an anchor independent of the publisher's repo. The interchange format (PIN-SPEC) is open and versioned.
One design note from running it: separate the ATTESTATION from the VERDICT. Our signed artifacts attest bytes ("these were the exact tool contracts served by version X"); whether that is good or safe stays with the human approval step. That separation keeps attestations cheap to produce and impossible to argue with. Glad to compare receipt formats if this moves forward - it is the same interchange problem we worked through for cross-organization pin hashes (PIN-SPEC §3.2).
Aicent-com commentedon Oct 22, 2026
Thanks @Paraphern — and the field data you published (218 silent contract changes in the npm MCP top; 66 version pairs across the 4 official
@modelcontextprotocol/server-*reference servers yielding 140 findings, not one announced in a changelog) is exactly the kind of evidence this ADR's gap needed named.Your ATTESTATION/VERDICT separation matches what we pre-registered on the public record this week (W3C list, No. 0015): a signed statement is evidence, never permission — attestation stays cheap precisely because it refuses to be a verdict. Good to see that boundary re-derived independently from production experience; it suggests the separation is load-bearing, not stylistic.
On comparing receipt formats: yes, let's. Concretely, we propose a field-level mapping between PIN-SPEC §3.2 (cross-organization pin hashes) and the sealed envelope we use for iqa-mcp (Ed25519, content-addressed subject derived from the artifact itself, explicit freshness lease). The goal would not be for either format to win — it would be to identify the minimal common interchange that lets an artifact sealed in one scheme be verified with the other's tooling, and to state honestly which properties each side does not carry.
The two artifacts chain naturally, too: your pin attests the bytes that were approved (release-time, hash-pinned, on-chain anchored); our envelope attests the verdict rendered over a session (runtime, lease-bound, organ-signed). An auditor holding both can walk from "this contract was approved" to "this session was verified against it — by whom, when, until when" without trusting either publisher's repo or contacting either issuer.
Everything on our side is offline-verifiable today:
pip install "iqa-org[ed25519]", a public sealed-verdict demo at https://iqa.org/sealed-mcp/, and the derivation/envelope conformance vectors are public and replayable offline (RTTP self-test 83/83 on PyPI rttp 1.3.1; conformance vectors 35/35 on npm @aicent/rttp 1.3.1). If the maintainers are content for it to live in this thread, we are happy to draft the mapping table as a public document here.Paraphern commentedon Oct 22, 2026
Draft away — and thank you for citing both reports precisely; the two numbers live in different documents (218 across the npm top, 140 over the 66 pairs of the reference servers) and you kept that distinction, which is rarer than it should be.
Before answering we checked your side: the sealed-verdict demo is live and internally consistent — 22 verdicts embedded with their AE-128 envelopes, subject URIs documented as reconstructed from the verdict hashes, offline verification spelled out end-to-end — and the packages are live at the versions you named (
@aicent/rttp@1.3.1on npm,rttp@1.3.1on PyPI). We have not executed the offline verify itself yet; we'd run it against the published payload as step one of the mapping doc, so the table starts from a verified baseline rather than two parties' assertions.On the mapping — agreed on the goal, and we'd state the non-carried properties up front, because they're the interesting part:
surfaceHashover the canonical tool array; Ed25519-signed pin store; release hashes append-only on-chainIf that skeleton holds, the minimal common interchange looks like three fields: content-addressed subject, signature suite + issuer identity, and a time discipline — where our side would carry "no expiry is a property, not an omission" as an explicit flag, since a pin genuinely has none. The chaining you describe, approval pin ↔ session verdict, is the part we want most: an auditor walking from "this contract was approved" to "this session was verified against it" without contacting either issuer is the audit story PIN-SPEC was written for.
One boundary the doc should keep explicit: neither artifact should quietly become the other. Our system has a mirror-image stop for this — when the canonicalization policy that produced a pin changes, we emit exactly one POLICY finding and refuse to re-grade into tool classes, because verifier drift must never masquerade as server drift (PIN-SPEC §3.1). The receipt-format analog deserves the same sentence: a signature-suite or policy bump on either side surfaces as its own event, never as a silent re-interpretation of existing receipts.
Happy to co-draft in this thread when you start it.
Aicent-com commentedon Oct 26, 2026
@Paraphern — started the mapping as proposed. The document has a versioned home now: Aicent-Stack/interchange · receipt-interchange/ (v0.1).
It takes your four-row skeleton and expands it to a field-level mapping, then proposes the minimal three-field interchange — content-addressed subject, signature suite + issuer identity, time discipline as an explicit
lease | immortalenum — plus the boundaries neither artifact may quietly cross, and the chaining story an auditor walks offline.Baseline is green from our side as of today (2026-10-26):
rttp[ed25519]==1.3.1self-test 83/83 on PyPI (clean target dir),@aicent/rttp@1.3.135/35 on npm (independent implementation), and the sealed-verdict demo verifying PASS at https://iqa.org/sealed-mcp/ (sealiqa://f124b59fc28315c4da79348b37c28a74.forge.iqa, standing RADIANT).Co-drafting happens over there: PRs welcome (DCO sign-off), issues open — one folder per collaboration, no party's brand in any name, and co-drafting implies no joint ownership. This thread stays lean for the maintainers.