Credenciales para agentes: qué protege una pasarela y qué deja abierto

El 24 de julio de 2026, OneCLI ofrecía una respuesta concreta a un problema que aparece cuando un asistente deja de redactar y empieza a actuar: ¿cómo puede llamar a GitHub, Stripe o un servicio en la nube sin recibir la clave real? El proyecto interpone una pasarela que guarda la credencial, examina la petición y la añade después de que esta haya salido del proceso del agente. La idea reduce una clase de exposición, pero no convierte al agente en confiable ni vuelve inocua cada operación. Para evaluar cualquier producto semejante conviene separar cuatro preguntas: quién custodia el secreto, quién puede pedir su uso, qué acciones permite el servicio y qué rastro queda.

La documentación primaria de la arquitectura describe un proxy HTTP escrito en Rust. El agente recibe un token propio y envía una petición normal a través de la pasarela. Antes de tocar el secreto, el sistema contrasta la identidad, el destino y la política; si la operación se permite, busca la credencial por servicio, host y ruta, la descifra e inyecta en una cabecera o parámetro de URL. La respuesta vuelve al agente, pero la clave auténtica no tiene que entrar en su prompt, su archivo de entorno ni su memoria.

Custodiar una clave no es autorizar una acción

Esta distinción evita el error más frecuente al hablar de bóvedas para agentes. Una credencial responde «¿con qué identidad se autentica la petición?». Una política responde «¿puede esta identidad realizar esta operación, en este recurso y ahora?». Un agente puede no conocer la clave de Stripe y aun así estar autorizado a crear un cargo mediante la pasarela. Si interpreta mal una instrucción, repite un bucle o acepta contenido malicioso, el secreto seguirá oculto, pero el cargo puede ejecutarse.

El propio fabricante lo reconoce en una explicación de alcance y limitaciones publicada el 16 de marzo de 2026: OneCLI busca impedir el robo de credenciales, no el abuso de un acceso legítimo. La página advierte de que una llamada autorizada a una API se cursará aunque el agente haya alucinado la operación. También enumera lo que queda fuera: tráfico que elude el proxy, un host totalmente comprometido y acciones dañinas que no requieren claves, como borrar archivos locales o usar una sesión ya autenticada.

Ese reconocimiento permite construir un modelo de amenaza verificable. Primero se define el activo: la clave, el dinero, los datos o el repositorio. Después se enumeran las rutas: copiar el secreto, usarlo a través del intermediario, saltarse el intermediario o actuar por otro canal. Por último se asigna un control a cada ruta. La bóveda reduce la copia; una regla por método y ruta limita el uso; la red obliga a pasar por el proxy; el aislamiento restringe el host; y una aprobación humana protege operaciones de consecuencias altas. Si una fila queda sin control, el producto no la cubre por arte de su nombre.

La inyección de prompt cambia el cálculo

Un agente procesa texto procedente de personas, páginas, incidencias y resultados de herramientas. Parte de ese material puede contener instrucciones hostiles. OWASP define la inyección de prompt como una entrada que altera de forma no prevista el comportamiento o la salida del modelo, y distingue la variante indirecta: la orden llega dentro de una fuente externa. Entre las consecuencias posibles incluye divulgar información sensible, usar funciones sin autorización y ejecutar órdenes en sistemas conectados.

Ocultar las claves reduce lo que el modelo puede revelar literalmente. No elimina la posibilidad de que use una capacidad válida en beneficio del atacante. Por eso OWASP recomienda mínimos privilegios, funciones gestionadas por código y aprobación humana para acciones de alto riesgo. Son controles situados fuera del razonamiento probabilístico del modelo. Una frase en el prompt puede orientar; una denegación en el proxy o en la API decide.

La comprobación práctica consiste en tratar al agente como un cliente no confiable. Hay que probar peticiones al host correcto con método prohibido, rutas que casi coinciden, parámetros inesperados, redirecciones, subdominios, destinos codificados de otra forma y salidas directas que no usan el proxy. También se prueba qué ocurre cuando la política no encuentra coincidencia. En seguridad, «sin regla» debe tener un resultado explícito; si significa permitir, cualquier hueco de configuración amplía el acceso.

Cuatro fronteras que no deben mezclarse

La primera frontera es la custodia. El repositorio público de OneCLI declara cifrado AES-256-GCM en reposo y descifrado al preparar la petición. Eso protege el contenido almacenado ante ciertos accesos a disco o base de datos, pero la clave de cifrado y la memoria del proxy pasan a ser activos críticos. El equipo debe saber dónde vive esa clave maestra, quién puede leerla, cómo se rota, qué copias existen y qué ocurre si el servicio no está disponible.

La segunda frontera es la identidad. Compartir un token entre varios agentes impide atribuir acciones y obliga a revocarlos como bloque. Cada proceso necesita una identidad propia, y cada entorno —desarrollo, pruebas y producción— debe tener credenciales y reglas distintas. NIST define el mínimo privilegio como restringir a cada usuario o proceso a los recursos y autorizaciones mínimos para su función. Aplicado aquí, no basta con conceder «GitHub»: hay que limitar repositorio, operación y, cuando la API lo permita, recurso.

La tercera frontera es la decisión. La documentación actual de OneCLI describe reglas de organización y permisos por agente, evaluados antes de inyectar la credencial, con acciones de bloqueo, límite de frecuencia y aprobación. El orden importa: una regla general permisiva colocada antes de una excepción puede absorberla si el motor aplica la primera coincidencia. El inventario de políticas debe incluir prioridad, propietario, razón y una prueba que demuestre tanto lo permitido como lo denegado.

La cuarta frontera es la ejecución. La política del proxy no sustituye los permisos nativos del proveedor. Si una clave puede administrar toda una cuenta, un error en la pasarela conserva un radio de daño enorme. Siempre que sea posible, el servicio de destino debe emitir credenciales separadas, ámbitos OAuth o roles IAM restringidos. La pasarela añade una decisión; no debe convertirse en la única decisión.

El proxy también se convierte en infraestructura sensible

OneCLI intercepta HTTPS para examinar destinos e inyectar credenciales. Eso requiere instalar confianza en un certificado de la pasarela y operar correctamente la cadena criptográfica. No es automáticamente inseguro, pero cambia la frontera: quien controle el proxy o su autoridad de certificación puede observar o alterar tráfico que antes iba directamente al servicio. Los equipos deben aislar esa infraestructura, limitar su administración, proteger registros y documentar cómo se renuevan y revocan certificados.

Obligar a usar la pasarela es otro control distinto. La página de limitaciones explica que, si el agente puede abrir conexiones fuera del proxy, OneCLI no puede interceptarlas. En contenedores o clústeres se pueden aplicar reglas de salida; en una máquina general hace falta un control de red equivalente. La prueba no es que una petición configurada atraviese el proxy, sino que una petición sin configurar no pueda alcanzar Internet por otra ruta.

La disponibilidad también cuenta. Centralizar rotación y revocación simplifica operaciones, pero concentra dependencia. Antes de colocar la pasarela delante de un proceso crítico hay que decidir si un fallo debe cerrar el acceso o permitirlo, cuánto tiempo pueden almacenarse respuestas, cómo se recupera el servicio y qué operaciones de emergencia existen. Abrir el acceso cuando la política está caída conserva continuidad a costa de desactivar el control justo cuando hay menos visibilidad.

Auditar el efecto, no solo registrar llamadas

Un registro útil debe responder quién solicitó qué, cuándo, contra qué destino, con qué regla y con qué resultado. No debería contener la credencial ni cuerpos sensibles por defecto. También necesita integridad, retención y una alerta accionable: cien denegaciones pueden señalar un bucle, un ataque o una regla rota. Ver una lista de peticiones después del incidente no equivale a detectarlo a tiempo.

La evaluación puede organizarse como una matriz de pruebas. Para cada agente se enumeran operaciones necesarias, operaciones prohibidas y operaciones que requieren aprobación. Se ejecutan casos positivos y negativos, se rota una clave, se revoca un token, se intenta eludir el proxy y se verifica el contenido del log. Después se repite con una instrucción hostil escondida en una página o incidencia. El éxito no es solo que el secreto no aparezca: tampoco debe completarse una acción que la política pretendía impedir.

Así se puede juzgar OneCLI —o cualquier bóveda para agentes— sin confundir una propiedad valiosa con seguridad total. Mantener la clave fuera del modelo reduce exposición y facilita revocación. La seguridad del sistema depende además de permisos estrechos en el proveedor, reglas deterministas, salida de red controlada, aislamiento del host, aprobaciones proporcionadas y registros protegidos. La capacidad transferible es formular cada promesa como una frontera y atacarla desde ambos lados: comprobar lo que bloquea y, sobre todo, descubrir qué sigue pudiendo hacer un agente autorizado.