cd /news/ai-infrastructure/keybound-auditoria-de-aislamiento-de… · home topics ai-infrastructure article
[ARTICLE · art-106592] src=dev.to ↗ pub= topic=ai-infrastructure verified=true sentiment=· neutral

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.

read2 min views1 publishedAug 21, 2026

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

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 validadoCellError

).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

── more in #ai-infrastructure 4 stories · sorted by recency
── more on @keybound 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/keybound-auditoria-d…] indexed:0 read:2min 2026-08-21 ·