Quince adversarios atacan nuestra defensa las 24 horas. Cada brecha la hace más fuerte.
Cada persona se especializa en una clase de ataque distinta — inyección de prompts, ingeniería social, exfiltración de datos, compromiso de la cadena de suministro — en los cuatro checkpoints, sin pausa. En cuanto una encuentra una brecha, esa brecha se convierte en una detección revisada y firmada criptográficamente que protege a todos los agentes de la red, no solo a la arena.
Quince adversarios, cada amenaza en cada checkpoint
Cada uno de nuestros quince adversarios con nombre ocupa una celda de la matriz de amenazas: una clase de ataque concreta en un checkpoint concreto. The Substrate Mole, por ejemplo, ejecuta ataques a la cadena de suministro en el checkpoint de integridad. A medida que la defensa se endurece, cada adversario muta dentro de su especialidad —ahondando, no divagando—, de modo que la cobertura sigue completa y la presión, enfocada.
front door
Puerta delantera — prompts entrantes y resultados de herramientas: inyección de prompts, inyección indirecta, fraude del CEO, jailbreaks, secuestros multironda, suplantación de agentes, variantes multilingües y ruido en ráfaga.
inside.autonomy
Checkpoint de autonomía — lo que el agente puede hacer: sondeo de los límites de las herramientas, llamadas a herramientas no declaradas y acciones que exceden el mandato del agente.
inside.integrity
Checkpoint de integridad — cómo razona el agente: integridad de la cadena de razonamiento, compromiso de la cadena de suministro (The Substrate Mole), blanqueo de prompts y deriva de valores.
back door
Puerta trasera — respuestas salientes: prevención de pérdida de datos, exfiltración de credenciales y canarios, fugas de PII/PHI y fugas del prompt de sistema.
Cuando la defensa empieza a ganar, los ataques evolucionan
La arena pasa la mayor parte del tiempo buscando nuevas formas de penetrar. Pero cuando la defensa atrapa de forma fiable una clase de ataque, la arena cambia de marcha ahí: deja de repetir ataques conocidos y empieza a mutarlos, poniendo a prueba la defensa parcheada en lugar de confiarse. Cada clase de ataque se sigue por separado, así que la arena puede endurecer un área mientras sigue explorando otra.
Umbral de entrada
95% atrapado, sostenido
Volumen suficiente (180–360 sondeos) para reaccionar rápido sin perseguir el ruido.
Ventana
48 horas rolling
Ventana continua hacia atrás, no por periodos de calendario.
Histéresis de entrada
24 horas sostenidas
Un pico no lo activa: la tasa debe mantenerse un día entero.
Histéresis de salida
24 horas sostenidas
Un bucket debe permanecer por debajo del umbral de salida durante 24 horas antes de volver al modo de búsqueda.
Umbral de salida
90% atrapado
Por debajo del umbral de entrada para que el sistema no oscile en el límite.
Independencia por bucket
por sustrato, sector, patrón y origen
Un agente financiero puede estar endureciéndose contra el fraude del CEO mientras aún explora la inyección de prompts: cada uno se sigue por separado.
Encuadre honesto
Esta activación adaptativa está construida y desplegada en nuestra arena. Informaremos de la primera vez que se active en producción en /trust/advisories: no contamos el código terminado como probado en el mundo real.
La arena puede encontrar una debilidad. No puede publicar la solución por sí sola.
La arena funciona con su propia identidad de alcance reducido. Solo puede hacer una cosa: presentar una detección candidata para revisión humana. No puede promover una regla, editar una activa, retirar ninguna ni tocar nada más. Cada candidata se marca —desde el servidor, nunca el cliente— con su procedencia, de modo que un hallazgo de la arena nunca puede hacerse pasar por un informe de cliente o una acción de operador.
writer_identity = arena-bypass
auth = ARENA_RECIPE_CANDIDATE_TOKEN
write_scope = recipe_candidates only
read_scope = none (no live-rule visibility)
promote_scope = none (separate reviewer auth required)Scope
Las credenciales de la arena abren exactamente una puerta: presentar una candidata para revisión. Sin acceso de lectura a las reglas activas. Sin acceso de escritura a nada más.
Origen marcado por el servidor
El origen de cada candidata lo fija el servidor a partir de la identidad autenticada, nunca el cliente. La arena no puede suplantar un informe de cliente ni a un operador.
Auditoría solo de adición
Cada acción sobre cada regla se registra en un log de solo adición: quién hizo qué y cuándo. Promover un hallazgo de la arena sigue requiriendo un revisor humano autenticado por separado.
Control dual, obligatorio
Las reglas que pueden bloquear tráfico real de producción nunca se promueven solas, sin importar el origen ni la configuración. Se requieren dos revisores autenticados, y ese requisito lo impone la propia base de datos, no un proceso que pueda omitirse.
De una brecha en la arena a protección activa: cinco pasos revisados
Cinco etapas convierten una brecha de la arena en protección activa. Cada paso se registra en un rastro de auditoría de solo adición. Es la misma vía por la que pasan los informes de clientes y nuestra inteligencia entre clientes: la arena es una de tres fuentes de señal, no un atajo.
1 · Bypass encontrado
Un adversario logra pasar. El hallazgo se presenta como candidato para revisión: aún no hay nada activo.
2 · Revisión humana
Los operadores triplican cada candidata. Por defecto es una aprobación manual; la aprobación automática más rápida es opcional y solo se aplica a reglas de aviso: todo lo que pueda bloquear tráfico real siempre necesita dos personas.
3 · Promoción firmada
Las reglas aprobadas se firman criptográficamente, y cada aprobación —creada, revisada, firmada— se registra en el rastro de auditoría de solo adición.
4 · Distribución redundante
Cada regla firmada se escribe en dos almacenes con claves independientes y se verifica antes de que ningún gateway la cargue. Envenenar el plano de reglas exigiría vulnerar varios sistemas independientes a la vez.
5 · Observar y luego aplicar
Las nuevas reglas se ejecutan en modo observe durante 24 horas. Si su tasa de falsos positivos se mantiene limpia, se promocionan a enforcing; si no, se revierten — confirmado por el operador hoy, automático en una fase posterior.
Lo que esta página afirma — y lo que no.
Toda afirmación de carga en esta página cita una referencia pública. Los puntos siguientes son los aplazamientos que nombramos a propósito — los CISOs respetan la divulgación honesta de restricciones; castigan la restricción descubierta.
Las pruebas de presión adaptativas están construidas y desplegadas en nuestra arena. Aún no se han activado en producción; cuando ocurra, lo publicaremos en /trust/advisories.
La arena es el laboratorio. Los bypass encontrados aquí no cuentan como detecciones reales. Una detección promovida pasa por la aprobación de un revisor y un periodo de observación de 24 horas antes de aplicarse: lo que ves en /dashboard/threats es el resultado de esa vía, no la arena directamente.
En la GA, la lista de advisories muestra un único post-mortem sintético, claramente etiquetado como sintético. El IoC feed está vacío por diseño. El sistema dice la verdad — no fingimos actividad para parecer ocupados.
Las reglas de aviso se publican autopromovidas en el lanzamiento. Las reglas que pueden bloquear tráfico de producción requieren dos revisores autenticados, y ese requisito ya se impone hoy en la plataforma.
De la arena a su flota.
La arena es una de tres fuentes de señal que alimentan la AEGIS Protection Network, junto con los informes de clientes y nuestra inteligencia entre clientes. Las tres pasan por la misma vía de promoción firmada.
Su threat thermometer
Estado en vivo para su flota en /dashboard/threats. Calm at GA by design — cuando algo cambia, usted lo ve primero.
La red L0-L5 completa
Identidad de amenazas, inteligencia entre clientes, la superposición bajo ataque, la distribución de reglas gestionadas, tu termómetro de amenazas y el feed de IoC: toda la red de protección, de principio a fin.
Hable con nosotros
Enterprise, sectores regulados, despliegues self-hosted — los temas que merecen una conversación, no un checkout.
