Este brief técnico de Workstation cubre la seguridad y autenticación de la IA agéntica: asegurar agentes empresariales que llaman herramientas a través de MCP (Model Context Protocol) con OAuth 2.1, situar endpoints MCP de alto riesgo detrás de VPN / red privada, y gestionar credenciales de herramientas con HashiCorp Vault — secretos dinámicos, leases, rotación automática y revocación inmediata. Recomienda configuraciones alineadas con la industria para Claude, OpenAI y Cursor.
- Problema: Agentes con claves de herramientas estáticas de larga duración + MCP público = dispersión de credenciales y movimiento lateral.
- Auth: MCP remoto = servidor de recursos OAuth 2.1 + RFC 9728 PRM + audiencia RFC 8707; PKCE obligatorio.
- Empresa: Preferir MCP Enterprise-Managed Authorization (EMA / ID-JAG) vía IdP corporativo.
- Red: MCP interno y Vault en VPN/enlace privado; allowlists de egress por herramienta.
- Secretos: Secretos dinámicos de Vault + TTL de lease; rotar roles estáticos automáticamente; revocar al final de la sesión.
- Separación: Claves API del proveedor LLM != tokens de acceso MCP != secretos de herramientas backend.
Fuentes: MCP Authorization, Vault leases, Vault AI agent validated pattern, Claude connector auth. Verifique la documentación actual del proveedor antes del despliegue en producción.
1. Modelo de amenazas para agentes empresariales
Un agente es un principal de automatización privilegiado. Modos de fallo típicos:
- Dispersión de secretos — claves API en el JSON de MCP,
.envcommitados en git, o pegados en prompts. - Sustitución de token — token de acceso emitido para el servidor A aceptado por el servidor B (falta de vinculación de audiencia).
- Herramientas con exceso de alcance — un MCP puede escribir en BD de prod y abrir firewalls con la misma sesión.
- OBO no auditado — el agente actúa sin vincular acciones a una identidad humana.
- MCP público — herramientas internas alcanzables desde Internet sin VPN ni enlace privado.
Los controles deben cubrir identidad (quién), autorización (qué herramientas), secretos (con qué credenciales) y red (desde dónde).
2. Autenticación MCP: estándar de la industria
Para MCP remoto basado en HTTP, la especificación se alinea con OAuth 2.1:
- Servidor MCP = servidor de recursos OAuth; los clientes envían
Authorization: Bearer. - PKCE es obligatorio; el grant implícito está prohibido.
- Los servidores MUST publicar Protected Resource Metadata (RFC 9728) para que los clientes descubran el servidor de autorización.
- Usar Resource Indicators (RFC 8707) para que los tokens estén vinculados a la audiencia de ese servidor MCP.
- Authorization Server Metadata (RFC 8414) y/o descubrimiento OIDC para capacidades del AS.
- Dynamic Client Registration (RFC 7591) se recomienda cuando los clientes deben registrarse sin IDs de cliente manuales.
# Protected Resource Metadata (conceptual)
{
"resource": "https://mcp.internal.example/mcp",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["mcp:tools", "mcp:resources"]
}
STDIO / MCP local es distinto: prefiera credenciales de entorno inyectadas por Vault Agent — no fuerce OAuth de navegador en cada herramienta de escritorio. El MCP remoto/público debe implementar OAuth 2.1.
2.1 Enterprise-Managed Authorization (zero-touch)
La extensión MCP Enterprise-Managed Authorization permite al IdP corporativo (Okta, Entra ID, etc.) conceder acceso a servidores MCP aprobados en el SSO mediante un ID-JAG (Identity Assertion JWT Authorization Grant), evitando la fatiga de consentimiento por servidor. Adopte EMA para flotas Claude / IDE / agentes a escala de la organización.
3. Integración VPN y MCP privado
OAuth autentica al cliente; no sustituye el aislamiento de red.
- Hospede servidores MCP internos y Vault en CIDR privado (VPN, PrivateLink, mesh Tailscale/WireGuard o mTLS de service mesh).
- Vincule listeners MCP a interfaces privadas; bloquee el 443 público salvo que el producto esté intencionadamente expuesto a Internet.
- Aplique allowlists de egress desde el runtime del agente: solo APIs/hosts MCP aprobados.
- Separe planos: portátiles de desarrolladores en VPN corporativa para Cursor; agentes en servidor en VPC sin MCP de Internet excepto SaaS aprobado.
Patrón: VPN para alcance + OAuth para autorización + Vault para secretos.
4. HashiCorp Vault para secretos de agentes
Las claves de herramientas estáticas de larga duración son incompatibles con el radio de explosión de los agentes. Vault proporciona:
4.1 Secretos dinámicos + leases
Cada secreto dinámico devuelve un lease_id y un TTL. El consumidor debe renovar (si está permitido) o solicitar un reemplazo antes del vencimiento. Cuando termina el lease, Vault puede revocar la credencial en el proveedor. Esto obliga al check-in, mejora los registros de auditoría y reduce las ventanas de exposición.
4.2 Rotación automática
Para roles estáticos (p. ej. contraseña de base de datos con rotation_period), Vault rota según un calendario. Las plantillas de Vault Agent vuelven a obtener cerca del final de vida (umbral por defecto lease_renewal_threshold ~0,9 del TTL) y pueden reiniciar un proceso hijo cuando cambian las credenciales.
4.3 TTL recomendados para agentes
| Clase de riesgo | Ejemplo | Orientación de TTL |
|---|---|---|
| Escritura crítica | Mutación BD prod, admin IAM | 5-15 minutos; revocar al final de la herramienta |
| Lectura / staging | Réplicas de lectura, APIs de tickets | 30-60 minutos |
| Clave de proveedor LLM | Clave org OpenAI / Anthropic | Gestionada por Vault; rotar según calendario; nunca en el JSON de MCP |
4.4 Vault + atribución de usuario (validated pattern)
Validated pattern de HashiCorp: el usuario se autentica; el agente recibe un token on-behalf-of (OBO); las herramientas se autentican en Vault con JWT; Vault mapea claims a policies y emite secretos dinámicos con alcance limitado. Las pistas de auditoría vinculan la emisión del secreto al humano, no a una cuenta robot compartida.
Vault Enterprise añade Agent Registry y perfiles de OAuth resource server para que los agentes inscritos presenten JWT OAuth sin un paso de login Vault separado — con restricciones específicas del agente para delegación / OBO.
# Conceptual agent tool hook (do not ship secrets to the model)
vault_token = login_jwt(obo_token) # Vault auth
secret = vault.read("database/creds/agent-ro")
lease_id, ttl = secret["lease_id"], secret["lease_duration"]
try:
run_tool(db_url=secret["data"]) # use within TTL
finally:
vault.lease.revoke(lease_id) # or let TTL expire
5. Configuraciones recomendadas por proveedor
5.1 Claude (Anthropic)
- Prefiera OAuth para conectores MCP remotos; devuelva 401 con
WWW-Authenticateapuntando a PRM para que los clientes descubran la auth. - Nunca ponga tokens/claves API en query strings de URL del conector (registradas, en caché, prohibidas por las reglas de tokens MCP).
- Claude Code: OAuth local con almacén seguro de tokens y refresh; los plugins no deben leer tokens.
- Claude alojado: credenciales de cliente gestionadas por Anthropic para usuarios que consienten; aun así mantenga los secretos de herramientas en Vault detrás de su MCP.
- Empresa: alinee el IdP con MCP EMA para acceso a servidores zero-touch.
5.2 OpenAI (Agents / tools)
- Separe las claves API del modelo de las credenciales de herramientas; rotación y radio de explosión distintos.
- Ejecute runtimes de agentes en VPC; llame MCP privado sobre red privada.
- Pase tokens atribuidos al usuario a las herramientas; autentíquese en Vault con JWT; emita secretos dinámicos por invocación.
- Registre cada llamada de herramienta con user + agent + lease_id para cumplimiento.
5.3 Cursor
- Config del servidor MCP: referencie solo variables de entorno — nunca hardcodee secretos en
mcp.json. - Servidores STDIO: ejecute bajo Vault Agent (template o env) para que los leases roten sin que los desarrolladores copien contraseñas.
- MCP remoto: OAuth cuando el servidor lo soporte; de lo contrario VPN corporativa + bearer de corta duración desde Vault.
- Política de equipo: allowlist de servidores MCP aprobados; bloquee MCP comunitarios no confiables en bases de código de prod.
- Mantenga
.env/ archivos de secretos fuera del contexto vía reglas de ignore; reglas del proyecto: prohibir pegar secretos en el chat.
6. Matriz de controles de referencia
| Capa | Control | Anti-patrón |
|---|---|---|
| Identidad | SSO IdP + EMA / OAuth PKCE | Contraseña robot compartida |
| MCP | PRM + tokens vinculados a la audiencia | Tokens en la URL; sin expiración |
| Red | VPN / PrivateLink + ACL de egress | MCP público para herramientas de prod |
| Secretos | Lease de Vault + rotar + revocar | Claves de un año en mcp.json |
| Ops | Auditoría IdP+MCP+Vault; gates humanos | Despliegues / pagos de prod sin gate |
7. Lista de verificación de implementación
- Inventarie cada servidor MCP y clasifique público vs privado.
- Implemente OAuth 2.1 + PRM en todos los MCP remotos; habilite EMA con el IdP corporativo.
- Mueva MCP + Vault detrás de VPN/red privada; documente cómo Cursor/Claude se unen a la red.
- Sustituya claves de herramientas estáticas por secretos dinámicos de Vault; defina TTL por clase de riesgo.
- Integre Vault Agent (o renew/revoke del SDK) en los runtimes de agentes; revoque leases al final de la sesión.
- Separe las claves de proveedores LLM; almacénelas y rótelas en Vault — nunca en prompts ni en la config de MCP.
- Añada gates de aprobación humana para dinero, cambios de identidad y despliegues en producción.
- Pruebe: lease expirado falla en cerrado; token de audiencia incorrecta rechazado; ruta pública bloqueada.
Publicado por Workstation — automatización empresarial, plataformas multiagente y entrega segura en Kubernetes.