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

Aperta
  • Qualcosa non va?
#163 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cryptography, python
Ambito
security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
2.1k
Fork
230
Merge medio
16h 8m
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di uber/ADR

Tutte le issue di uber/ADR

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.