[Proposal] Complementary evidence layer: portable offline-verifiable attestation for agent sessions (iqa-mcp)

Open
  • Is something wrong?
#163 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
cryptography, python
Domain
security

Research direction

The proposal names ADR's Observability component and REPRODUCIBILITY.md, but does not identify implementation files or define an integration scope. First read REPRODUCIBILITY.md and the Observability documentation or entry points to understand existing outputs. Before starting, get agreement on whether an integration sketch is wanted; done criteria and specific changes are not defined in the issue.

Written by the indexing model from the issue text.

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.

Dominant language
Python
Stars
2.1k
Forks
231
Avg merge
16h 8m
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uber/ADR

All issues in uber/ADR

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.