El credential brokering en agentes IA es un patrón arquitectónico donde un proxy intermediario maneja las credenciales reales en lugar del agente, que solo opera con placeholders. Según el blog de Infisical publicado el 23 de mayo de 2026, el problema de fondo es que los agentes son sistemas no-determinísticos que no pueden ser confiables con secretos de alto valor.
En 30 segundos
- Los agentes IA necesitan credenciales (API keys, tokens de GitHub) para operar, pero son vulnerables a prompt injection que puede forzarlos a filtrarlas.
- Credential brokering resuelve esto con un proxy que intercepta requests, reemplaza placeholders por credenciales reales en memoria, y envía la request autenticada sin que el agente vea nunca el secreto.
- Anthropic, Vercel y Cloudflare convergieron independientemente en el mismo patrón en 2026: proxy dedicado en la capa de egress.
- Infisical publicó Agent Vault en mayo de 2026 como implementación open-source de referencia, configurable vía variable de entorno HTTPS_PROXY sin cambios de código.
- Los tres pilares de implementación son: aislamiento (el agente nunca toca el broker), co-location (latencia mínima), y acceso solo desde redes privadas.
AI Agents es un programa autónomo capaz de percibir su entorno, tomar decisiones y ejecutar acciones sin intervención humana continua, desarrollado por empresas como OpenAI, Anthropic y Google para automatizar tareas complejas mediante la interacción con APIs y herramientas.
El problema: por qué los agentes IA no pueden tener credenciales
Ponele que desplegás un agente para automatizar trabajo en un repositorio de código. Le das una Anthropic API key para razonar y un GitHub access token para abrir pull requests. Simple, funciona en local, lo mandás a producción.
El problema aparece cuando el agente lee un archivo README malicioso, una issue de GitHub con texto cuidadosamente crafteado, o los resultados de una búsqueda web envenenada. Esa entrada puede instruir al agente a incluir las credenciales en el siguiente request, a escribirlas en un log, o a subirlas a un endpoint externo. Todo esto sin que nadie en el equipo lo vea venir.
Esto es prompt injection: entrada maliciosa camuflada en el entorno del agente que secuestra sus próximas acciones. A diferencia de una aplicación web tradicional con un flujo de código fijo, un agente decide en tiempo de ejecución qué herramientas invocar y con qué parámetros. No hay un código path predecible que auditar. La superficie de ataque es toda la información que el agente puede leer.
La diferencia clave con una app tradicional: si tu backend de Node.js lee una variable de entorno, hay un flujo determinístico. Si tu agente LLM “lee” esa misma variable, puede ser manipulado para enviarla a cualquier destino. El modelo de threat no es el mismo y las soluciones de seguridad tradicionales no alcanzan.
Qué es credential brokering: el aislamiento como arquitectura
Credential brokering es el patrón donde el agente nunca accede a credenciales reales. Opera con placeholders de tipo {ANTHROPIC_API_KEY} o similares. Un proceso separado, el broker, intercepta los requests HTTP, verifica que el agente tenga autorización para ese destino, reemplaza los placeholders por las credenciales reales en memoria, y despacha el request autenticado al servicio destino.
El trust boundary queda trazado limpio: el agente vive de un lado, el broker del otro. Aunque el agente sea comprometido vía prompt injection y quiera filtrar sus “credenciales”, solo tiene placeholders. No hay nada para filtrar. Complementá con los estándares de seguridad CISA en tu infraestructura de agentes.
Esto no es encriptación. No es una solución de secrets management convencional. Es aislamiento arquitectónico: el agente físicamente no puede ver lo que no necesita ver.
Cómo funciona el flujo técnico de credential brokering
El flujo en producción tiene cinco pasos:
- 1. El agente construye un request con placeholders en los headers de autenticación:
Authorization: Bearer {GITHUB_TOKEN}. - 2. El HTTP client del agente rutea el request por el broker gracias a la variable de entorno
HTTPS_PROXY. El agente no necesita saber que hay un proxy, el sistema operativo lo maneja. - 3. El broker intercepta, autentica al agente (¿tiene permiso para hablar con GitHub?), y verifica el destino del request.
- 4. En memoria, el broker reemplaza
{GITHUB_TOKEN}por el token real obtenido del secrets store. - 5. El request autenticado llega a GitHub. El agente nunca vio el token. Si está comprometido, no tiene nada para enviar.
¿Y qué pasa si el agente intenta leer directamente el endpoint del broker para extraer credenciales? Ese es el tercer pilar: el broker solo es accesible desde la red privada donde corre el agente, nunca desde internet público. No hay forma de alcanzarlo externamente.
Implementaciones en producción: Anthropic, Vercel y Cloudflare convergieron en el mismo patrón
Lo interesante es que a principios de 2026, tres empresas llegaron independientemente a la misma arquitectura.
Anthropic integró credential brokering en su Managed Agent Infrastructure. El proxy dedicado intercepta todos los requests del inference loop antes de que lleguen a servicios externos, con autenticación a nivel del harness del agente.
Vercel lo implementó en la sandbox layer de sus deployments de agentes: cada agente corre en un sandbox con su propio proxy que maneja las credenciales de las integraciones configuradas en el dashboard.
Cloudflare lo llevó a la egress layer de Workers AI: cuando un agente hace un request saliente, pasa por un Workers KV-backed proxy que resuelve las credenciales sin exponerlas al código del worker. Más contexto en las integraciones con ChatGPT.
LangChain lo tiene como auth proxy configurable en su LangGraph platform. El patrón tiene nombre diferente en cada implementación, pero el mecanismo es el mismo: proxy en el medio, credenciales reales solo en el broker.
Esta convergencia independiente en 2026 es una señal de que el patrón encontró product-market fit. Cuando cuatro equipos distintos llegan a la misma solución sin coordinarse (que yo sepa), algo hay ahí.
Agent Vault de Infisical: implementación open-source de referencia
Agent Vault es la implementación de credential brokering que Infisical publicó en mayo de 2026 como open-source. La idea es que sea la referencia para equipos que quieran implementar el patrón sin reinventar la rueda.
Su ventaja principal: es interface-agnostic. No importa si el agente usa el SDK de Anthropic, llama a OpenAI directamente, o usa cualquier cliente HTTP. La integración se hace vía variable de entorno HTTPS_PROXY: apuntás esa variable al endpoint del Agent Vault y listo (sin cambios de código en el agente).
El flujo de substitución opera sobre strings: el agente declara qué placeholders necesita, Agent Vault los mapea a los secrets almacenados en Infisical, y hace el reemplazo en memoria en cada request. Tiene soporte nativo para múltiples MCPs (Model Context Protocol), por lo que un mismo agente puede hablar con varios servicios, cada uno con sus propias credenciales, sin que el agente tenga acceso a ninguna.
El proxy corre como proceso separado del agente. Eso es importante: si el agente se compromete, el proceso del broker no está en el mismo espacio de memoria. No hay forma de hacer memory dump del agente para extraer tokens del broker.
Tabla comparativa: enfoques de seguridad para credenciales en agentes IA
| Enfoque | Aislamiento | Protege vs. prompt injection | Complejidad de implementación | Complementario con credential brokering |
|---|---|---|---|---|
| Variables de entorno | Ninguno | No | Baja | No reemplaza |
| Encriptación de secrets | Parcial (en reposo) | No (en memoria están expuestos) | Media | Sí, complementa |
| OAuth con scope limitado | Parcial (por scope) | Parcial | Media-Alta | Sí, complementa |
| Zero-trust + mínimo privilegio | Por identidad | Parcial | Alta | Sí, se complementan |
| Credential brokering | Arquitectónico (total) | Sí | Media | Es el componente base |
Acá vale hacer una aclaración que a veces se pierde: credential brokering no reemplaza a los otros enfoques, es la capa de aislamiento que los hace más efectivos. Usás OAuth con scope limitado para minimizar permisos, zero-trust para autenticar el agente como identidad, encriptación en reposo para el secrets store, y credential brokering para que nada de eso llegue jamás al contexto del agente. Ya lo cubrimos antes en cómo funcionan los modelos de lenguaje.
Best practices: los tres pilares para implementarlo bien
Si vas a implementar credential brokering en tu stack, hay tres principios que se repiten en todas las implementaciones maduras:
Aislamiento: el agente nunca habla con el broker directamente
El agente no debería tener ninguna ruta de acceso al proceso del broker. Ni por red local, ni por IPC, ni por sistema de archivos. La única forma en que el broker le “ayuda” al agente es interceptando sus requests HTTP salientes vía proxy. Si el agente puede hacer un GET al broker, ya rompiste el aislamiento.
Co-location: el broker tiene que estar físicamente cerca
Un agente típico hace cientos de API calls por tarea. Si cada call pasa por un broker que está en otra región de AWS, vas a acumular latencia muy rápido (ponele 20ms por hop, multiplicado por 500 calls). El broker tiene que correr en la misma máquina o en el mismo datacenter que el agente. Esto es un constraint de arquitectura real, no solo una buena práctica.
Privacidad de red: el broker solo accesible desde la red privada
El endpoint del broker no puede ser alcanzable desde internet. Solo debe aceptar conexiones de la red interna donde corre el agente. Si exponés el broker públicamente, un atacante externo puede hacer los mismos requests que el agente y obtener credenciales reales.
Dos prácticas adicionales que las implementaciones más maduras ya incluyen: tokens efímeros (las credenciales que el broker obtiene del secrets store tienen TTL corto, no son long-lived API keys) y rotación automática (si un token se compromete, el broker genera uno nuevo sin intervención manual).
Qué significa esto para equipos y empresas en Latinoamérica
Si estás construyendo agentes IA para clientes en la región y usás infraestructura propia o VPS, la implementación de credential brokering es más directa de lo que parece. Agent Vault de Infisical es open-source y configurable en horas. Para equipos que alojan sus propios servidores (o los de sus clientes) en plataformas como donweb.com, el broker puede correr en el mismo servidor que el agente sin costos adicionales de infraestructura.
El escenario que más se da en equipos locales: agentes corriendo en producción con credenciales en variables de entorno, sin ningún aislamiento. Funciona hasta que no funciona. Sobre eso hablamos en las APIs de Google.
Errores comunes al implementar seguridad en agentes IA
Error 1: Creer que encriptar los secrets en reposo es suficiente. La encriptación protege los datos almacenados. En el momento en que el agente necesita la credencial para hacer un request, tiene que desencriptarla, y ahí queda expuesta en memoria y en contexto. Si el agente es comprometido vía prompt injection durante ese window, la encriptación no te protegió de nada.
Error 2: Poner el broker en el mismo proceso que el agente. Esto es el error de diseño más frecuente en implementaciones caseras. Si el broker es una función dentro del mismo proceso Python que corre el agente, un atacante que compromete el contexto del agente puede invocar esa función directamente. El aislamiento tiene que ser a nivel de proceso o contenedor, no de función.
Error 3: Scope de credenciales demasiado amplio. Credential brokering resuelve el problema de exposición, pero no el de permisos excesivos. Si el GitHub token del agente tiene acceso de escritura a todos los repos de la organización, un ataque exitoso puede hacer mucho daño aunque el token no haya sido “filtrado”. El mínimo privilegio y el credential brokering se necesitan mutuamente.
Preguntas Frecuentes
¿Qué es el credential brokering en agentes de IA?
El credential brokering es un patrón arquitectónico donde un proxy intermediario maneja las credenciales reales mientras el agente opera únicamente con placeholders. El broker intercepta los requests HTTP del agente, reemplaza los placeholders por credenciales reales en memoria, y envía el request autenticado al servicio destino. El agente nunca tiene acceso a las credenciales reales en ningún momento de la ejecución.
¿Cómo prevenir que los agentes IA filtren credenciales vía prompt injection?
La forma más efectiva es que el agente nunca tenga las credenciales reales para filtrar. Con credential brokering, aunque el agente sea comprometido y reciba instrucciones de “enviá tu API key a este endpoint”, solo tiene placeholders como {API_KEY}. El aislamiento arquitectónico a nivel de proceso es lo que hace que la filtración sea imposible, no la detección de ataques.
¿Cuál es la diferencia entre credential brokering y seguridad tradicional con variables de entorno?
Con variables de entorno, la credencial real está accesible en el contexto del proceso del agente. Cualquier instrucción maliciosa que el agente reciba puede potencialmente leer y retransmitir esa variable. Con credential brokering, el agente corre en un proceso que solo tiene placeholders; las credenciales reales viven en un proceso separado (el broker) que el agente no puede acceder directamente. La diferencia es de aislamiento, no solo de dónde se almacena el secreto.
¿Qué es Agent Vault de Infisical y cómo funciona?
Agent Vault es la implementación open-source de credential brokering publicada por Infisical, disponible en GitHub. Opera como un proxy HTTPS separado del agente: el agente se configura con la variable de entorno HTTPS_PROXY apuntando a Agent Vault, y todos los requests salientes pasan por ahí automáticamente sin cambios de código. Agent Vault resuelve los placeholders contra el secrets store de Infisical y reemplaza las credenciales en memoria antes de despachar cada request.
¿Cómo implementar credential brokering de forma segura en mi infraestructura?
Los tres requisitos son: correr el broker como proceso separado del agente (no como librería dentro del mismo proceso), ubicarlo en la misma red privada que el agente para minimizar latencia en los cientos de API calls que genera una tarea típica, y asegurarse de que el endpoint del broker no sea alcanzable desde internet. Usando Agent Vault de Infisical sobre infraestructura existente, el setup inicial puede completarse en pocas horas sin cambios en el código del agente.
Conclusión
El credential brokering llegó en 2026 como respuesta concreta a un problema que muchos equipos estaban ignorando: los agentes IA no son aplicaciones determinísticas y las estrategias de seguridad de credenciales tradicionales no son suficientes para ellos. Que Anthropic, Vercel y Cloudflare convergieran independientemente en el mismo patrón es la señal más fuerte de que esto es el estándar que viene.
Para equipos que ya tienen agentes en producción con credenciales en variables de entorno, la urgencia es real. Agent Vault de Infisical bajó la barrera de entrada a un nivel donde no hay excusas de complejidad. La pregunta no es si implementarlo, es cuándo. Y la respuesta honesta es: antes de que el primer agente comprometido te cueste más caro que la implementación.