Plano de control

Cómo se constrain realmente al agente

La defensa contra prompt injection es una sola línea de un sistema mucho más grande. Esta página muestra la pila completa: qué está escrito, qué se impone mecánicamente antes de que corra una herramienta, qué se detecta haciendo patrones sobre el propio cableado, qué capacidad se concede y qué se mide después.

Casi todo lo que se dice sobre «seguridad de agentes de IA» se detiene en el filtro de entrada: detectar la instrucción mala antes de que el modelo la lea. Ese filtro importa, pero protege un solo momento. El resto del tiempo el riesgo está en otro lado — el agente tiene una herramienta, la herramienta tiene un nombre que parece seguro, y el modelo la llama a las 3am sin que nadie lea la transcripción.

Una instrucción le pide al modelo que se comporte. Un control le quita la herramienta.

Esa es la diferencia entre una regla y un control. Una regla es un párrafo que se le pide al modelo que lea y recuerde. Un control es código que se ejecuta coopere el modelo o no. Todo lo de abajo es un control, y cada control está contado.

Cinco capas, en el orden que las atraviesa una petición

Cada capa responde una pregunta distinta, y cada una tiene un tamaño medible. Una pila con una sola capa sería un filtro; una pila con cinco es un plano de control.

Política escrita

¿Qué es siempre cierto, lo pregunte quien lo pregunte?

Qué es

Las restricciones existen como texto antes de que corra nada. Declaran lo que tiene que cumplirse en cada repositorio, cada sesión, cada commit — y son la especificación contra la que se verifica la capa de ejecución de abajo, no notas que yo debo recordar.

Cómo funciona

Las reglas se emparejan por tema y se cargan en el contexto automáticamente, así que la misma decisión recibe la misma respuesta venga de una instrucción humana, de un comentario en el código o de una sesión nueva sin memoria del ayer.

Evidencia

Archivos de reglas: 108
Corpus de reglas: 809 KB

Ejecución conectada

¿Qué detiene de verdad una herramienta?

Qué es

Las verificaciones corren en puntos fijos del ciclo de vida del agente: antes de una llamada a herramienta, después, al iniciar sesión, al compactar el contexto, al terminar el agente. Están conectadas al runtime que realmente ejecuta — no a un archivo de configuración que alguien recuerda abrir.

Cómo funciona

Cada verificación es un programa pequeño con permiso para negarse. Una negativa aparece en la transcripción con su motivo adjunto, así que la restricción es un evento con timestamp, no una promesa con buenas intenciones.

Evidencia

Verificaciones conectadas: 36
Puntos del ciclo: 13
Scripts de verificación: 88

Detección verificada

¿Cómo sabes que un control todavía funciona?

Qué es

La capa de ejecución está, a su vez, bajo prueba. Las suites de abajo enuncian cada una una condición que debe cumplirse — un cerrojo que debe estar cerrado, un script que debe existir, un fallo que no debe tragarse — así que las verificaciones se comprueban en vez de darse por supuestas.

Cómo funciona

Los fallos que importan no son los que rompen. Son los que parecen bien: un guard que nunca se conectó, un script que ya no existe, un paso de build cuyo exit code se descarta. Esos pasan cualquier test normal, así que se encuentran haciendo patrones sobre el propio cableado.

Evidencia

Suites de prueba: 18
Aserciones: 356

Capacidad, no herramientas

¿Qué puede tocar el agente?

Qué es

Hay servidores de herramientas conectados al runtime, y los que construí para esto declaran ser de solo lectura, con una afirmación explícita de lo que pueden y no pueden hacer. Un servidor que solo lee no es un privilegio menor: es otro tipo de privilegio.

Cómo funciona

El acceso se filtra por intención. Una pasada de solo lectura expone únicamente las herramientas que no pueden cambiar estado, así que una instrucción perdida no alcanza un camino de escritura a través de una herramienta de lectura. Subir la intención es un acto explícito y registrado, nunca el default.

Evidencia

Servidores de herramientas: 17
Construidos para esto: 7

Cuánto costó

¿Qué consumió realmente la ejecución?

Qué es

Cada petición se enruta, se cuenta y se valora en la frontera del upstream: tokens de entrada, de salida, servidos desde caché, costo, reintentos, caídas. El dashboard de operación vive de estos contadores, y las cifras de abajo son los mismos contadores que él lee.

Cómo funciona

Medir es lo que convierte «funcionó» en un argumento. Una petición que cayó a un segundo upstream, un prefijo que se mantuvo estable a lo largo de mil llamadas, un límite que se alcanzó y del que se salió bien — cada uno es un contador con historial, no una anécdota.

Evidencia

Peticiones enrutadas: 1,525
Tokens leídos de caché: 127,854,687

Tres formas de fallar en silencio

Un control que está conectado, probado y documentado aun así puede no hacer nada. Estas son las tres fallas que el scanner sabe nombrar, explicadas como las situaciones que son y no como patrones de regex.

El guard que nunca se conectó

hook-not-wired

Se escribió un guard, se subió, se documentó y se revisó. El script que lo impone existía en disco. Pero el archivo que conecta el runtime con ese script nunca lo mencionó, así que nunca corrió — y nadie lo notó, porque la ausencia de un guard se ve exactamente igual que su presencia.

Lo que cuesta

Toda regla que se apoyaba en ese guard era decorativa. Cada acción que debía rechazar quedó permitida, mientras la documentación afirmaba lo contrario.

Cómo se encuentra

El scanner compara los scripts que existen contra las entradas que están conectadas y reporta la diferencia por nombre. La clase es hook-not-wired: presente en el sistema de archivos, ausente del runtime.

El build que no podía fallar

silent-failure

Una cadena de build terminaba con una construcción que descarta el exit code de todo lo anterior. El build estaba roto. El gate que debía impedir el deploy reportó éxito igual. El deploy subió el artefacto anterior, y los logs dijeron que todo estaba bien.

Lo que cuesta

La falla fue invisible justo en el momento en que más importaba — el gate que existía para detener el deploy pasó en vez de bloquear.

Cómo se encuentra

El scanner parsea la cadena de comandos y marca la forma donde un paso que se traga errores queda delante de un gate. La clase es silent-failure: el script es sintácticamente válido y siempre reporta éxito.

La puerta a una sala vacía

declared-but-absent

Al runtime le dijeron que corriera una verificación en cierto momento y nombraron la verificación. El script al que apunta no existe — lo renombraron, lo movieron, o nunca se comiteó. El cableado está intacto y resuelve a la nada.

Lo que cuesta

Toda una clase de verificaciones dejó de correr sin quitar una sola línea de configuración. Bajó el conteo de guards activos y el dashboard no lo dijo, porque el dashboard contaba declaraciones y no ejecuciones.

Cómo se encuentra

El scanner resuelve cada ruta declarada y reporta las que no se pueden resolver. La clase es declared-but-absent: el runtime cree que está protegido, y no lo está.

El sistema auditándose a sí mismo

El plano de control escanea su propio cableado de forma periódica y publica lo que encuentra — incluidos los hallazgos que siguen abiertos, incluido el que bloquea. Un sistema que lista sus propias brechas es otra propuesta distinta a uno que afirma no tener ninguna.

1 bloqueantes3 advertencias1 informativos5 hallazgos abiertos

Una verificación declarada no tiene script

blocker

El runtime referencia una verificación cuyo script no existe, así que esa verificación nunca puede correr. Es la clase de mayor severidad porque quita protección sin quitar la apariencia de protección.

Un guard existe pero no está conectado

warn

El script está presente y es ejecutable, pero el runtime no lo referencia. La protección está escrita, revisada y subida — y no está activa.

Un servicio en segundo plano no está corriendo

warn

Un helper de larga vida del que dependen otras verificaciones está en estado fallido. Hoy no bloquea nada, pero lo que dependa de él depende de un servicio que está caído.

Una verificación propuesta no tiene receta de cableado

info

Una nota propone una verificación nueva pero no registra cómo instalarla. Las propuestas así son fáciles de escribir y fáciles de olvidar; el arreglo es guardar la receta junto a la propuesta.

Cuánto cuesta realmente una ejecución

Cada petición que entra a la capa de enrutamiento se cuenta en la frontera del upstream. Estos son los contadores vivos del dashboard de operación, leídos en el mismo momento que el snapshot del corpus de arriba.

Lectura de caché por token fresco

3.27×

Peticiones servidas desde prefijo en caché

92.5%

Tokens manejados en total

167,933,880

Costo combinado por millón de tokens

$0.061669

Peticiones enrutadas: 1,525Cada llamada que entró al router, sin importar qué upstream la tomó.
Decisiones de ruteo: 1,525Cuántas veces el router eligió upstream para una petición.
Peticiones con prefijo en caché: 1,411Llamadas donde se encontró un prefijo reutilizable, así que el upstream no tuvo que recomputarlo.
Tokens leídos de caché: 127,854,687Contexto servido desde un prefijo guardado en vez de recomputarse desde cero.
Tokens de entrada frescos: 39,051,470La parte del prompt que tuvo que procesarse en frío.
Tokens de salida: 1,027,723Lo que el modelo devolvió.
Prefijos que quedaron estables: 679Llamadas cuyo prefijo de contexto ya estaba en el orden que lo hace cacheable.
Prefijos reordenados: 846Llamadas cuyo prefijo tuvo que reordenarse antes de poder cachearse.
Golpes a un límite: 10Veces que una petición chocó con el límite de un provider y se reintentó contra otro upstream.
Recuperadas tras el límite: 10De esos reintentos, cuántos terminaron en una respuesta exitosa.
Aperturas del circuit breaker: 0Veces que un upstream salió de la rotación tras fallar repetidamente.
Caídas totales: 0Veces que no había upstream disponible y la petición no pudo servirse.
Costo combinado: $10.356380Gasto total entre todos los upstreams, después de cualquier failover.

El corpus detrás

El tamaño del sistema que impone: cuánto está escrito, cuántas verificaciones existen, cuántas están conectadas y cuánto de todo eso está bajo prueba.

Archivos de reglas: 108
Corpus de reglas: 809 KB
Verificaciones conectadas: 36
Puntos del ciclo: 13
Scripts de verificación: 88
Servidores de herramientas: 17
Construidos para esto: 7
Suites de prueba: 18
Aserciones: 356
Archivos fuente: 174
Líneas de código: 45,338

Desglose por evento del ciclo de vida

PreToolUse13
PostToolUse4
SessionStart4
PostCompact3
PermissionRequest2
PreCompact2
Stop2
Notification1
PostToolUseFailure1
SessionEnd1
SubagentStart1
SubagentStop1
UserPromptSubmit1