Un agente que solo puede leer es un buscador con peor latencia. El valor llega cuando puede registrar la prueba, actualizar la oportunidad o publicar el tablero; y esa es justamente la capacidad que una revisión de seguridad existe para acotar. Este desglose describe la puerta que se sitúa en la ruta de ejecución, y las tres propiedades que la distinguen de un diálogo de confirmación.
La distinción es estructural, no de grado. Un diálogo de confirmación se sitúa al lado de la ruta de ejecución y puede rodearse; una puerta se sitúa dentro de ella y no puede. Todo lo que sigue se deriva de ponerla en la ruta.
Del estándar
“a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI)”
La secuencia
- el modelo propone una llamada a herramienta
-
1 · VALIDACIÓN DE POLÍTICA Evaluada fuera del canal del modelo Contra una política que el modelo no puede ver, releer ni influir.
-
pasa
2 · VERIFICACIÓN DE MANIFIESTO ¿Está esta herramienta en el manifiesto de este turno? Manifiesto de sesión firmado — plataforma ∩ inquilino ∩ RBAC.
-
pasa
3 · PUERTA HUMANA — SOLO ESCRITURAS Se muestra el diff de impacto Aprobar · rechazar · escalar. La aprobación se fija a un token de versión y esquema.
- aprobado · token aún válido la escritura se ejecuta
- traza: turno → llamada → args → resultado → aprobador
Las lecturas pasan por las etapas uno y dos. Las escrituras pasan por las tres. La asimetría es deliberada: la latencia de lectura determina si el sistema llega a usarse, y una lectura dentro de los permisos que el usuario ya tiene no es el riesgo para el que existe la puerta.
Propiedad 1 — la política está fuera del alcance del modelo
La política de validación no está en el prompt. No está en un mensaje de sistema, ni en la descripción de una herramienta, ni en ningún texto que el modelo procese. Esto importa porque de lo contrario la defensa y el ataque comparten canal: todo lo que se escriba en el prompt para restringir al modelo es texto que una instrucción inyectada también puede dirigir.
Colocar la verificación fuera de ese canal es lo que convierte una inyección exitosa en una llamada de herramienta fallida en lugar de una escritura no autorizada.
Propiedad 2 — el radio de impacto se muestra, no se describe
La puerta renderiza un diff de exactamente qué cambiaría y a cuántos registros alcanza. No una frase que describa la acción: el cambio a nivel de campo en sí, y el conteo.
… 11 registros más, los mismos tres campos
El fallo que esto previene
A un aprobador al que se le muestra «actualizar los registros de oportunidad» no tiene forma de distinguir entre un registro y once mil. Aprobarlo no es una decisión; es un reflejo que la interfaz ha entrenado. Mostrar el conteo y el cambio a nivel de campo es lo que hace que la aprobación signifique algo en lo que un auditor pueda apoyarse después.
Propiedad 3 — las aprobaciones no pueden reproducirse
Cada aprobación se ancla a un token de versión de concurrencia optimista y al esquema contra el que se concedió. Si el plan subyacente cambia después de la aprobación —un registro editado por otra persona, una definición de herramienta actualizada, un parámetro modificado— el token ya no coincide y la escritura se rechaza.
Rechazada, no re-aprobada automáticamente ni reintentada en silencio contra el nuevo estado. La aprobación se concedió contra algo específico, y cuando eso cambia el comportamiento correcto es detenerse y volver a preguntar.
Dónde se acota la capacidad, no solo la acción
La puerta es la última línea, no la única. El catálogo de herramientas disponible en cada turno se calcula como la intersección de la capacidad de la plataforma, los derechos del inquilino y el rol del usuario que actúa, y se compila en un manifiesto de sesión firmado. Una capacidad fuera de esa intersección no se deniega meramente en la puerta: está ausente del manifiesto, así que no hay nada que una instrucción inyectada pueda alcanzar.
Esta es la diferencia entre un sistema que rechaza una acción no autorizada y uno donde la acción no autorizada nunca fue expresable.
Qué registra la traza
Una traza distribuida abarca ambos planos, y para cualquier escritura un auditor puede reconstruir qué turno disparó qué llamada de herramienta, con los argumentos que recibió; qué devolvió esa llamada y qué cita del texto apunta a ella; y quién aprobó la escritura resultante, cuándo y contra qué versión.
El trazado debe estar presente en cada punto de llamada o la cadena tiene huecos, y una cadena con huecos no es un rastro de auditoría: es un registro. Por eso la instrumentación no es una preocupación de segunda fase: adaptarla después produce cobertura en todas partes salvo en los sitios que eran difíciles, que son los que importan.
El costo honesto
Una puerta en cada escritura significa que hay un humano en la ruta de cada escritura, y eso es un techo de rendimiento. Es el techo correcto en un contexto regulado: en el despliegue de verificación del que proviene este patrón, una escritura desatendida en un plan de pruebas es en sí misma un defecto, así que el sistema simplemente no tiene esa capacidad, y el número de escrituras sin revisar es cero por construcción y no por política.
Donde el volumen importa más que la reversibilidad, este es el diseño equivocado y un radio de impacto más estrecho con ejecución desatendida es mejor compromiso. La pregunta a resolver primero no es cuánto confía en el modelo. Es qué podría hacer la peor escritura individual antes de que alguien lo notara.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.