Una propuesta de integración reciente en LlamaIndex — exportar e importar paquetes de memoria sellados (sealed memory bundles) — toca exactamente el problema que operamos a diario: llevar estado verificado entre agentes. Mantenemos un protocolo de tarjetas de confianza (trust cards) para verificación agente-a-agente, donde los bundles sellados y portables son el artefacto central. Cuatro lecciones que aprendimos por las malas, aplicables directamente a esa propuesta y a cualquier diseño similar propio.
1. Fija el reloj, o tus intervalos de validez son re Jugables
Que algo fue "verificado en marzo" solo constituye evidencia sobre abril si la marca de tiempo de la verificación es, ella misma, un objeto de confianza. Si el importador evalúa la validez contra su reloj local de pared, el bundle sigue siendo re jugable entre hosts con desviación de reloj o con el reloj manipulado.
Lo que nos funcionó fue un solo cambio: registrar un evaluation_clock explícito junto a cada resultado de verificación, y evaluar contra esa referencia fijada — nunca contra el reloj local del importador. Con eso, los intervalos de validez dejan de ser re Jugables. Es la misma estructura de riesgo del rug pull de herramientas (te confías de una definición que ya cambió), pero aplicada al tiempo: el "momento en que verificaste" también es superficie de ataque.
2. Limita la evidencia, hashea el resto
Los recibos por memoria (comando ejecutado, resultado, código de salida, hash de salida) crecen sin cota. Un mes de evidencia de un agente ocupado vuelve el bundle intransportable.
El patrón viable: guardar un extracto de salida con tope de tamaño más el hash del recibo completo, y mantener los recibos completos fuera de banda (out-of-band), disponibles solo para resolución de disputas. Separar "que exista evidencia" de "transportar la evidencia siempre" mantiene el bundle pequeño y la verificación completa.
3. Prueba el importador adversarialmente
El parser de un bundle sellado es una decisión de confianza ejecutada sobre entrada no confiable: tiene exactamente la forma de ataque del tool poisoning. Nosotros generamos bundles mutados (mutaciones de dos puntos a través de fronteras firmadas) y exigimos que el importador rechace todos antes de llamar "implementado" al formato. El modelo observed-until-reverified solo gana su nombre si la propia ruta de reverificación sobrevive entrada adversarial.
4. No hagas que la validez del bundle dependa de confiar en el exportador
Anclar los digestos del bundle en un registro público de transparencia (estilo Rekor) más una cadena de releases firmada da verificabilidad por terceros y una historia de revocación sin autoridad central — y mapea limpio sobre custodia multi-salto, donde las firmas por salto se degradan al acumularse. El anclaje público no se degrada.
La pregunta que queda abierta: frescura de identidad
Cuando el exportador rota llaves, un bundle viejo sigue siendo criptográficamente válido. Observed-until-reverified cubre la frescura del contenido — pero ¿quién cubre la frescura de la identidad? ¿Un bundle firmado por una llave ya rotada sigue siendo importable, y quién decide? No he visto aún una respuesta de diseño a esto, y me parece que ahí hay un terreno vacío.
Artefactos públicos
Lo concreto detrás de las lecciones 1 a 4 está publicado y es verificable por cualquiera:
- Repositorio: https://github.com/alicelabs-llc/universal-trust-adapter
- Índice de vectores de conformance (regla de reloj fijado + distribuciones adversariales): https://www.marketnow.site/uta/conformance/vectors/_index.json
- SDK de verificación offline (solo node:crypto, registro de llaves CA embebido): https://www.npmjs.com/package/agent-trust-card
Preguntas y objeciones en español bienvenidas — especialmente si alguien tiene una respuesta de diseño para la frescura de identidad.
Top comments (0)