Dar acceso a Proxmox a un asistente de IA: dónde tiene que estar el límite

Aquí hay una asimetría real y algo molesta. Leer dos mil líneas de registro y encontrar la línea donde algo se rompió es exactamente lo que un modelo de lenguaje hace bien. Y es también exactamente el trabajo que la mayoría no puede dejarle hacer, por la forma en que se concede el acceso.

La pregunta no es si un modelo debe tocar un servidor. Es dónde está el límite, y hoy suele estar en el sitio equivocado.

Por qué el montaje habitual incomoda

Hay dos formas comunes de conectar un asistente a Proxmox: darle una sesión SSH o un token de API con todos los privilegios. Ambas acaban en lo mismo. Desde ese momento nada se interpone entre el modelo y el hardware, y todas las protecciones viven en cómo esté redactada una instrucción.

Una instrucción no es un límite. Es una petición a un sistema diseñado para ser servicial, en un idioma que no tiene fuerza ejecutoria.

El riesgo es el contexto que falta, no la mala intención

Esta es la parte que se diagnostica mal. El modo de fallo rara vez es un modelo que decide hacer daño. Es un modelo que actúa correctamente sobre una imagen incompleta.

Un disco que parece vacío. El modelo lee un dispositivo sin sistema de archivos montado y lo da por libre. El dispositivo pertenece a una máquina que simplemente está apagada.

Un grupo degradado. El modelo lee el estado degradado y propone reconstruir el conjunto. El paso correcto era sustituir un disco, y reconstruir es la forma en que se pierden los datos restantes.

Un servicio "que no está corriendo". No está corriendo porque corre por horario y ya terminó. Reiniciarlo es inofensivo; desactivarlo porque "se para todo el rato" no lo es.

En los tres el comando está bien escrito. Lo falso es la premisa, y un comando correcto sobre una premisa falsa es indistinguible de un sabotaje una vez hecho el daño.

Solo lectura ayuda, y no es toda la respuesta

La respuesta obvia es conceder acceso de solo lectura, y de verdad elimina los peores desenlaces. Quedan dos cosas.

Leer no sale gratis. La configuración, los registros y las trazas de auditoría contienen nombres de host, direcciones, nombres de usuario y a veces tokens pegados donde no debían. Un asistente de solo lectura con alcance de lectura completo es una exportación de su infraestructura.

El diagnóstico sin acción se queda a medias. Si la respuesta útil es "reinicia este servicio concreto", un montaje de solo lectura devuelve el hallazgo a una persona para que lo reescriba. Está bien, y es también por lo que los permisos se ensanchan en silencio más adelante.

Así que solo lectura es un buen comienzo y un mal destino. El destino es acceso de escritura estrecho, pasando por las mismas puertas que pasa una persona.

Dónde pertenece realmente el límite

Ni a la instrucción ni al modelo. A la capa que ejecuta, porque es el único sitio capaz de negarse.

Tres propiedades hacen fiable a esa capa, y las tres son comprobables en lugar de prometidas.

Los permisos vienen del sistema que ya los tiene. Si el asistente se conecta con una cuenta existente, lo que esa cuenta puede tocar es exactamente lo que el asistente puede tocar. No se inventa un segundo modelo de permisos, así que no hay nada que mantener sincronizado ni forma de que los dos se contradigan.

Las operaciones destructivas pasan la misma puerta que una persona. Si borrar un disco pide confirmación a un humano, debe pedirla también cuando lo solicita un modelo. Un camino seguro para las personas y abierto para la automatización no es un límite, es un atajo con buen nombre.

Cada paso aterriza en el registro de auditoría. Quién, qué, cuándo, sobre qué y con qué resultado. Sin eso, la pregunta real tras un incidente, "¿esto lo hizo el asistente?", no tiene respuesta, y la ausencia de respuesta es por sí sola un motivo para no dar acceso.

La pregunta que hacerle a cualquier herramienta así

No "¿es seguro?" sino "¿qué es lo que se niega, y dónde vive?"

Si la respuesta es "al modelo se le dijo que no lo hiciera", no hay límite. Si la respuesta es "la capa que ejecuta comprueba los permisos de la cuenta y hace pasar los pasos destructivos por una puerta", lo hay, y puede probarlo: conéctese con una cuenta restringida y compruebe que la negativa es real.

Qué hace Atlas

⚠️ Esta capa está planificada, no entregada. Lo que sigue es el diseño hacia el que se construye, escrito aquí porque la pregunta anterior merece una respuesta honesta y no publicitaria.

La intención es que el asistente se conecte a Atlas y no a Proxmox. Proxmox queda debajo y el modelo nunca lo alcanza directamente; solo puede usar lo que Atlas sabe hacer, con lo que cada puerta existente permanece en el camino.

El límite lo dibujan los permisos de Proxmox, es decir la primera propiedad de arriba: lo que la cuenta conectada puede tocar es todo lo que el asistente toca, y no aparece ningún concepto nuevo de permisos. Las operaciones destructivas conservan la confirmación que ya tienen, y el registro de auditoría ya anota quién, qué, cuándo, sobre qué y con qué resultado para cada acción privilegiada, incluidas las rechazadas.

También está pensado como componente separado en vez de parte de la instalación: en una máquina que no lo quiere nunca está presente. Eso importa por el mismo motivo que el resto de este artículo. El límite más seguro para una capacidad que no ha elegido es su ausencia.