La incorporación de agentes autónomos debe empezar con una bóveda bloqueada

Los agentes autónomos deben obtener acceso por etapas. Si empiezas entregándole a un agente un token de producción y le pides que «tenga cuidado», te has saltado la única parte de la configuración que te enseña cómo funcionan los controles bajo presión.

El proceso del primer día debe empezar con una bóveda que deniegue todo, pasar por una acción HTTP de bajo riesgo, añadir después SSH y activar luego la aprobación en cada uso para las credenciales que lo merezcan. Termina verificando el registro de auditoría mientras la ejecución todavía está fresca en tu memoria. El orden importa porque cada etapa aísla un fallo diferente.

El objetivo no es conseguir que un agente sea útil lo antes posible. Es saber exactamente qué puede hacer, qué debes aprobar, qué registra y cómo detenerlo antes de conectarlo a un trabajo con consecuencias.

Empieza con una bóveda que rechace todas las acciones

Tu primera prueba exitosa debe ser una denegación. Una bóveda bloqueada debe rechazar una acción del agente aunque la solicitud sea perfectamente razonable y la credencial ya esté configurada.

Puede parecer contradictorio hasta que ves a un agente reintentar una acción fallida. Los agentes no dudan. Si una herramienta informa de que el acceso no está disponible, el agente puede probar otro endpoint, cambiar un argumento, invocar una herramienta relacionada o pedir aprobación. Quieres que el límite de seguridad responda antes de que cualquier credencial salga de su almacenamiento protegido.

En un Mac, asegúrate de que la app está ejecutándose, pero deja la bóveda bloqueada. Inicia el agente mediante su flujo normal de desarrollo y dale una solicitud deliberadamente inofensiva, como recuperar un recurso de prueba de una API que todavía no hayas autorizado.

El resultado esperado es sencillo: la solicitud no se ejecuta. No evites la denegación pegando el token en una variable de entorno, un perfil del shell, una instrucción, un archivo del proyecto o un archivo de configuración del agente. Esa solución enseña la lección equivocada porque convierte tu primera prueba en un problema convencional de gestión de secretos.

Anota lo que informó el agente. Debes comprobar tres cosas:

• El agente puede llegar a la puerta de enlace de acciones mediante su conexión MCP.
• La puerta de la bóveda detiene la acción mientras está bloqueada.
• No aparece ningún secreto en la transcripción del agente, la salida de la terminal ni los argumentos de la herramienta.

La diferencia entre una credencial no disponible y una bóveda bloqueada importa. Una credencial no disponible suele indicar un problema de configuración. Una bóveda bloqueada significa que la configuración funciona y el acceso está cerrado intencionadamente. Si tratas ambos fallos como «el token no funcionó», tarde o temprano desactivarás el control que te estaba protegiendo.

Sallyport usa esto como primer control de su escala de decisiones: mientras la bóveda está bloqueada, todas las acciones se deniegan. En los equipos Mac compatibles, la puerta de la bóveda usa Secure Enclave y Touch ID en lugar de pedirle al agente que demuestre algo sobre sí mismo.

Conecta el agente sin entregarle un secreto

Un agente necesita una vía para realizar acciones, no una copia de una credencial. Esta regla evita que una ejecución de automatización útil se convierta en una distribución de secretos sin control.

Configura el agente compatible con MCP para que use el complemento stdio incluido:

sp mcp

El complemento es un servidor MCP normal. El agente se comunica con él, solicita una acción HTTP o SSH y recibe un resultado. La credencial permanece en la bóveda cifrada dentro de la app. El agente no recibe un token en texto plano, un token sustituto ni un marcador con apariencia de secreto que pueda usar indebidamente más tarde.

Este límite es más preciso que el que suelen establecer muchos equipos. A menudo dicen «el agente tiene acceso limitado», cuando en realidad quieren decir que el agente tiene en su entorno un token con permisos limitados. Son sistemas distintos.

Con una variable de entorno, cualquier proceso que pueda leer el entorno podría copiar el secreto. Una entrada del historial del shell, un registro de depuración, un informe de fallo, un proceso hijo, una exportación de instrucciones o una transcripción pegada de la terminal puede prolongar su vida. Con una puerta de enlace de acciones, el agente puede solicitar una acción concreta, pero no puede inspeccionar el material de la credencial que la autoriza.

Antes de desbloquear nada, revisa la configuración del agente para detectar las filtraciones habituales:

• Elimina los tokens de los archivos .env, los archivos de inicio del shell, las instrucciones del agente y la documentación del proyecto.
• No añadas una credencial a los argumentos de una herramienta solo porque la herramienta admita un campo token.
• Evita dar al agente permiso para leer el mismo gestor de contraseñas, archivo de secretos o directorio de credenciales en la nube que intentas proteger.
• Mantén la primera ejecución del agente separada de cualquier sesión de terminal que tenga cargadas variables de entorno privilegiadas.

Aquí también aparece una recomendación popular, pero mala, entre los desarrolladores: «Usa primero un token temporal y refuérzalo después». Un token temporal sigue siendo un secreto en cuanto entra en el contexto de un agente. Sí, usa una credencial temporal para limitar el impacto. No la uses como permiso para abandonar el límite entre el agente y el secreto.

Haz una única solicitud HTTP sencilla antes de cualquier otra cosa

Tu primera acción permitida debe ser una solicitud HTTP con una credencial de propósito limitado. Es preferible que sea de solo lectura. Una cuenta de prueba es mejor. Lo ideal es un endpoint que devuelva un objeto conocido y no sensible.

Elige una solicitud que puedas verificar de forma independiente. Algunos ejemplos son leer los metadatos de un repositorio de prueba, recuperar un perfil de sandbox que hayas creado o llamar a un endpoint de estado asociado a una cuenta que no sea de producción. Evita los endpoints que enumeren clientes reales, código fuente, datos de facturación o una configuración amplia de la cuenta. Una lectura exitosa también puede revelar más de lo que pretendías.

Configura la credencial HTTP en la bóveda usando el método de autenticación que espera el servicio: autenticación bearer, autenticación básica o un encabezado personalizado. Ponle una etiqueta suficientemente clara para reconocerla más tarde en una tarjeta de aprobación. «Lectura de API de prueba» es mejor que «token 2». Tu yo del futuro no debería tener que abrir un gestor de contraseñas para saber si un clic es seguro.

Ahora desbloquea la bóveda e inicia un proceso nuevo del agente. La autorización por sesión está activada de forma predeterminada, así que la primera acción de ese proceso nuevo debe mostrar una tarjeta de aprobación. Lee la autoridad de firma de código que aparece allí antes de aprobar.

No reduzcas esta comprobación a «reconozco el nombre del agente». Un nombre de comando conocido puede haber sido iniciado por un envoltorio inesperado, un binario copiado o una herramienta de desarrollo distinta. La tarjeta de aprobación muestra primero la autoridad de firma de código del proceso porque importa más el proceso que solicitó el acceso que la tarea en lenguaje natural que afirma estar realizando.

Aprueba la ejecución solo si se cumplen todas estas condiciones:

1. Has iniciado tú mismo el proceso del agente.
2. La identidad de firma es la que esperabas para ese proceso.
3. La credencial solicitada tiene el alcance limitado que pretendías.
4. La solicitud es la que pediste al agente.

Después, haz que el agente realice exactamente una llamada. Compara el resultado devuelto con una solicitud manual que hagas fuera del flujo del agente. No estás demostrando que HTTP funciona. Estás comprobando que el agente puede solicitar una acción, que la puerta de enlace puede insertar la credencial almacenada y que el resultado puede regresar sin exponer la credencial.

Un registro útil del primer día es breve:

Credencial: Lectura de API de prueba
Tarea del agente: Recuperar un objeto de prueba conocido
Resultado esperado: Solo identificador y estado del objeto
Comparación manual: Mismo identificador y estado
Datos inesperados devueltos: Ninguno

Si la respuesta incluye más campos de los esperados, detente ahí. No le pidas al agente que resuma los datos adicionales y continúe. Reduce el alcance de la API, usa un objeto de prueba más pequeño o elige un endpoint más específico. La primera llamada HTTP debe generar confianza mediante la contención, no mediante un resultado impresionante.

La aprobación de sesión permite una ejecución, no es un cheque en blanco

La autorización por sesión responde a una pregunta concreta: ¿apruebas este proceso del agente durante toda esta ejecución? No responde si todas las credenciales o todas las acciones solicitadas merecen el mismo tratamiento.

Una vez que apruebas una ejecución, el agente puede realizar varias llamadas antes de salir. Eso resulta útil cuando supervisas una tarea coherente, como leer metadatos de prueba y generar un informe local. Es arriesgado cuando la instrucción es abierta, puede iniciar trabajo relacionado o tiene acceso a credenciales con consecuencias distintas.

Trata una sesión como una unidad de trabajo delimitada. Iníciala para una tarea. Observa las primeras acciones. Termínala cuando esa tarea concluya. Inicia un proceso nuevo para la siguiente tarea diferenciada y obtén otra decisión de autorización.

El registro de sesiones debe ayudarte a mantener este hábito. Registra las ejecuciones de los agentes y puedes revocar una ejecución al instante. Usa la revocación cuando el agente empiece a desviarse, cuando descubras que aprobaste el proceso equivocado o cuando la tarea cambie de forma a mitad de camino.

Este es un patrón de fallo que conviene reconocer. Pides a un agente que «compruebe la API de prueba y corrija cualquier problema evidente». Empieza con una solicitud GET inofensiva. Apruebas la sesión. Encuentra una discrepancia de configuración, ve un endpoint de escritura entre las acciones disponibles y decide que la solución evidente es actualizar el ajuste. La credencial puede permitirlo y la aprobación original aún puede cubrir la ejecución.

Nada de esto exige un agente malicioso ni una herramienta defectuosa. El problema está en el límite de la tarea. Diste a una sesión una fase de descubrimiento y otra de corrección, y luego esperaste que la aprobación original conservara el mismo significado en ambas.

Divide el trabajo. Aprueba una sesión de descubrimiento de solo lectura. Revisa sus resultados. Después, inicia una ejecución separada para un cambio propuesto, preferiblemente con otra credencial que tenga permisos de escritura más limitados. La aprobación tiene sentido cuando sigue una unidad de trabajo que puedes describir en una sola frase.

Añade SSH solo después de que el límite HTTP te resulte normal

SSH no es «HTTP, pero para servidores». Tiene un conjunto mayor de consecuencias porque una conexión exitosa puede ejecutar comandos arbitrarios, inspeccionar archivos, cambiar permisos y mover datos mediante canales que una API limitada nunca expone.

Empieza con un host desechable o una máquina de desarrollo aislada. Crea una cuenta remota sin acceso a producción, sin credenciales compartidas y sin motivo para tocar tu directorio personal o la configuración de la nube. Coloca en ese host un archivo inofensivo con una línea de texto conocida. La primera tarea SSH del agente debe recuperar esa línea y nada más.

Sallyport dirige las acciones SSH mediante su ayudante Go sin estado incluido, sp-ssh. El agente solicita la acción mediante el mismo modelo de puerta de enlace, mientras la credencial SSH almacenada permanece en la bóveda en lugar de convertirse en un archivo de clave privada que el agente pueda leer.

El primer ejercicio SSH debe ser deliberadamente limitado:

Host: host de desarrollo aislado
Cuenta remota: cuenta de prueba restringida
Tarea permitida: Leer un archivo de texto conocido
Respuesta esperada: La línea exacta colocada en ese archivo
Condición de parada: Cualquier intento de inspeccionar otras rutas o ejecutar un segundo comando

No empieces con «ejecuta diagnósticos». Esa frase es demasiado amplia. Los diagnósticos suelen incluir listados de procesos, configuración de red, inventarios de paquetes, archivos de registro, directorios personales y configuración de aplicaciones. Un agente capaz interpretará la solicitud de forma amplia porque esa interpretación suele ser la manera de completar una tarea.

Presta atención a un error operativo muy frecuente: los desarrolladores prueban SSH con una cuenta cómoda en lugar de una cuenta segura. Tiene acceso a un host conocido, quizá mediante una clave personal existente, así que la prueba es rápida. Después, la primera experiencia SSH del agente incluye repositorios, credenciales de despliegue, historial del shell, archivos de configuración y cualquier otro elemento que esa cuenta pueda leer. Has aprendido que el túnel funciona, pero no has aprendido nada útil sobre la contención.

Una cuenta de prueba restringida hace que el fallo sea visible. Si el agente solicita una ruta inesperada, puedes ver la acción intentada en el registro y denegarla o revocarla sin preguntarte si ya encontró un archivo más sensible.

La aprobación por uso corresponde a las credenciales con consecuencias

La aprobación por uso te pide confirmar cada uso de una credencial. Activa esa opción antes de probar una credencial que pueda cambiar un sistema, acceder a material sensible o llegar a un host donde un solo comando de shell pueda tener un efecto amplio.

Los desarrolladores suelen oponerse porque las solicitudes repetidas parecen poco eficientes. Tienen razón sobre el coste. Una solicitud para cada lectura de bajo riesgo te entrenará a hacer clic sin leer. Eso es fatiga de aprobación y empeora el control, porque crea una falsa sensación de seguridad.

Usa la configuración por uso cuando cada acción necesite una decisión humana nueva. Son buenas candidatas las credenciales que pueden:

• crear, modificar o eliminar recursos remotos;
• leer registros personales, de clientes, financieros o sensibles desde el punto de vista de la seguridad;
• invocar métodos administrativos de una API;
• abrir acceso SSH a una máquina de desarrollo, staging o cercana a producción que sea compartida;
• activar un despliegue, trabajo, flujo de trabajo o notificación externa.

Mantén las lecturas de prueba de bajo riesgo bajo aprobación de sesión mientras aprendes el flujo. Coloca una puerta de aprobación por uso en la siguiente credencial que añadas y que tenga consecuencias reales. Después, dale al agente una tarea que requiera dos llamadas separadas, como leer una configuración de prueba y proponer, pero no aplicar, un cambio. Comprueba que debes aprobar cada uso cuando la credencial está configurada de ese modo.

La diferencia es importante. La aprobación por sesión pregunta si un proceso concreto puede actuar durante esta ejecución. La aprobación por uso pregunta si esta credencial concreta puede utilizarse ahora. Una se refiere a la identidad del proceso y la duración de la ejecución. La otra se refiere a la consecuencia asociada a un secreto almacenado. Si las tratas como equivalentes, el equipo acabará aprobando con demasiada amplitud o recibiendo tantas solicitudes que nadie leerá la tarjeta.

Cuando aparezca la solicitud, inspecciona algo más que la etiqueta de la credencial. Comprueba la acción, el destino y si la tarea actual del agente todavía la justifica. Si no la justifica, deniega el uso y pide al agente que explique su plan en lenguaje sencillo antes de aprobar cualquier otra cosa.

El registro de actividad convierte las sorpresas en pruebas

Un registro de sesión te indica qué ejecución del agente recibió aprobación. Un registro de actividad te indica qué ocurrió dentro de esa ejecución. Necesitas ambos porque un proceso que parece limpio aún puede tomar una mala decisión, y una llamada sospechosa significa poco si no puedes relacionarla con la ejecución que la provocó.

Después de la prueba HTTP, abre el registro de actividad y lee cada llamada individual. Haz lo mismo después de la prueba SSH. Compara el registro con el ejercicio que escribiste: el endpoint o host esperado, la acción esperada y el resultado esperado. Estás aprendiendo a detectar una discrepancia cuando todavía es fácil explicarla.

Presta especial atención a las llamadas que parecen inofensivas de forma aislada, pero no encajan con la tarea. Un endpoint de metadatos puede revelar la estructura de una cuenta. Una comprobación de un host puede llevar a un comando más amplio. Un reintento puede ser inofensivo o indicar que el agente cambió los parámetros después de que fallara la primera respuesta. El contexto procede de la sesión y la secuencia, no de una sola línea vista por separado.

No uses la narración del agente como registro. Los agentes pueden resumir con precisión, omitir un detalle, entender mal una respuesta de una herramienta o redactar una explicación convincente de una acción que no habrías aprobado. El registro sirve para comprobar lo ocurrido, no para evaluar la prosa que lo acompaña.

Este es también el momento en que la revocación instantánea demuestra su valor. Si ves que el agente pasa de la tarea acordada a la exploración, revoca primero la sesión. Puedes determinar después si la llamada era inofensiva, una vez que hayas detenido las acciones adicionales. Esperar una explicación completa puede ser sensato en una reunión, pero es una mala respuesta ante un proceso activo con credenciales.

Verifica la cadena de auditoría antes de necesitarla en una discusión

Un registro de auditoría solo es útil si puedes detectar la manipulación del propio registro. Leer una lista de eventos te dice lo que la interfaz muestra en ese momento. La verificación te dice si la cadena hash del registro de auditoría cifrado sigue siendo válida.

Ejecuta esto después de los dos primeros ejercicios:

sp audit verify

Sallyport puede verificar la cadena hash sin conexión sobre el texto cifrado, así que esta comprobación no necesita acceso al secreto de la bóveda. Esta propiedad resulta práctica durante una investigación. Puedes comprobar la integridad del registro sin desbloquear primero el mismo almacén que controla las acciones del agente.

Ejecuta el comando una vez cuando todo esté tranquilo. Anota dónde guardarás el resultado para un cambio, una prueba o un incidente. Después, repítelo tras una acción denegada deliberadamente, una llamada HTTP aprobada y una llamada SSH aprobada. Estás comprobando una secuencia de eventos conocidos, lo que facilita reconocer más adelante un resultado de verificación inesperado.

No esperes a tener una pregunta seria sobre producción para descubrir quién puede ejecutar el comando, dónde están los registros o si tu equipo distingue entre un registro de sesión y una llamada individual. Ese es el fallo habitual. Los equipos instalan registros, confían en que existen y solo los abren cuando alguien pregunta «¿Quién aprobó esto?». Para entonces intentan aprender la herramienta y reconstruir el evento al mismo tiempo.

El registro de auditoría se proyecta en los registros de sesiones y actividad a partir de un único registro cifrado, encadenado mediante hashes y ciego para la escritura. Esto te ofrece dos vistas operativas sin convertirlas en la única evidencia que puedes inspeccionar.

Haz que la primera semana sea más exigente que la primera demostración

Una demostración pulida termina cuando la solicitud HTTP tiene éxito. Un proceso de incorporación útil continúa hasta que has denegado una acción, aprobado una ejecución limitada, revocado una a propósito, inspeccionado llamadas individuales, probado SSH en un host aislado, usado la aprobación por uso y verificado la cadena de auditoría.

Mantén la primera semana lo bastante pequeña como para poder explicar cada acción. Añade solo una credencial o capacidad nueva cada vez. Si una configuración nueva necesita varias excepciones, alcances amplios y una solicitud que no puedes interpretar rápidamente, todavía no está lista para un agente autónomo.

La prueba práctica es directa: cuando el agente pide actuar, ¿puedes decir quién solicita la acción, qué credencial almacenada se utilizaría, qué sistema externo recibiría la acción y dónde mirarías después? Si alguna respuesta es imprecisa, vuelve a la etapa anterior y limita la prueba.

Es más lento que copiar un token en un archivo de configuración. También es la manera de evitar descubrir a las dos de la madrugada que tu primera ejecución real del agente fue el momento en que tus controles de credenciales dejaron de ser controles.