Autenticación

El Conector MCP acepta dos tipos de credencial en el header Authorization: Bearer …. En ambos casos el tenant se deriva de la credencial, nunca de los argumentos de una herramienta: un cliente no puede pedir datos de otro negocio.

OAuth 2.1 (Claude.ai web)

Overtaker actúa como Authorization Server OAuth 2.1. El flujo es estándar y lo maneja el cliente de forma automática:

Claude.ai            Overtaker /mcp
   │                       │
   ├─ discovery ──────────▶│  .well-known/oauth-authorization-server
   ├─ register (DCR) ─────▶│  registra el cliente dinámicamente
   ├─ authorize ─────────▶│  → pantalla de consent (login Overtaker)
   │                       │     · elegís acceso: lectura | completo
   │◀─ code (PKCE) ────────┤     · aprobás con tu cuenta
   ├─ token ──────────────▶│  → access_token + refresh_token
   └─ Bearer <token> ─────▶│  cada request MCP

Propiedades de seguridad:

• PKCE S256 obligatorio — el code no sirve sin el verificador del cliente.
• Identidad = tu cuenta de Overtaker. Se reusa el login del panel; no se crea una credencial paralela. El consent no bypassea 2FA.
• Códigos de un solo uso, con expiración de 5 minutos; las solicitudes de conexión (txn) caducan a los 10 minutos.
• Tokens acotados al tenant y firmados con una clave dedicada del MCP (no comparten firma con la sesión del panel).
• Revocables — el refresh_token rota en cada uso y se puede revocar.

No hay nada que configurar de tu lado: seguí Conectar → Claude.ai.

API key MCP (Desktop / programático)

Una clave sk_live_* con kind=mcp, que pasás como Bearer token:

Authorization: Bearer sk_live_xxxxxxxxxxxxxxxx

• Se genera desde el panel del tenant (rol OWNER/MANAGER) y se muestra una sola vez.
• Cupo: hasta 3 keys mcp activas por tenant, independientes de las del Canal API.
• Cada key lleva su nivel de acceso fijado al crearla (read o full).

Niveles de acceso

Nivel	Puede	No puede
read (Solo lectura)	Consultar todo: resumen, leads, conversaciones, KB, config del bot, memoria, surveys.	Ninguna escritura.
full (Completo)	Todo lo de lectura + crear/editar/borrar: Prompt Builder, conocimiento, reglas, CRM, seguimientos.	—

Con OAuth elegís el nivel en la pantalla de consent; con API key queda fijado al generarla. Toda herramienta de escritura exige access=full — si no, devuelve un error de permiso.

Confirmación de escrituras

Además del nivel de acceso, toda operación que modifica o es destructiva usa un gate de confirmación en dos pasos:

1. Llamás la herramienta sin confirmar → devuelve un preview de lo que va a pasar (no aplica nada).
2. Repetís con confirmar=true → recién ahí se aplica.

Esto vale para publicar el Prompt Builder, borrar conocimiento, cambiar la etapa de un lead, programar seguimientos, etc. Es una red de seguridad contra cambios accidentales pedidos en lenguaje natural.

Publicar es destructivo

publicar_config_bot reconstruye el system prompt completo desde el wizard y puede pisar contenido cargado por otras vías. Editá siempre el borrador (actualizar_config_bot) y revisá antes de publicar. Ver el playbook de configuración.

Aislamiento entre tenants

El middleware de auth resuelve el tenant desde la credencial y fija el search_path de la base a su schema. Las herramientas no aceptan un tenant_id como argumento. Un intento de acceso cruzado se registra como alerta de seguridad y se bloquea.