Lo que tiene que vivir en el código

La página de gating defendía que el código debe ser dueño del umbral. Esta página va un nivel más allá: algunas comprobaciones no deberían pedirse al modelo en absoluto.

La afirmación de límite más contundente que se ha publicado

La línea más dura viene de una implementación de bucle de agente:

Una llamada a herramienta con una puntuación de riesgo alta obliga a autorización humana, y ninguna probabilidad puede anularla.

«Ninguna probabilidad puede anularla» merece destacarse. No dice «la confianza debe ser muy alta» — dice que esta regla no está en el espacio de probabilidad. La distinción importa:

• «Aprobar automáticamente con ≥ 0.95» es una regla de umbral — en principio alguna probabilidad lo bastante alta la superaría.
• «Riesgo alto requiere aprobación humana» es una regla estructural — verdadera independientemente de lo que diga el modelo.

No son igual de fiables. Tu sistema debería ser explícito sobre qué comprobaciones son cuáles, y debería haber tantas reglas estructurales como sea posible.

Ejecuta primero las reglas deterministas, dale al modelo solo la zona gris

Otra formulación del mismo patrón:

Ejecuta primero las reglas deterministas: lo que se puede decidir se bloquea o se permite directamente, y el modelo es solo un backend opcional. Los comandos rutinarios se deciden localmente y nunca se envían al modelo.

Ejecutar las reglas primero tiene un beneficio infravalorado: reduce la superficie de ataque. Un juez que depende únicamente del modelo se comporta de forma impredecible bajo inyección de prompts; un juez que ejecuta las reglas primero confina la inyección a la pequeña porción que las reglas no pueden decidir.

Una prueba de inyección publicada reporta 300 intentos de inyección y dice sin rodeos qué atrapó la compuerta y qué se le escapó. Eso es mucho más útil que una simple afirmación de «protección contra inyección».

Secretos y datos sensibles: bloquear localmente primero

Un detector de secretos expone el orden con claridad:

Dos decisiones que recordar:

• El enmascarado va primero. No puedes enviar algo a un servicio externo para averiguar si es un secreto. La propia comprobación filtra información.
• Un modelo caído sigue preguntando a un humano, en lugar de permitir. Eso es fail-closed en su forma concreta — que un servicio no esté disponible no es razón para bajar en silencio el listón de seguridad.

Medido: 6/6 secretos bloqueados, 0/6 entradas benignas bloqueadas por error.

Límites de presupuesto, recibos firmados, auditoría

Algunas comprobaciones no tienen nada que ver con lo que dice el modelo, pero tienen que vivir en el mismo sistema:

• Un runtime asigna el bloqueo de comandos peligrosos y los límites de presupuesto a código determinista, y registra cada veredicto en una cadena de recibos firmados con Ed25519.
• Otro restringe la puntuación de riesgo a una escala de 0–100 controlada por código y firma cada veredicto con ES256 (540 llamadas, 99.76% y 0 falsos positivos con un umbral de 65–75).

El objetivo de firmar no es protegerse del modelo — es que después puedas saber qué pasó. Cuando una decisión automatizada causa un incidente, «qué dijo el modelo y qué hizo el código al respecto» tiene que ser verificable de forma independiente en lugar de depender de confiar en los registros.

Filtra la inyección en dos lugares

El diseño de una capa de guardarraíl merece mención aparte porque nombra dos puntos que se pasan por alto con facilidad:

Filtra una vez antes de que se ejecute una llamada a herramienta, y otra vez antes de que el agente lea el resultado de una herramienta.

El segundo es el que la gente olvida. Filtra solo la entrada y un ataque puede esconderse en lo que devuelve la herramienta — una página descargada, el contenido de un archivo —, que entra en el contexto habiendo eludido por completo la comprobación del lado de la entrada.

Una regla relacionada de una implementación aumentada por recuperación: nunca emitas un número que no aparezca en las fuentes citadas.

Sandboxing y permisos

Además de filtrar el contenido, la otra capa consiste en limitar el radio de impacto: las rutas protegidas siempre pasan por confirmación humana; la ejecución del agente corre en espacios de trabajo aislados (una implementación usa Docker); los permisos de los subagentes se separan de los del padre.

Una tabla de referencia

La columna del medio es el punto: cuanto más cerca de arriba, menos debería intervenir el modelo.

En una frase

Una comprobación que puede anularse por una probabilidad, tarde o temprano se anulará. Decide primero qué comprobaciones no se pueden anular; solo entonces ajusta los umbrales.