Ve la elicitación por URL en acción →
Mira a nuestro ingeniero Will Dawson recorrer la nueva propuesta de MCP que resuelve una de las brechas de seguridad más grandes en el tool-calling de AI. En 15 minutos verás cómo los agentes pueden manejar flujos OAuth, confirmaciones de pago y API keys sin exponer datos sensibles al LLM.

Ve el recorrido técnico →

Esta es la brecha entre el diseño de MCP y la realidad productiva. El protocolo maneja bien la autenticación cliente-servidor, pero le falta por completo un mecanismo para que los servidores obtengan credenciales de terceros de forma segura. En Arcade.dev hemos trabajado para corregir esta limitación fundamental.

El problema técnico: flujo de credenciales en sistemas distribuidos

Veamos qué pasa realmente. Tu servidor MCP necesita hacer solicitudes autenticadas a APIs externas, pero MCP no tiene ningún mecanismo seguro para obtener credenciales.

Las soluciones actuales son todas antipatrones de seguridad para sistemas multiusuario en producción:

  • Tokens de cuenta de servicio con permisos excesivos
  • Credenciales hardcodeadas en configuraciones del servidor
  • Pasar tokens a través del cliente MCP (violando el principio de menor privilegio)
  • Almacenamiento de credenciales en el cliente (hola, riesgos de exfiltración de tokens)

No es solo mala experiencia de usuario: es una falla fundamental de arquitectura de seguridad. Los clientes MCP suelen ser código no confiable que corre en dispositivos de usuarios. Son “clientes públicos” de OAuth 2.0 que no pueden almacenar secretos de forma segura. Sin embargo, eso es exactamente lo que los desarrolladores se ven obligados a hacer hoy.

Nuestro camino de ingeniería: dos enfoques para autenticación segura

PR #475: Agregar interacción de usuario como capacidad del cliente

Nuestra propuesta inicial introdujo una nueva capacidad del cliente para interacciones de usuario. La idea central: usar el navegador como contexto de seguridad confiable, igual que OAuth 2.0 lo ha hecho con éxito por más de 15 años.

La implementación agregó una capacidad userInteraction :

interface UserInteractionRequest {
  method: 'userInteraction';
  params: {
    prompt: string;
    url?: string;
    timeout?: number;
  };
}

Esto permitía a los servidores redirigir usuarios a endpoints seguros para obtener credenciales, manteniendo los datos sensibles completamente fuera del contexto de ejecución del cliente. La propuesta generó una discusión extensa y revisión de seguridad con más de 50 contribuidores que analizaron vectores de ataque, protecciones CSRF y gestión de estado.

Pero MCP 2025-06-18 llegó con elicitación, una capacidad del cliente para renderizar formularios dinámicos y recopilar datos del usuario. La elicitación por formularios no funciona para credenciales ni datos sensibles, pero ¿podría extenderse para habilitar interacciones seguras con el usuario?

PR #887: Extender la elicitación con modo URL

En lugar de tener dos capacidades similares pero distintas, evolucionamos nuestro enfoque. El PR #887 extiende el framework de elicitación con un nuevo modo:

interface UrlElicitation {
  id: string;
  mode: 'url';
  url: string;
  message: string;
  metadata?: {
    oauth_provider?: string;
    required_scopes?: string[];
    state?: string;
  };
}

Esto crea una separación clara de responsabilidades:

  • Modo formulario: UI renderizada por el cliente para datos no sensibles (preferencias, parámetros)
  • Modo URL: Navegación directa del navegador para flujos sensibles (OAuth 2.0, pagos, WebAuthn, SAML)

El modelo de seguridad es explícito: la elicitación por formulario pasa datos a través del cliente, la elicitación por URL bypasea el cliente por completo. ¿Por qué importa eso?

Análisis profundo: por qué importa la elicitación por URL

Implementación correcta de OAuth 2.0

Considera implementar la integración con GitHub. Con elicitación por URL obtienes OAuth 2.0 como debe ser:

# Server initiates OAuth flow
def handle_github_tool_call(params):
    if not has_valid_token(user_id):
        state = generate_secure_state()
        code_verifier = generate_code_verifier()

        auth_url = build_oauth_url(
            client_id=GITHUB_CLIENT_ID,
            redirect_uri=CALLBACK_URL,
            state=state,
            code_challenge=hash_verifier(code_verifier),
            scope="repo:read"
        )

        raise ElicitationRequired([{
            "id": f"github-auth-{state}",
            "mode": "url",
            "url": auth_url,
            "message": "Authorize GitHub access",
            "metadata": {
                "oauth_provider": "github",
                "required_scopes": ["repo:read"]
            }
        }])

O algo distinto a OAuth: un redirect a un portal de pagos, una página de login de IDP empresarial, etc. El cliente solo abre la URL. Para el cliente eso significa cero manejo de tokens, cero gestión de estado, cero responsabilidades de seguridad.

Respetando los límites de seguridad

La elicitación por URL aplica límites de seguridad apropiados:

  1. Cliente (no confiable): Facilita la navegación, maneja la lógica de reintentos
  2. Servidor (confiable): Gestiona tokens, valida estado, aplica scopes
  3. Proveedor de auth (confiable): Maneja autenticación y consentimiento del usuario

Esto replica patrones establecidos de seguridad web. El cliente MCP nunca toca las credenciales, lo que previene clases enteras de ataques:

  • Exfiltración de tokens mediante clientes comprometidos
  • Escalada de permisos por manipulación del cliente
  • El problema del “deputy confundido”

Beneficios reales de implementación

De nuestra investigación en servidores MCP listos para producción en Arcade.dev:

// Before: Insecure token passing
const result = await mcp.callTool('search_gmail', {
  query: 'weekly report',
  token: localStorage.getItem('gmail_token'), // 🚨 Security nightmare
});

// After: Secure URL elicitation
try {
  const result = await mcp.callTool('search_gmail', {
    query: 'weekly report',
  });
} catch (e) {
  if (e.code === 'ELICITATION_REQUIRED') {
    // Client opens URL, user auths, server stores token
    window.open(e.elicitations[0].url);
    // Retry after auth completes
  }
}

Este patrón replica lo que las apps cliente ya hacen para interactuar con servicios que requieren redirects para autorización.

Autenticación con múltiples proveedores

Los agentes reales necesitan varios proveedores de auth. La elicitación por URL lo maneja con elegancia:

// Server can request multiple authorizations
throw new ElicitationRequired([
  {
    id: 'gmail-auth',
    mode: 'url',
    url: getGoogleOAuthUrl(),
    message: 'Authorize Gmail access',
  },
  {
    id: 'slack-auth',
    mode: 'url',
    url: getSlackOAuthUrl(),
    message: 'Connect Slack workspace',
  },
]);

Lo que esto hace posible

Con autorización adecuada, los servidores MCP están un paso más cerca de estar listos para producción:

  • Acceso con scope: Solicitar solo los permisos mínimos necesarios
  • Renovación de tokens: Manejar la expiración sin intervención del usuario
  • Registros de auditoría: Rastrear qué acciones se realizaron con qué autorizaciones
  • Revocación: Los usuarios pueden revocar el acceso cuando quieran desde el proveedor

Las bases técnicas importan. Esta es la diferencia entre un demo y una infraestructura en producción.

Cronograma de implementación

El PR #887 está bajo revisión activa. Para los early adopters:

  1. Hoy: Las herramientas de Arcade.dev ya implementan estos patrones
  2. Corto plazo: La elicitación por URL estandariza el enfoque
  3. Futuro: El ecosistema MCP adopta estos patrones tanto en clientes como en servidores

¿Quieres acelerar esto?

  • Revisa el PR #887 y pon a prueba el modelo de seguridad
  • Implementa elicitación por URL en tu servidor MCP

Sin una forma de interactuar con el usuario de manera segura, MCP queda limitado a servidores que solo se conectan a APIs propias. Al agregar un mecanismo que respeta los límites de seguridad del cliente (inspirado en los patrones probados de OAuth), son posibles servidores MCP más poderosos e interesantes, habilitando por fin casos de uso de nivel productivo como agentes de AI seguros para flujos de on-call en SRE. Nos emociona el futuro de MCP, ¿y a ti?

El equipo de Arcade.dev lleva años reforzando la autenticación en Okta, Stormpath y Redis. Aplicamos esas lecciones para hacer que la infraestructura de AI esté lista para producción. Ve estos principios en acción en nuestro blueprint para una alternativa segura a OpenClaw usando Arcade y Claude Code.

*¿Quieres construir agentes de AI que funcionen de verdad en producción? Mientras esperamos que la autorización llegue a MCP, Arcade ya implementa auth segura para más de 100 integraciones. Sin bot tokens, sin pesadillas de seguridad: solo flujos OAuth reales que funcionan.*

Empieza a construir con Arcade → Regístrate.