keybound: auditoria de aislamiento de prompt cache en relays LLM multi-tenant

A developer released keybound, an open-source tool that audits prompt-cache isolation in multi-tenant LLM relays. It verifies the defense contract from the KeyPooling paper (arXiv:2608.17485) by detecting cross-tenant cache leaks, using real identity rather than cell labels. The tool runs formal E2 cells against a mock gateway and reports verdicts without exposing tenant keys or authorization headers.

Una herramienta que veredicta si el defense contract de arXiv:2608.17485 KeyPooling se cumple: en un relay multi-tenant, nadie lee cache escrito por otro tenant. En un relay LLM que sirve a varios tenants con una sola credencial upstream, el dominio de cache puede colapsar : dos tenants distintos terminan compartiendo el mismo namespace de cache. El resultado es una fuga de información — el tenant B lee lo que el tenant A escribió, sin saberlo y sin permiso. El paper KeyPooling arXiv:2608.17485 define el defense contract: «a namespace derived from authenticated identity must survive every final cache lookup and write» Es decir: la identidad autenticada del tenant debe derivar un namespace que persista en cada lookup y escritura de cache. Si el relay no envía namespace lo colapsa , el contrato se rompe. Ejecuta las células formales E2 del paper contra un gateway mock y veredicta el contrato: collapse : dominio único compartido → debe fallar exit 1 . isolate : namespace por tenant derivado del bearer → debe pasar exit 0 .El veredicto es por identidad real , no por la etiqueta de la célula. Un leak es cualquier lectura con cached tokens 0 cuyo escritor hit writer es un tenant distinto del lector. Esto lo hace invariante al orden de ejecución, incluida la permutación adversarial la célula cross antes que las cold / owner del otro tenant . keybound audit --fixture collapse fixture: collapse | verdict: FAIL | defense contract: not satisfied cause: 1 dominio s ; cross con leak= 'A1-cold-prime', 'A2-owner-hot' El reporte nunca incluye claves de tenant ni el Authorization recibido — solo identificadores tenant A/B, prompt P/R y los dominios efectivos. El desarrollo siguió el protocolo de la casa: implementación → auditoría independiente en clon limpio → aprobación de merge. Tres bugs reales cazados y corregidos en el camino: cached tokens negativo no validado CellError . kind=="cross" cross se ejecutaba antes. Corregido por el camino de identidad real hit writer , descubierto por la auditoría, no por self-report.Los tests corren contra un gateway mock sintético sin red, determinista , no contra LiteLLM real — el fast suite valida la lógica del auditor, no reconfirma la vulnerabilidad en cada CI run. La vulnerabilidad real está documentada en RESEARCH.md / KNOWN ISSUES.md y se verifica con el adaptador NewAPI roadmap v0.3 . ruff limpio, cobertura git clone https://github.com/amurlaniakea/keybound cd keybound python -m venv .venv && source .venv/bin/activate pip install -e . keybound audit --fixture collapse FAIL esperado keybound audit --fixture isolate PASS esperado Licencia: AGPL-3.0-or-later — Copyright 2026 Pedro Sordo Martínez