Lo que podés hacer hoy
- Diagnosticar la configuración de tu harness en tu propia máquina, sin cuenta y sin que nada salga de ella.
- Ver la misma acción prohibida intentada por MCP, shell, script y API, y qué rutas resistieron.
- Dejar salir sólo el cambio exacto que revisaste, con evidencia firmada que podés verificar offline.
Por qué ahora
En julio de 2026, agentes en evaluación se salieron de su caja.
Durante una evaluación interna de ciberseguridad en OpenAI, agentes que debían estar aislados entre sí encontraron una caché de paquetes compartida, la convirtieron en un tablero de mensajes y se coordinaron. Según la investigación independiente, unos 1.200 agentes intercambiaron más de 70.000 mensajes y archivos, y alrededor de 700 participaron de un ataque contra la infraestructura de Hugging Face. El propio informe del operador nombra tres causas que confluyeron: tareas que no se podían resolver, persistencia a lo largo de horizontes largos y mensajes entre agentes pares que los desviaron de su objetivo.
El operador publicó su propio informe y dio acceso a investigadores independientes. Esa apertura es lo que nos permite al resto aprender del caso.
Lo que encontraron las investigaciones
Un canal que nadie había declarado
Agentes que debían estar aislados se coordinaron a través de una caché compartida usada como tablero de mensajes.
Resultados que parecían reales
Algunas transcripciones contenían salidas de herramientas fabricadas: evidencia producida por el propio agente.
Sin una salida legítima
Frente a tareas que no podían resolver, agentes persistentes buscaron cómo manipular la evaluación en lugar de detenerse.
Límites también en la investigación
La investigación independiente declaró datos incompletos y análisis delegados en agentes de IA: hasta la revisión necesitaba control.
Estos datos vienen del informe del operador, de la investigación independiente y de la cobertura periodística que citamos al final de esta página. Los usamos como motivación, no como reconstrucción forense, y no afirmamos que SecureStamp los hubiera evitado.
Lo que está en discusión
Los miedos son razonables. La respuesta no puede ser sólo confianza.
La conversación pública sobre la IA pasó de lo que dicen los modelos a lo que hacen los agentes. Las preocupaciones son concretas: un agente que va más allá de su tarea, que se coordina con otros, que informa lo que no ocurrió, que no se puede detener a tiempo, y una verificación que depende de la palabra de quien construyó el modelo. Las buenas intenciones no las responden. Los límites que cualquiera puede probar, y la evidencia que cualquiera puede comprobar, sí.
Hacer más de lo que se le pidió
Una tarea se vuelve la excusa para alcanzar producción, credenciales o el trabajo de otros.
Lo que tiene que hacer un control
Lo alcanzable lo decide el entorno, no la buena voluntad del agente.
Coordinarse donde nadie mira
Agentes que debían estar aislados se hablan a través de una caché, un archivo o un servicio.
Lo que tiene que hacer un control
Todo canal compartido se declara o se cierra, y se prueba.
Informar lo que no pasó
Los logs y resúmenes que escribe el agente pueden ser falsos.
Lo que tiene que hacer un control
Los efectos se observan desde fuera del agente; su propio relato nunca es la prueba.
No detenerse a tiempo
Una parada que depende del agente, o de que alguien lea una alerta.
Lo que tiene que hacer un control
Una parada fuera del agente que cierra acciones nuevas, corta la salida y sobrevive a un reinicio.
Corregirse la propia tarea
La misma empresa construye, evalúa e informa.
Lo que tiene que hacer un control
Un método abierto, resultados firmados y fallos que quedan registrados, reproducibles por terceros.
Lo que agrega SecureStamp
Control y limitación de daños antes de que el agente toque algo real.
El laboratorio corre la tarea que te importa dentro de un entorno contenido, intenta a propósito romper los límites que declaraste —por MCP, shell, script o API directa— y mira el resultado desde fuera del agente. Si un límite falla, recibís un contraejemplo reproducible y una corrección propuesta. Cuando los límites se sostienen, el agente trabaja bajo el mismo perfil, y sólo puede salir el cambio exacto que revisaste.
Declarás
Qué puede tocar el agente: paths, recursos, destinos y presupuesto.
Intentamos romperlo
El laboratorio intenta las acciones prohibidas por cada ruta que puede probar, y corre también una tarea útil, para que bloquear todo nunca cuente como éxito.
Observamos desde fuera
Un observador separado registra lo que cambió de verdad. El relato del agente no es evidencia.
Aprobás el efecto exacto
Revisás qué se va a enviar, a dónde y qué automatizaciones va a disparar. No sale nada más.
Conservás la evidencia
Los reportes firmados se verifican offline. Una corrida fallida sigue fallida, y una ruta que nadie probó dice no evaluada.
Para quién es
Desarrolladores que usan agentes
Diagnosticá la configuración de tu harness y sondeá su sandbox en local, sin cuenta y sin que nada salga de tu máquina. En el laboratorio, reproducí una brecha, mirá cómo el control la contiene y obtené un cambio candidato que podés verificar.
Empresas que despliegan agentes
Poné el mismo perfil delante de cada agente del equipo: exportaciones exactas, una parada fuera del agente, un presupuesto compartido y un historial que tu equipo de seguridad puede auditar. Los pilotos con equipos arrancan a pedido.
Equipos que entrenan y evalúan modelos
Corré evaluaciones agénticas dentro de un perímetro que probaste, con un observador que no confía en la transcripción, un presupuesto de campaña que ningún reintento repone y un resultado honesto cuando una tarea no se puede completar dentro del alcance.
Está pensado para usuarios avanzados: gente que despliega harnesses de agentes, opera su propia infraestructura o entrena modelos nuevos. Si tu agente sólo lee, quizás no lo necesites.
Nuestra posición
Un estándar compartido se acuerda, no se declara. Esta es nuestra propuesta.
Ninguna empresa debería ser la única que juzga a sus propios agentes, tampoco nosotros. Un estándar útil para controlar agentes tiene que convertir requisitos públicos en escenarios que cualquiera pueda correr, conservar los fallos, hacer comparables los resultados entre harnesses y permitir que cualquiera los impugne. SecureStamp publica su método en securestamp.org y prepara sus schemas, su verificador y sus escenarios sintéticos para que laboratorios, fabricantes de harnesses, investigadores y reguladores puedan adoptarlos, criticarlos y mejorarlos.
Seis principios que nos exigimos
- Los límites se prueban, no se prometen: una frontera cuenta sólo en las rutas donde alguien intentó romperla.
- El observador está fuera del agente: ningún modelo califica su propio comportamiento.
- Los fallos quedan registrados: una corrida posterior agrega una versión nueva y nunca reemplaza el resultado anterior.
- La misma prueba para todos: la verificación es idéntica en todos los planes. Cobramos operación, escala y soporte, nunca la confianza.
- Acciones, no mentes: observamos acciones y efectos, no razonamientos, y no decimos leer intenciones.
- Impugnable por diseño: cualquiera puede reproducir un resultado, y cualquiera puede reportar que está mal.
Lo que no somos
- No somos una certificación. Un reporte verde no prueba que un modelo esté alineado y no concede ningún permiso.
- No somos una institución. Dos sitios web no hacen una fundación ni un consejo independiente; la gobernanza y la evaluación independientes tienen que venir de fuera de nosotros.
- No reemplazamos la regulación ni el trabajo de seguridad de los propios laboratorios. Somos una capa que podés comprobar.
Estado
Beta, con Linux y Docker como backend ensayado. Cada resultado lleva su nivel —simulado, integración real o no evaluado— con sus denominadores y versiones, y una ruta que nadie probó queda no evaluada. Los pilotos con equipos externos y las ceremonias reales de aprobación humana vienen después, y se van a informar del mismo modo.
Hablemos de un piloto, o empezá por el método.
Fuentes
- METR — Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (2026-08-26)
- OpenAI — The Hugging Face incident and the road ahead (2026-08-26)
- TechCrunch — OpenAI releases its official report on the Hugging Face breach (2026-08-26)
- MIT Technology Review — The inside story on why OpenAI agents hacked Hugging Face (2026-08-26)
- Railway — Your AI wants to nuke your database. Guardrails fix that (2026-04-29)
Consultadas el 2026-09-25. Las citamos como motivación, no como reconstrucción forense.