philippeabraxas-jpg/tbp-networkTeoría e implementación del protocolo TBP para asegurar la IA en red en redes web de pequeñas a abiertas
Implementación a nivel de red del Protocolo de Delimitación Teleológica (TBP) — gobernanza atestiguada de las acciones de agentes de IA sobre una red, desde una sola máquina hasta despliegues empresariales a escala de WWW.
« El control de acceso existente decide si entras; TBP decide qué se te permite hacer una vez dentro — y lo demuestra. Gobernamos capacidades, no modelos. »
Nunca una asociación por confianza — solo por un apretón de manos atestiguado. Ese es el objetivo: el apretón de manos entre entidades (spec §3) permite que entidades que no confían entre sí se demuestren mutuamente política, historial y vivacidad. El apretón de manos en sí aún no está construido (#33). Lo que este repositorio contiene hoy es lo que viene antes y sobre lo que se apoyará — los PEP, el broker de celdas y los registros, NAC, supervisión, las guías de despliegue — lo que extiende la gobernanza de TBP desde una sola máquina hasta una pequeña red de máquinas bajo una misma organización.
No para producción. Claves desechables, máquinas que puedes perder, sin datos reales. Existe para que puedas intentar romper TBP antes de que lo haga un lanzamiento de producción.
TBP-NETWORK incluye un despliegue sencillo para ejecutar y atacar antes de que exista un lanzamiento de producción. Tres máquinas,
cada una desplegada por un script: M1 la celda (brokerd y su OPA), M2 un servidor de aplicaciones (pepd y una
pequeña aplicación), M3 un agente. Prueba que todo el conjunto funciona — un agente enrolado por su certificado,
una decisión sobre TLS mutuo, un token verificado por un servidor, la postura del servidor gobernada por los controladores — con los
binarios reales y la aplicación real; solo se simplifica la ceremonia de claves. Una variante de una sola máquina te permite observar la
celda por sí sola.
Todo está en deploy/dev-test/: para qué sirve cada máquina y por qué, el procedimiento exacto desde máquinas Debian 12 recién instaladas, el escenario a probar, dónde atacar, qué demuestra y qué no — y cómo enviarnos tus números y comentarios para cada entorno que pruebes, que queremos recibir. Cualquier cosa explotable va a través de SECURITY.md, no en un issue público.
TBP no cierra todos los agujeros; audita todos los agujeros. Eso no es una limitación a sortear, es el postulado fundacional (spec §1: "no cerramos todos los agujeros; clasificamos los agujeros por impacto y mitigamos proporcionalmente — la gobernanza es asignación, no completitud"). TBP no es un sistema de seguridad autosuficiente — no reemplaza a SELinux, firewalls, IAM ni el sandboxing a nivel de SO, y nunca lo hará por diseño. Lo que hace es más acotado e innegociable: ninguna acción gobernada se ejecuta sin una decisión criptográficamente demostrable, y ninguna decisión — permitir o denegar — escapa de la cadena de auditoría sin ser demostrable e incorrupta. TBP es una capa de gobernanza y atestación sobre cualquier stack de aplicación que un despliegue ya tenga, no un sustituto de él.
Cuánto restringe TBP es una elección del despliegue, no una propiedad del protocolo. Entre permitir-todo (modo monitor, todo registrado, nada bloqueado) y denegar-todo hay todo un espectro, moldeado por qué paquetes de reglas OPA carga una celda, en qué escala (abajo) opera, y hasta dónde lleva los contratos de plan, el quórum y la (planificada) capa de puntuación de riesgo (#177–#181). Un laboratorio personal y una celda de producción regulada pueden ejecutar el idéntico protocolo en puntos muy diferentes de ese espectro, y eso es por diseño, no una carencia — véase "Próximo trabajo planificado" más abajo para los presets de paquetes de reglas / postura planificados para la consola de administración por escala.
Exactamente dos cosas no se mueven, en ningún punto de ese espectro:
tbp4.2.1/README.md.
Estas son las categorías donde una acción mala no es reversible
revocando el acceso a posteriori; ninguna postura de despliegue, paquete de reglas o
escala las relaja jamás.Todo lo demás — cuán amplio es el envelope permitido, cuánta fricción acepta un operador, qué composiciones requieren una firma humana — es una elección entre complejidad, necesidad operativa y lo que un despliegue dado puede realmente ejecutar, no una propiedad del protocolo en sí.
Nota sobre el idioma: la especificación de referencia es ahora
docs/spec-en-v1.0.md (inglés) — este es el
documento contra el que deben construirse el código y las auditorías. Su número de versión
se reinicia a 1.0 deliberadamente: es un reinicio limpio hacia un documento citable y versionado
(§13: "versionado de forma conservadora; los cambios pasan por transiciones firmadas
y atestiguadas"), no una continuación del propio conteo de la nota de trabajo —
la nota de trabajo con número más alto no es el documento más nuevo. La
nota de trabajo del autor — más densa, menos lineal, útil para excavar en la justificación de diseño,
pero no la que hay que citar — existe en dos idiomas:
docs/spec-v1.4.10.md (inglés) y
docs/spec-v1.4.10.fr.md (francés original).
La misma convención se aplica en todo el repositorio: todo documento escrito originalmente
en francés tiene ahora un primario en inglés en su ruta original, con
el original francés conservado junto a él como <name>.fr.md. El glosario
(docs/glossaire.md) sigue siendo de origen francés (§14 del documento francés es
su fuente de verdad terminológica) con una columna de glosa en inglés para
legibilidad — esto no ha cambiado.
La especificación completa es docs/spec-en-v1.0.md
— es la fuente de verdad para cualquier decisión de diseño o configuración en
este repositorio. Este README solo resume lo necesario para orientarse;
en caso de duda, la spec manda. La nota de trabajo
(docs/spec-v1.4.10.md, traducción al inglés del original francés) no
queda superada en cuanto a contenido — es el mismo protocolo, desarrollado allí
primero — pero no es la referencia citable en adelante.