Saltar al contenido

BLOG

Cómo está cableado el agente

  • arquitectura
  • gobernanza

El agente es el núcleo gobernado de la plataforma. Todo lo que un agente de T6X puede hacer pasa por el mismo cableado: un permiso que se consulta, una compuerta que puede suspender el turno, un intermediario que sostiene las credenciales que el agente nunca ve, y una traza encadenada por hash que registra lo que ocurrió.

Este texto recorre ese cableado. No es una lista de características, es el camino que hace una llamada a herramienta desde que el modelo la pide hasta que se ejecuta, con los componentes que la pueden detener en cada tramo.

Una premisa antes de empezar, porque ordena todo el diseño: asumimos que el modelo va a ser convencido de hacer algo que no debería. La inyección de prompts es un problema abierto en toda la industria y nadie ha publicado una solución. Así que ningún control de este sistema vive en el prompt. Los componentes que dicen que no son un ejecutor en Rust, un intermediario, un rol de base de datos y un predicado SQL, y a ninguno se le puede pedir un favor.

El turno

Un turno es la unidad de gobierno. Todo lo que el agente decide hacer ocurre dentro de uno, y el estado que lo regula se toma al principio y no cambia a mitad de camino.

el turno 1 permisos instantánea del turno 2 el modelo pide una herramienta 3 efecto resuelto desde el catálogo del operador efecto desconocido: se deniega, nunca se asume lo que la herramienta declara 4 aprobación suspende y espera 5 despacho traza encadenada por hash cada decisión queda anotada, cada entrada enlaza el hash de la anterior un permiso ausente no es permisivo: sin fila, una herramienta de escritura pide aprobación una lectura de permisos que falla no vacía la compuerta: rechaza todas las llamadas del turno un permiso en deny no se puede aprobar: no llega a la compuerta y no aparece en el catálogo
Figura 1. Los permisos se toman una vez por turno y el efecto de una herramienta se resuelve antes de la compuerta, no se cree del servidor que lo declara. Las tres líneas de abajo son los modos de falla: en los tres el sistema se cierra, nunca se abre.

Vale la pena detenerse en el tercer paso, porque es donde la mayoría de los sistemas confía de más.

Un servidor MCP describe sus propias herramientas, incluido si cada una lee o escribe. Creerle sin más significa que un servidor puede marcar como de solo lectura una herramienta destructiva y saltarse la compuerta de aprobación con solo declararlo. Por eso el efecto que se usa en ejecución viene del catálogo del operador y no de la autodescripción del servidor, y una herramienta cuyo efecto no se puede resolver se deniega en lugar de suponerse inocua.

El mismo principio recorre todo el camino: nada aguas abajo cree una afirmación hecha por aquello que se supone que debe gobernar.

Las credenciales de terceros nunca entran al proceso

Cuando el agente usa una integración, un CRM externo, un repositorio, un servicio de correo, no marca contra ese servicio. Sostiene un token de intermediación y pide. El intermediario hace la conexión real.

proceso del agente bucle del agente NO llega aquí credenciales del tenant tokens de integraciones la llave de la bóveda sí sostiene un token de intermediación acotado a la sesión con vencimiento pide 1 intermediario resuelve marcadores inyecta parámetros de identidad verifica la lista de la sesión 2 bóveda credenciales del tenant solo referencia en la fila 3 credencial real servicio externo la sustitución exige coincidencia de la cadena completa un marcador incrustado o concatenado se rechaza
Figura 2. El agente pide, el intermediario resuelve. La regla de sustitución es lo que cierra la exfiltración: como solo se acepta el marcador solo, un modelo convencido de filtrar un secreto no puede pedirlo dentro de una cadena más larga.

Dos detalles de esa figura hacen el trabajo pesado.

Los parámetros ligados a identidad se eliminan del esquema que el modelo ve. No es que el modelo no deba usarlos, es que no sabe que existen. El intermediario los inyecta a partir de la identidad verificada, así que apuntar a los datos de otro tenant no es una acción que el modelo pueda formular.

El efecto declarado de una herramienta no se cree del servidor que lo declara. Los efectos vienen del catálogo del operador, y un efecto desconocido se deniega en lugar de asumirse. Un servidor que se anuncia como de solo lectura no obtiene por eso el trato de solo lectura.

La escalada a shell

Ejecutar un comando es la capacidad más delicada, así que es la que más pasos tiene. En el nivel compartido el agente no recibe un shell: el comando sale a un contexto de un solo uso que se crea para esa llamada y se destruye con ella.

comando pedido tras la compuerta 1 negar por defecto sin identidad ligada, termina aquí con identidad 2 tomar el arrendamiento el supervisor vacía, bloquea y confirma sin confirmación en 45 s: se rechaza el comando 3 acuñar identidad de un solo uso un permiso, un prefijo, entregada como archivos 4 el comando corre único escritor del prefijo 5 revocar la identidad, liberar el arrendamiento en toda salida: éxito, error de herramienta o tiempo agotado el contexto nunca ve la llave del proveedor la cadena de la base el token de intermediación otros prefijos su entorno tiene dos valores, ninguno secreto
Figura 3. La identidad que recibe el contexto no es la de la sesión, y eso es deliberado: reaprovisionar una identidad rota su par de claves y dejaría sin montaje a la sesión que está esperando que el comando termine.

Dos escritores, un prefijo

El paso 2 de esa figura merece su propia explicación, porque resuelve un problema que no es evidente hasta que lo sufres.

El espacio de trabajo de una sesión tiene su verdad en el almacenamiento de objetos y se materializa localmente. Un supervisor lo mantiene sincronizado, y empuja tanto escrituras como borrados. Cuando el comando escala, ese contexto baja el espacio de trabajo, corre y sube resultados. Ahora hay dos escritores sobre un mismo prefijo, y cada subida de uno parece un borrado del otro.

sin arrendamiento supervisor borra huérfanos comando baja, corre, sube prefijo de la sesión los archivos desaparecen y reaparecen con arrendamiento supervisor vaciado y bloqueado comando único escritor un escritor a la vez el espejo cede el prefijo y lo retoma bajando primero
Figura 4. Ninguno de los dos escritores está mal por separado. El arrendamiento vence del lado del supervisor a los 900 segundos, así que un portador que muere no deja el espacio bloqueado.

Tres propiedades sostienen el arrendamiento. La pausa se confirma en vez de suponerse, porque solo el supervisor sabe cuándo terminó su vaciado. El retorno es primero de bajada, porque la vista local quedó obsoleta y retomar subiendo borraría justo lo que el comando produjo. Y el vencimiento vive del lado del supervisor, porque un arrendamiento que solo su portador puede liberar es un bloqueo esperando un desalojo.

Dónde vive cada cosa

El bucle del agente hace la llamada al modelo, lo cual tiene una consecuencia directa: la credencial del proveedor tiene que estar donde corre el bucle. Por eso el nivel por defecto lo saca del sandbox.

plano de control bucle del agente llave del proveedor almacén por sesión celda del intermediario, una por sesión canal propio, ruta de trabajo reclamada, gobernanza propia escala límite de aislamiento contexto de un solo uso un prefijo, una llamada sin token de servicio sin salida de red salvo al almacén se destruye con la llamada
Figura 5. El nivel compartido ejecuta varias sesiones en un proceso, cada una con su propio canal, su propia ruta reclamada y su propio almacén de autenticación. Existen además niveles con una máquina por sesión para trabajo interactivo largo, donde el intercambio es una primitiva de aislamiento más fuerte a cambio de que la credencial viva adentro.

Hay una última capa que no aparece en ninguna figura porque no es un camino, es una propiedad: las sesiones corren contra un rol de base de datos restringido y sin herencia, con la escritura directa al archivo de sesiones denegada. El arranque falla antes que degradar a un rol más amplio. Un agente completamente comprometido, ejecutando SQL arbitrario, sigue sin poder reescribir el registro de lo que hizo.

En resumen

MecanismoQué imponeCómo falla
Instantánea de permisosEl estado del turno no cambia a mitad de turnoUna lectura fallida rechaza todo el turno
Resolución de efectoEl efecto lo fija el operador, no el servidorUn efecto desconocido se deniega
Compuerta de aprobaciónEscrituras y ejecución esperan a una personaSin fila, pide; en deny, ni aparece
IntermediaciónLas credenciales de terceros no entran al procesoMarcador incrustado: se rechaza la llamada
Identidad de un solo usoUn permiso, un prefijo, una llamadaSe revoca en toda salida
Arrendamiento del espacioUn solo escritor sobre el prefijoSin confirmación: no corre el comando
Rol restringidoLa historia no se puede reescribirEl arranque falla antes que ampliar permisos
Traza encadenadaCada decisión enlaza el hash de la anteriorSe verifica al abrir

La línea de fondo es la que ordena todo el diseño: cada límite vale exactamente lo que vale después de que el modelo fue convencido de atacarlo. Con ese criterio, los controles que sirven no son los que le piden algo al agente, son los que están implementados como la ausencia de un camino. Un canal por sesión. Una ruta reclamada. Un ejecutor que niega por defecto. Un arrendamiento confirmado. Un rol que no puede concederse más permisos a sí mismo.

Ese es el cableado sobre el que se construye el resto de la plataforma.