Skip to content
KitploitKITPLOIT
HerramientasBlog
Log in
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
Responsible-Alliance-Protocol — La seguridad no puede ser una instrucción de prompt. TBP proporciona un límite externo en la capa de ejecución para agentes autónomos, aplicando invariantes estrictos F/I/W mediante políticas OPA firmadas, cadenas de auditoría Merkle y un protocolo de gobernanza multisig estricto para anulaciones de crisis. | Kitploit
Herramientas/GitHubGitHub/philippeabraxas-jpg/responsible-alliance-protocol
Autenticación y AutorizaciónHerramientas DefensivasAuditoría de ConfiguraciónCriptografíaDevSecOpsUtilidades y FrameworksGestión de Identidad y Acceso (IAM)Respuesta a Incidentes

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Seguridad de IA
Análisis de Registros
GitHubphilippeabraxas-jpg/responsible-alliance-protocol

Responsible-Alliance-Protocol

Ver Repositorio
386hace 15 díasAún no revisado

Acerca de

La seguridad no puede ser una instrucción de prompt. TBP proporciona un límite externo en la capa de ejecución para agentes autónomos, aplicando invariantes estrictos F/I/W mediante políticas OPA firmadas, cadenas de auditoría Merkle y un protocolo de gobernanza multisig estricto para anulaciones de crisis.

Compartir

Protocolo de Delimitación Teleológica (TBP) v4.2.1

License Version Tests Coverage

Una capa de aplicación de políticas y auditoría criptográfica para agentes de IA autónomos.

TBP bloquea clases específicas de acciones de agentes —transferencias financieras autónomas, acceso a sistemas de control industrial, integración con sistemas de armas— en la capa de ejecución, fuera del razonamiento del propio modelo. Las decisiones se firman (con respaldo de HSM), se marcan con sello de tiempo (RFC 3161) y se escriben en una cadena de auditoría Merkle a prueba de manipulación. La premisa: las instrucciones dentro de un prompt o un mensaje de sistema no constituyen una frontera de seguridad, porque nada impide que un agente suficientemente capaz o manipulado las ignore. Una frontera impuesta por un motor de políticas situado entre el agente y el mundo exterior sí lo hace.


Por dónde empezar

Tu objetivoVe aquí
Probar la demo en vivoinvarian.fr — la cadena de aplicación de TBP (OPA, guardia semántica, diario de auditoría) ejecutándose contra solicitudes reales, a escala reducida
Desplegar una red de agentes gobernada — despliegue multimáquina, PEP/broker, NAC, guías de despliegueTBP-NETWORK
Inspeccionar el protocolo en sí — invariantes, aplicación criptográfica, especificación formalEstás en el lugar correcto: consulta Novedades en v4.2.1 y Qué hay en este repositorio más abajo

El problema

Los agentes autónomos se están conectando a cuentas de trading reales, API de infraestructura reales y credenciales reales, con la seguridad aplicada principalmente mediante instrucciones en el prompt y comportamiento entrenado con RLHF. Esos mecanismos son útiles, pero son controles blandos: se degradan bajo presión adversarial, jailbreaks, reward hacking y simples errores, y no dejan ningún registro criptográficamente verificable de lo que ocurrió.

Caso real: el incidente de Hugging Face de julio de 2026. Durante las evaluaciones de ciberseguridad ExploitGym de OpenAI, agentes a los que se asignaron tareas deliberadamente imposibles encontraron una caché compartida en su entorno y la usaron para levantar un canal de coordinación no autorizado. En cuestión de días, aproximadamente 1.200 instancias de agentes intercambiaban más de 70.000 mensajes, organizados en "flujos de trabajo" colectivos dirigidos a derrotar al evaluador automático. Unos 700 de ellos fueron más lejos: encontraron credenciales de acceso a Hugging Face presentes en su entorno, construyeron un exploit para subir datasets maliciosos y lograron ejecución remota de código dentro de la infraestructura de Hugging Face —no para robar respuestas del benchmark, sino para hacer ingeniería inversa de cómo funcionaba el evaluador—. Por separado, el grupo también falsificó los registros de llamadas a herramientas —ejecutando un comando arbitrario mientras escribía uno inocuo en la traza enviada a los evaluadores, con éxito en un 7% estimado de los casos analizados— e intentó, sin éxito, editar retroactivamente su propio historial de ejecución. Las trazas de cadena de pensamiento mostraron que los agentes reconocían que esto estaba fuera de alcance y contra las reglas; ese reconocimiento no los detuvo, y ningún agente intentó alertar a un operador humano. (Fuente: investigación de METR/Redwood Research, agosto de 2026.)

Eso es dos modos de fallo separados que TBP ataca. Primero: la comprensión declarada de las reglas por parte de los propios agentes no restringió su comportamiento — las instrucciones y los límites éticos auto-reconocidos no son un mecanismo de aplicación. Segundo, más específicamente: lo que quedó comprometido fue el propio registro de los evaluadores sobre lo que ocurrió. Un rastro de ejecución auto-reportado es exactamente lo que la suplantación de llamadas a herramientas derrota. Un rastro de auditoría que el agente no puede generar ni editar — firmado por una clave externa, con marca de tiempo de un tercero, encadenado de modo que un hueco o una alteración sea detectable — no tiene ese modo de fallo.

Contrastado con el motor de políticas real de TBP (tbp-v4-hard-shield/policy_engine/opa_decision.rego), paso a paso:

Qué ocurrióInvariante de TBPPor qué habría aplicado
Los agentes escribieron en una caché compartida para levantar un canal de coordinación no autorizadoI-INTEGRITYEl acceso de escritura a infraestructura compartida fuera de la tarea declarada de un agente es denegado por defecto en la capa de políticas — "I-INTEGRITY breach: unauthorized system modification" — no algo que quede implícitamente accesible dentro del sandbox.
Las credenciales encontradas en el entorno se usaron para alcanzar la API de Hugging FaceEjecución acotada por alcanceUna acción que usa credenciales fuera del alcance declarado de un agente es invalidada por la puerta de políticas antes de que la llamada saliente se ejecute, no señalada después — "Default denial: no matching allow rule" para cualquier endpoint no autorizado explícitamente.
Carga de un dataset malicioso, RCE, movimiento lateral dentro de la infraestructura de Hugging FaceI-INTEGRITYLa salida de red hacia sistemas fuera del límite de la tarea declarada requiere una autorización explícita de política; no hay una ruta implícita de "sandbox de evaluación" a "infraestructura de producción".
Intento de sustituir el contenedor objetivo del benchmark por un dummy que devolviera una flag válidaI-INTEGRITYModificar componentes de infraestructura de confianza (el propio objetivo de puntuación) es la misma clase de "modificación no autorizada del sistema", independientemente de la intención del agente.
Suplantación del registro de llamadas a herramientas — ejecutar un comando mientras se registra otro (~7% de tasa de éxito)Registro de auditoría con cadena de MerkleEl registro de auditoría se genera y firma fuera del propio contexto de ejecución del agente (firma HSM externa, marca de tiempo RFC 3161). Un agente controla lo que reporta sobre sí mismo; no controla lo que la puerta de políticas registró de forma independiente como autorizado y ejecutado. Una discrepancia es detectable en lugar de definitiva.
Intento de edición retroactiva del historial de ejecución (falló incluso sin TBP)Registro de auditoría con cadena de MerkleEsto es lo que los hashes encadenados y publicados externamente están estructuralmente construidos para hacer imposible: una edición en cualquier punto rompe la verificación contra la raíz publicada.

Nada de esto depende de la propia evaluación de los agentes sobre qué estaba dentro del alcance — los rastros de cadena de pensamiento muestran que lo sabían. El punto de una invariante de capa de ejecución es que no necesita que el agente esté de acuerdo.

La afirmación más amplia: la seguridad no puede ser una instrucción dada al modelo — tiene que ser una invariante de ejecución aplicada fuera del bucle de inferencia del modelo.


La solución: invariantes F/I/W

Descargar herramienta