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

Abierto
  • ¿Algo no está bien?
#163 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
cryptography, python
Área
security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
2.1k
Forks
230
Merge medio
16 h 8 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de uber/ADR

Todos los issues de uber/ADR

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.