Una IA que tiene que leer las redes sociales de un cliente (para medir, recomendar o avisar) necesita que ese cliente le autorice su cuenta. El atajo más rápido es prestarle, sin pensarlo mucho, la clave con la que tu plataforma habla con esa red social en nombre de TODOS tus clientes a la vez. Funciona a la primera. Y es exactamente el error que no se puede permitir cometer ni una vez, porque convierte un problema de seguridad de un solo cliente en un problema de seguridad de todos.
Nos lo encontramos de frente hace poco: un cliente quería que su propia plataforma de datos leyera las estadísticas de su cuenta de TikTok. Esto es cómo lo resolvimos sin que esa clave saliera nunca de nuestro servidor, y la regla que nos llevamos para cualquier integración parecida.
El problema de fondo: una clave, muchos clientes
Cuando una empresa construye una plataforma que habla con una red social (TikTok, Meta, LinkedIn) en nombre de varios clientes, suele haber una única credencial de aplicación registrada ante esa red: es la que identifica a la plataforma entera frente a TikTok, Meta o quien sea. Esa clave es necesaria y no tiene nada de malo mientras se quede donde tiene que quedarse: en el servidor de quien la gestiona.
El problema aparece en el momento de conectar la cuenta de UN cliente concreto. Si para que su plataforma lea sus propios datos hay que entregarle (aunque sea indirectamente, metida en una variable de entorno o en un fichero de configuración) esa misma clave maestra, acabas de crear este riesgo:
- Un fallo de seguridad en el servidor de ESE cliente (uno solo, el más débil de todos) compromete la clave que habla en nombre de TODOS los demás.
- No hay forma de revocar el acceso de un cliente sin invalidar también el de los demás, porque todos comparten la misma credencial.
- No puedes auditar qué cliente hizo qué llamada a la API, porque todas las llamadas se identifican igual.
Es el mismo patrón, a otra escala, que ya contamos cuando hablamos de qué pasa si un agente de IA depende del permiso de la cuenta personal de alguien: una sola pieza compartida, sin que nadie se dé cuenta, sostiene cosas que debería sostener cada una por separado.
La solución: separar "quién tiene la llave" de "quién usa el dato"
La regla de decisión que aplicamos es sencilla de enunciar y la que de verdad cuesta mantener en el día a día: la clave maestra que habla con la red social no vive nunca en el servidor de ningún cliente. Lo que sí vive ahí es un token de corta duración, propio de ese cliente y de nadie más, que su servidor pide con un secreto que solo vale para él.
En la práctica montamos un intermediario con tres piezas:
1. Un enlace de invitación que caduca
El cliente no se conecta tecleando nada a mano: recibe un enlace de invitación firmado, que caduca a las 72 horas. Al abrirlo desde su propio navegador, es él quien autoriza su cuenta de TikTok, con su propia sesión, nunca con la nuestra. Nosotros no vemos ni tocamos su contraseña en ningún momento.
2. Un token de corta duración, renovado solo
Una vez autorizada la cuenta, el servidor del cliente no recibe la clave maestra: recibe un token que dura 24 horas, y que se renueva en automático solo cuando le quedan menos de 2 horas de vida. Si ese token se filtrase, la ventana de uso indebido es de horas, no de para siempre, y afecta solo a ese cliente, nunca a los demás.
3. Un secreto que solo abre la puerta de uno
Cuando el servidor del cliente pide ese token, lo pide con un secreto que se emitió únicamente para él. Con ese secreto puede renovar su propio acceso cuando toca, pero no puede usarlo para pedir el token de ningún otro cliente. Revocar a un cliente es borrar su secreto, sin tocar nada de los demás.
Lo que no te puedes ahorrar: enseñar el dato de verdad
Hay una tentación adicional en este tipo de conexiones: dejar la pantalla de confirmación en un simple "conectado" en verde, y asumir que con eso basta. No basta, por dos motivos.
El primero es de confianza: si vas a pedirle a un cliente que autorice el acceso a su cuenta, la revisión de seguridad de esa red social (y el propio cliente) tienen que poder ver, en pantalla, exactamente qué se está leyendo con cada uno de los permisos pedidos. Un "conectado" vacío no demuestra nada.
El segundo es práctico: nosotros pedimos 4 permisos para esta integración, y la pantalla de confirmación enseña de verdad el perfil autorizado, sus contadores, y los últimos 20 vídeos leídos con sus métricas, cubriendo exactamente esos 4 permisos. Si algún día pedimos un permiso de más que no se refleja en ninguna pantalla, es la señal más clara de que algo en el diseño se ha ido de madre.
Checklist: antes de conectar la IA de un cliente a su cuenta de redes
Si tu negocio está montando algo parecido (una plataforma que lee o publica en redes sociales en nombre de varios clientes), estas son las preguntas que nos hacemos antes de dar por buena una integración:
- ¿La clave que habla con la red social en nombre de todos vive en un único sitio, y nunca en el servidor de un cliente?
- ¿Lo que recibe el servidor del cliente es un token de corta duración, y no la clave maestra?
- ¿Ese token se renueva solo, antes de caducar, sin intervención manual?
- ¿Revocar el acceso de UN cliente deja intactos a todos los demás?
- ¿El enlace de invitación o autorización tiene fecha de caducidad?
- ¿La pantalla de confirmación enseña el dato real leído (perfil, contadores, contenido), no solo un aviso genérico de éxito?
Una regla que vale más allá de TikTok
Esta regla no es específica de TikTok, ni de redes sociales: vale para cualquier plataforma de datos con IA que necesite conectarse a una cuenta de un cliente dentro de un sistema compartido por varios clientes a la vez (un ERP multi-cliente, una pasarela de pagos, un hub de mensajería). La pregunta que hay que hacerse siempre es la misma: si esta clave se filtrase hoy, ¿a cuántos clientes afectaría? Si la respuesta es "a más de uno", el diseño está mal, por mucho que funcione.
Es exactamente el tipo de decisión que tomamos en AutoBoost cuando construimos la plataforma de datos con IA de un grupo de farmacias: antes de que la IA pudiera razonar sobre el dato de cada oficina, hubo que decidir primero quién tiene la llave y quién usa el dato cada día. Lo contamos con más detalle en el caso de plataforma de datos + IA.
Si tu negocio está a punto de conectar una IA a las cuentas de redes sociales (o a cualquier sistema compartido) de tus propios clientes, revisa primero quién tiene la clave que abre la puerta de todos. En nuestros servicios explicamos cómo lo planteamos de base, antes de escribir la primera línea de integración. Y si quieres que revisemos cómo está montada la tuya hoy, contacta con nosotros.
