Controles estrictos · Agentes · Borrador

Un agente de host diminuto: sin modelo, sin puerto de entrada

Estado: este es un diseño escrito, un borrador; aún no construido y no en uso. Se prevé un despliegue gradual: primero solo hechos y solo lectura, y los comandos al final.

La mayor parte de lo que se dice sobre los agentes de IA trata de lo que pueden hacer. Este artículo trata de una pieza diseñada deliberadamente para hacer muy poco: un agente pequeño que viviría en un host. No contendría ningún modelo. Informaría de hechos sobre el host, ejecutaría solo comandos de una lista fija, recibiría sus instrucciones como mensajes firmados mediante git y no escucharía en ningún puerto de entrada.

Es el ejemplo más pequeño de la idea que recorre esta serie: cuando no se puede hacer confiable a un componente pidiéndoselo con amabilidad, se hace lo bastante pequeño como para que haya poco en lo que confiar.

Para qué sirve

Algunos hosts no están controlados por ningún asistente de IA. Aun así, necesitan conocerse y, de maneras acotadas, gestionarse: qué se ejecuta en ellos, en qué estado están y un puñado de acciones rutinarias. El agente de host diminuto está diseñado para situarse en un host así y hacer exactamente eso y nada más.

Haría tres cosas. Informaría de los hechos del host. Recibiría instrucciones como mensajes firmados. Ejecutaría un comando solo si está en su lista de permitidos.

A la izquierda, un robot agente de host; en el centro, un servicio git; a la derecha, un robot firmante. El firmante hace push de mensajes firmados al servicio git, el host los descarga y le informa de los hechos. Una franja dice que el host siempre sale a buscar y nada entra hasta él: sin puerto de entrada. — Figura 1: el host descarga, el firmante envía, el host nunca escucha

Por qué cada decisión de diseño

Cada decisión está ahí por lo que quita de la superficie de ataque.

Sin modelo. Con un modelo se puede discutir: el texto que lee puede orientar lo que hace. A un programa pequeño y fijo no se le puede convencer de una acción, y es lo bastante pequeño como para que una persona lo lea y lo revise de una sentada. Quitar el modelo elimina del host toda una clase de manipulación.

Una lista de permitidos. El agente rechazaría cualquier comando que no esté en su lista. Un error, un mensaje defectuoso o una solicitud falsificada solo podrían alcanzar lo que la lista permite. Desconocido significa rechazado.

Mensajes firmados. El host actuaría solo según instrucciones cuya firma pueda verificar. Poder llegar al canal no basta; solo quien posee la clave de firma puede dar instrucciones al host.

Git como canal. El host pediría a git los mensajes nuevos, en lugar de esperar a que lo llamen. Cada instrucción se convierte en un commit, de modo que el historial es un registro de lo que se pidió y de quién lo pidió, y el transporte no necesita nada especial.

Sin puerto de entrada. Como el host siempre saldría a buscar y nada entraría hasta él, no hay ningún servicio a la escucha que escanear, sondear o explotar desde la red.

Cinco filas. Cada decisión de diseño a la izquierda (sin modelo, lista de permitidos, mensajes firmados, git como canal y sin puerto de entrada) apunta a lo que elimina de la superficie de ataque a la derecha. Una franja dice que cada decisión quita algo y que la siguiente imagen muestra lo que queda. — Figura 3: lo que elimina cada decisión de diseño

Un mensaje, cinco pasos fijos

Cada mensaje pasaría por los mismos pasos en el mismo orden: descargarlo, verificar la firma, comprobar el comando contra la lista de permitidos, ejecutar el único comando listado, informar del resultado y de los hechos del host. Si falla cualquier paso, el mensaje se detiene ahí. Sin firma, desconocido o fuera de la lista significa que no se ejecuta nada, y no hay en medio ningún criterio en el que nadie pueda apoyarse.

Cinco cajas en fila, cada una con un pequeño robot: descargar un mensaje nuevo, verificar su firma, comprobar el comando contra la lista de permitidos, ejecutar un comando listado, informar del resultado y de los hechos del host. Una franja dice que cualquier paso que falle detiene el mensaje, de modo que sin firma, desconocido o fuera de la lista significa que no se ejecuta nada. — Figura 2: un mensaje, cinco pasos fijos

Lo que costaría

Lo pequeño y estricto tiene un precio.

Flexibilidad. Un nuevo tipo de tarea significa una nueva entrada en la lista de permitidos, que hay que escribir y revisar. Ese es el objetivo, y también una fricción.
Gestión de claves. La firma necesita claves: alguien tiene que crearlas, custodiarlas, decidir quién puede firmar y sustituirlas cuando haga falta. El diseño exige que ese trabajo se haga bien; cómo se custodia la clave de firma es un punto de diseño abierto, y este artículo no describe ninguna configuración.
Velocidad. Un host que consulta periódicamente se entera de una instrucción en la siguiente consulta, no al instante.
Dependencia de git. El canal depende de que el servicio git sea accesible y se comporte bien.
Diagnóstico. Un programa fijo con una salida acotada dice poco cuando algo falla, así que los informes y el registro requieren cuidado.

Contra qué no protege este diseño

Nombrar los límites importa más que enumerar las fortalezas.

La clave de firma. Quien posee la clave de firma puede enviar mensajes válidos. La lista de permitidos limita lo que pueden pedir, pero una acción dañina que esté en la lista se llevaría a cabo. Cómo se custodia la clave, y cómo se sustituiría, es un punto de diseño abierto.

Repetición. Un mensaje firmado genuino puede enviarse de nuevo más tarde. El diseño exige una forma de distinguir los mensajes recientes de los antiguos, como una caducidad o un contador; sin ella, la repetición es posible.

Un servicio git comprometido. El servicio no puede falsificar firmas, pero sí retener mensajes, retrasarlos o mostrar otros antiguos. Eso afecta a la disponibilidad y a la actualidad, no a la autenticidad.

Una mala lista de permitidos. La lista de permitidos es el verdadero límite de permisos. Solo es tan segura como sus entradas y los argumentos que aceptan; una entrada amplia es un permiso amplio.

Un host comprometido. Un host del que se ha tomado el control puede informar de hechos falsos sobre sí mismo. El daño se limita a las rutas propias de ese host: con este diseño no alcanzaría a otros hosts.

Cinco tarjetas, cada una con un pequeño robot: la clave de firma como punto de diseño abierto, la repetición de un mensaje firmado antiguo, un servicio git comprometido, una mala lista de permitidos y un host comprometido que puede informar de hechos falsos limitados a sus propias rutas. Una franja dice que las listas de permitidos pequeñas, los mensajes recientes, el cuidado con las claves y la supervisión reducen el daño, pero estos riesgos permanecen. — Figura 4: contra qué no protege este diseño

Estos riesgos se reducirían con listas de permitidos pequeñas y de argumentos fijos, mensajes recientes, un manejo cuidadoso de las claves y la supervisión de lo que informa el host. No se eliminan.

Cómo encaja con el resto de la serie

El agente de host sería la capa más baja del mismo cuadro. Los agentes por encima proponen, las personas aprueban, y mensajes firmados y registrados llevan hacia abajo la instrucción aprobada. En el fondo habría una pieza que sigue su lista y deja un registro, y que tiene poco más que atacar.