No configures Telegram, Discord, Slack y WhatsApp en una sola sesión. El primer canal no debe ser el que parezca más popular, sino el que tenga una identidad, un administrador y una forma de recuperación que puedas mantener. Aprueba a un único remitente por DM y no amplíes el acceso hasta que su mensaje reciba una respuesta visible en esa misma conversación.
| Necesidad inicial | Canal de partida | Límite seguro para la primera prueba |
|---|---|---|
| Un bot privado para una persona | Telegram | Emparejar un solo DM y dejar los grupos fuera |
| Una identidad basada en número de teléfono | Vincular una sesión QR y aprobar un remitente; grupos cerrados | |
| Un servidor privado administrable | Discord | Permitir un servidor, un canal y un usuario; exigir mención |
| Una aplicación dentro del espacio de trabajo | Slack | Elegir Socket o HTTP y probar un DM o un canal estable |
Según la configuración oficial de canales de OpenClaw comprobada el 13 de julio de 2026, Telegram e iMessage se distribuyen en el paquete principal, mientras Discord, Slack, WhatsApp y otros canales oficiales se instalan como plugins separados. No es una clasificación de calidad. La fuente del plugin, los nombres de permisos, los comandos y las políticas predeterminadas pueden cambiar; contrasta siempre la documentación vigente con la salida de tu CLI.
La primera ruta debe permanecer cerrada. Conserva el emparejamiento para los DM, una lista de permitidos para grupos o canales y la exigencia de mención en destinos compartidos. Cambiar dmPolicy a open y añadir allowFrom: ["*"] solo para hacer pasar una prueba convierte el bot en una entrada pública; no es una reparación de la conexión.
Guardar un token, ver el bot como online o escanear un QR no completa la integración. El canal está listo cuando OpenClaw resuelve la cuenta esperada, recibe el mensaje del remitente autorizado, termina el turno del agente o modelo, intenta el envío saliente y muestra la respuesta en el DM, grupo, canal o hilo original.
Condición de parada: no añadas permisos opcionales, grupos, más usuarios, acceso público, otra cuenta ni un segundo canal hasta demostrar ese recorrido completo una vez.
Comprueba Gateway y el modelo antes de tocar un canal
Si el runtime de OpenClaw aún no está probado, cualquier diagnóstico del canal mezclará propietarios distintos. Un token de Telegram no corrige la autenticación de un proveedor de modelos y un scope de Slack no vuelve accesible un Gateway detenido. Primero demuestra que la misma instalación, servicio y configuración que alojarán el canal pueden completar un turno normal desde una superficie local o web ya funcional.
Empieza con observaciones que no modifiquen el estado:
hljs bashopenclaw status openclaw gateway probe openclaw doctor openclaw channels list --all openclaw channels status --probe
No son cinco variantes del mismo diagnóstico:
openclaw statusidentifica la instalación activa y resume el estado del runtime.openclaw gateway probecomprueba si la CLI llega al Gateway que esperas.openclaw doctor, sin--fix, informa de problemas de configuración o migración sin convertir una escritura automática en la receta de instalación.openclaw channels list --allsepara canales instalados, configurados, habilitados e instalables.openclaw channels status --probeconsulta la cuenta y el transporte en vivo cuando el Gateway responde. Si el Gateway no está disponible y el comando solo resume la configuración, todavía no has demostrado una conexión con la plataforma.
La base pasa cuando el binario y la versión corresponden al servicio que se está ejecutando, el Gateway responde al probe, un turno con modelo funciona fuera del canal nuevo y el canal elegido aparece como core, instalado o instalable. Si falla la CLI, el servicio, el Gateway o la ruta del modelo, detén la configuración del canal. Corregir primero ese nivel mantiene clara la causa de cualquier fallo posterior.
Elige el primer canal por la identidad que puedes administrar
Preguntar cuál es “el mejor canal” oculta la decisión real. Cada opción asigna una identidad de plataforma, una credencial o sesión, un transporte, un administrador y una recuperación diferentes. Elige la que puedas mantener cuando caduque un token, se desconecte una sesión o cambie un permiso.
| Opción | Buen primer caso | Responsabilidad que aceptas | No la elijas primero si |
|---|---|---|---|
| Telegram | Bot dedicado para una persona o un grupo pequeño | BotFather, token, IDs de usuario y grupo, privacidad y menciones | En realidad necesitas roles de servidor, una app de workspace o identidad telefónica |
| El número de teléfono es la entrada del usuario | Dispositivo vinculado, sesión QR, número, allowlist y host de la sesión | No puedes proteger ni mantener la sesión vinculada | |
| Discord | Servidor privado o comunidad con permisos explícitos | Application, bot, intents, invitación, IDs de guild y channel | No administras el servidor ni puedes revisar los permisos efectivos |
| Slack | Workspace donde puedes instalar una app | App, despliegue Socket/HTTP, tokens o signing secret, scopes y eventos | No puedes instalar la app o proporcionar la forma de red necesaria |
También debes saber si el canal está incluido o se instala. Para un canal disponible en el catálogo actual, la CLI puede resolver la fuente vigente con una orden basada en flags:
hljs bashopenclaw channels add --channel <name>
Consulta openclaw channels add --help y channels list --all antes de copiar el nombre de un paquete antiguo. Configura una sola cuenta además de una sola plataforma. Dos bots de Telegram, dos workspaces de Slack o un WhatsApp personal y otro profesional introducen la misma ambigüedad que cuatro plataformas simultáneas: ya no sabes qué identidad, secreto y ruta produjeron la respuesta.
Define cinco datos antes de empezar la conexión
Una credencial cubre solo una parte. Anota una línea para cada uno de estos cinco datos antes de añadir el segundo servicio:
| Dato | Pregunta previa | Evidencia que puedes conservar sin secretos |
|---|---|---|
| Identidad visible | ¿Qué bot, app, workspace, servidor o número verá el usuario? ¿Quién lo administra? | Etiqueta de cuenta e IDs estables |
| Transporte | ¿Está en core o es plugin? ¿Usa polling, Discord Gateway, Socket, HTTP o sesión QR? | Canal instalado y modo elegido |
| Secreto o sesión | ¿Dónde se resuelve el token, app token, signing secret o estado del dispositivo? | Referencia a entorno, archivo o SecretRef, nunca el valor |
| Acceso | ¿Qué remitente, DM, grupo, canal, guild, mención y comando están autorizados? | Aprobación de pairing y listas por ID |
| Prueba | ¿Qué mensaje demostrará entrada, modelo, salida y respuesta visible? | Hora, probe, fragmento de log y respuesta |
Este ejercicio descubre responsabilidades incompletas. “Usaremos Slack” no define el transporte hasta elegir Socket Mode o HTTP Request URLs. “Conectaremos WhatsApp” no define la identidad hasta decidir qué número y host poseen la sesión. “El bot de Discord está online” no prueba que un usuario autorizado pueda escribir en el destino previsto y recibir allí la respuesta.
Mantén tokens y sesiones fuera de la conversación de trabajo
Los ejemplos publicables deben enseñar referencias, no valores con forma de secreto. Resuelve las credenciales desde un entorno protegido, un archivo o el mecanismo SecretRef vigente en el host del Gateway. Por ejemplo, Discord admite una referencia a variable de entorno:
hljs json5{ channels: { discord: { enabled: true, token: { source: "env", provider: "default", id: "DISCORD_BOT_TOKEN" } } } }
El valor de DISCORD_BOT_TOKEN pertenece al entorno del servicio. No debe aparecer en ese archivo, en una conversación, captura de terminal, issue, paquete de soporte ni repositorio Git. Aplica la misma regla al token de Telegram, los tokens y signing secret de Slack, el directorio de autenticación de WhatsApp, los datos QR y los códigos de emparejamiento.
Empieza Telegram con BotFather y un único DM
Telegram es la ruta incluida para un bot dedicado. La guía oficial de Telegram para OpenClaw usa la cuenta exacta @BotFather, un bot token y long polling como transporte predeterminado; webhook es opcional. Telegram no se configura mediante openclaw channels login telegram.
1. Crea la identidad del bot y protege su token
Abre @BotFather, ejecuta /newbot y completa el nombre y username. Guarda el token en el host del Gateway. Para la cuenta predeterminada, TELEGRAM_BOT_TOKEN puede servir como fallback de entorno; las cuentas nombradas necesitan su propio botToken o tokenFile. Evita pasar el valor en una línea de comandos que quede en el historial.
hljs bashopenclaw channels add --channel telegram --use-env openclaw gateway
2. Aprueba un DM antes de añadir cualquier grupo
Envía un mensaje directo al bot. Con dmPolicy: "pairing", un remitente desconocido recibe un código temporal. Revisa la lista y aprueba únicamente la solicitud que acabas de provocar:
hljs bashopenclaw pairing list telegram openclaw pairing approve telegram <CODE>
Los códigos de pairing caducan actualmente tras una hora. Aprobar uno autoriza la identidad de ese DM. No concede automáticamente acceso a todos los grupos, comandos de grupo, comandos de propietario ni herramientas.
3. No intercambies el ID del usuario y el ID del grupo
En Telegram, un ID numérico positivo de usuario y un ID negativo de grupo o supergrupo, a menudo iniciado por -100, cumplen trabajos diferentes:
- El ID de usuario se usa en
allowFromogroupAllowFrompara decidir quién puede enviar. - El ID negativo del chat se usa como clave en
channels.telegram.groupspara elegir qué grupo puede entrar.
Poner el ID negativo del grupo dentro de groupAllowFrom no autoriza a una persona del grupo. Envía una prueba controlada mientras observas openclaw logs --follow, identifica ambos IDs y conserva requireMention: true en el primer grupo. Telegram Privacy Mode también decide qué mensajes compartidos llegan al bot. No lo desactives ni conviertas el bot en administrador solo para evitar entender la mención y el allowlist.
Primera aceptación de Telegram: el probe resuelve el bot correcto, el DM emparejado entra en Gateway, el modelo termina y la respuesta aparece en ese mismo DM. Solo después añade un ID de grupo y prueba una mención explícita a @botusername.
Vincula WhatsApp después de decidir quién posee el número
WhatsApp conecta una identidad telefónica mediante una sesión QR mantenida por el Gateway. La guía oficial de WhatsApp para OpenClaw usa el plugin externo con WhatsApp Web/Baileys; no es un canal independiente basado en Twilio.
El flujo interactivo puede ofrecer instalar el plugin cuando falta. La fuente manual documentada actualmente es:
hljs bashopenclaw plugins install clawhub:@openclaw/whatsapp
1. Decide qué número representará a OpenClaw
Se recomienda un número dedicado porque separa mejor la identidad, los contactos y las listas de permitidos. También se admite un número personal con self-chat, pero crea un caso especial: el remitente y la cuenta vinculada pueden ser la misma persona. Antes de escanear, define quién posee el número, quién puede desvincular o volver a vincular el dispositivo y en qué host se guardará la autenticación.
Usa un placeholder con forma E.164 y conserva los grupos cerrados:
hljs json5{ channels: { whatsapp: { dmPolicy: "pairing", allowFrom: ["<YOUR_NUMBER_E164>"], groupPolicy: "allowlist", groupAllowFrom: ["<YOUR_NUMBER_E164>"] } } }
2. Escanea un QR vivo desde un terminal controlado
hljs bashopenclaw channels login --channel whatsapp
El login es exclusivamente QR. Ejecuta la orden en un terminal donde el teléfono pueda leer el código vivo; un QR enviado lentamente como captura o adjunto puede caducar. Trata el directorio de autenticación resultante como una credencial. Gateway posee el socket y el bucle de reconexión, por lo que copiar ese directorio entre hosts sin una migración explícita puede crear dos propietarios que compiten por la misma sesión.
Cuando el primer remitente provoque el pairing, aprueba su código y consulta el estado en vivo:
hljs bashopenclaw pairing list whatsapp openclaw pairing approve whatsapp <CODE> openclaw channels status --channel whatsapp --probe
Primera aceptación de WhatsApp: la cuenta vinculada correcta está activa, el mensaje del número aprobado entra en Gateway y la respuesta vuelve a ese mismo chat. No agregues grupos, números adicionales ni una segunda cuenta vinculada antes de estabilizar esa prueba.
Prueba Discord en un servidor privado con permisos mínimos
Discord comienza con una application, un bot y un servidor que puedas administrar. El plugin conecta el bot mediante Discord Gateway, pero el indicador online solo demuestra una parte del transporte. No demuestra que llegue el contenido, que el usuario esté permitido ni que el bot pueda responder en el canal elegido.
1. Activa únicamente los intents necesarios para texto
En Discord Developer Portal, crea la aplicación y el bot siguiendo la guía oficial de Discord para OpenClaw. Distingue cada intent:
- Message Content Intent: necesario para la ruta normal de mensajes de texto.
- Server Members Intent: recomendado y necesario si las listas por roles, la resolución de nombres a IDs o los grupos de audiencia usan datos de miembros.
- Presence Intent: opcional; actívalo solo si la presencia forma parte del trabajo.
Genera la invitación con los scopes bot y applications.commands. Para la primera prueba de texto, concede View Channels, Send Messages, Read Message History, Embed Links y Attach Files en el canal previsto. Add Reactions es opcional. Send Messages in Threads solo hace falta si el primer trabajo usa hilos. Voz, moderación, roles, presencia y administración amplia son expansiones separadas.
2. Empareja un DM o permite un solo canal privado
Guarda DISCORD_BOT_TOKEN en el host y usa el camino actual de alta:
hljs bashopenclaw channels add --channel discord --use-env openclaw channels status --channel discord --probe
Si la privacidad del usuario permite DM, aprueba primero un remitente:
hljs bashopenclaw pairing list discord openclaw pairing approve discord <CODE>
Para el servidor, usa uno privado y un único canal. Mantén groupPolicy: "allowlist", registra los IDs numéricos de servidor y usuario y exige una mención:
hljs json5{ channels: { discord: { groupPolicy: "allowlist", guilds: { "YOUR_SERVER_ID": { requireMention: true, users: ["YOUR_USER_ID"] } } } } }
Primera aceptación de Discord: el probe confirma la identidad y los intents, el usuario previsto puede activar un mensaje en el DM o canal permitido y la respuesta vuelve allí. Si el bot está online pero el texto del servidor no entra, revisa Message Content Intent, allowlist de guild/channel, restricciones de usuario y mención antes de conceder más permisos.
Decide el transporte de Slack antes de ampliar scopes
Slack empieza por una decisión de despliegue, no por una lista larga de permisos. Instala el plugin oficial y usa la guía actual de Slack para OpenClaw para elegir Socket Mode o HTTP Request URLs:
hljs bashopenclaw plugins install @openclaw/slack
| Hecho del despliegue | Socket Mode | HTTP Request URLs |
|---|---|---|
| URL pública de entrada | No necesaria | Requiere DNS, TLS y una ruta de eventos accesible |
| Dirección | WebSocket saliente desde Gateway | Peticiones HTTPS firmadas entrantes |
| Credenciales | Bot token y App-Level Token con connections:write | Bot token y signing secret |
| Primer entorno natural | Un Gateway o un host detrás de firewall | Gateways replicados o infraestructura webhook existente |
Los dos modos ofrecen el mismo conjunto de mensajería e interacciones; elige según red y escalado. No configures ambos pares de credenciales como si fueran copias de seguridad. En Socket Mode, el app token y el bot token deben pertenecer a la misma app y workspace. En HTTP, cada petición debe verificarse con el signing secret correspondiente.
Parte de un manifest mínimo y una sola conversación
La página oficial de Slack mantiene los manifests mínimos y recomendados. Usa el mínimo para el primer DM o mención. Añade scopes de archivos, reacciones, historial, App Home, slash commands o interacciones únicamente cuando la siguiente tarea comprobada los necesite. Un conjunto antiguo de permisos amplios dificulta saber cuál era realmente necesario.
Los DM de Slack usan pairing por defecto:
hljs bashopenclaw pairing list slack openclaw pairing approve slack <CODE>
Para un canal compartido, utiliza su ID estable C..., no el nombre visible #canal. Bajo una política allowlist, una clave basada en nombre puede ignorarse y hacer que una app conectada parezca silenciosa. Los mensajes de canal requieren mención por defecto, un límite útil para la primera prueba.
Primera aceptación de Slack: el probe resuelve las credenciales y el transporte correctos, entra un DM emparejado o una mención desde el workspace y canal previstos, y la respuesta aparece en ese DM o hilo. Un secreto configured_unavailable, tokens de apps distintas, scope ausente o firma fallida se corrige en credenciales o transporte, no abriendo el acceso.
Sigue un mensaje hasta la respuesta en el mismo destino
Ahora prueba el recorrido, no la presencia de campos de configuración. Un token puede ser válido y el remitente estar bloqueado. Un socket puede estar conectado sin recibir eventos autorizados. Un modelo puede terminar y el envío fallar o elegir otro hilo.
Abre las superficies de evidencia antes de enviar el mensaje:
hljs bashopenclaw channels status --probe --json openclaw channels logs --channel all openclaw logs --follow
Desde el remitente previsto, envía una frase corta y única, por ejemplo Reply exactly: CHANNEL-OK-714. Anota la hora y el DM, grupo, canal de servidor, canal de workspace o chat de WhatsApp exactos.
| Punto | Evidencia de aprobación | Si aquí aparece el primer fallo |
|---|---|---|
| Identidad | El probe resuelve el bot, app, workspace o número esperado | Cuenta incorrecta, credencial, secreto sin resolver o sesión antigua |
| Transporte | Runtime core/plugin activo y conexión con proveedor sana | Plugin, red de Gateway, Socket/HTTP, Discord Gateway, polling o sesión QR |
| Acceso | Remitente y destino coinciden con pairing y allowlist | Código, sender ID, group/channel ID, guild/workspace, mención o comandos |
| Entrada | El mensaje único aparece en la ventana de logs | Evento, intent, subscription, privacy mode o routing |
| Modelo | El agente o modelo termina el turno | Auth del proveedor, modelo, rate limit, timeout o ruta de agente |
| Salida | Se intenta entregar al destino original | Permiso de plataforma, firma/sesión, thread target o fallo de envío |
| Respuesta visible | El remitente ve la frase en el mismo lugar | Destino/hilo incorrecto, visibilidad del cliente o entrega saliente |
Solo cuando pasan los siete puntos puedes considerar preparado el primer canal. Guarda un registro redactado con account label, ID no secreto o hash del destino, resultado del probe, timestamps, líneas de error pertinentes y respuesta visible. Elimina valores de token, signing secrets, archivos de sesión, QR, contenido privado y logs ajenos al caso.
Amplía un solo límite en cada prueba
Después de la primera respuesta, aumenta la autorización o la complejidad de forma aislada. Así sabrás qué cambio introdujo un fallo y podrás volver al último estado conocido.
| Ampliación | Qué cambia | Qué repetir antes del siguiente paso |
|---|---|---|
| Emparejar un DM | Un remitente puede llegar al bot en privado | Entrada, modelo y respuesta del mismo remitente |
| Añadir una identidad a allowlist | La autorización pasa de temporal a duradera | Probe y la misma prueba de DM |
| Añadir un grupo o canal | Entra un destino compartido y su ID | Mención de un usuario autorizado y respuesta allí |
| Añadir una función opcional | Nuevo scope, evento, intent, archivo, media, comando o interacción | Acción específica y respuesta de texto original |
| Añadir usuarios | Más personas pueden activar la ruta | Prueba de remitente autorizado y no autorizado |
| Añadir cuenta o canal | Nueva identidad, secreto, transporte, ruta y recuperación | Los siete puntos completos para la nueva ruta |
open no es el siguiente nivel normal después de pairing. Es otro modelo operativo. Una política de DM abierta requiere wildcard y permite entrar a cualquier cuenta que encuentre el bot. Úsala únicamente para un bot deliberadamente público, con herramientas restringidas, controles de abuso y una persona responsable de esa exposición.
La autorización de comandos también es independiente. Aprobar un DM no convierte necesariamente a esa identidad en propietaria de comandos sensibles en todos los grupos. Alinea commands.ownerAllowFrom, allowlists del canal, reglas de remitentes del grupo y aprobaciones de herramientas con los operadores reales.
Repara solo el primer punto que no tenga evidencia
Una aceptación fallida debe reducir el alcance de la reparación. No obliga a empezar toda la instalación de nuevo.
| Síntoma | Propietario probable | Próxima acción acotada |
|---|---|---|
El canal no aparece en channels list --all | Catálogo, plugin o instalación | Consultar la página vigente y channels add --channel <name>; no inventar config |
| Falla el probe de Gateway | Runtime o servicio OpenClaw | Detener el trabajo de canal y reparar el Gateway |
| Credencial invalid/unavailable | Resolución del secreto o identidad | Verificar la cuenta; rotar solo el secreto afectado si hace falta |
| Provider conectado pero sin entrada | Pairing, allowlist, mención, evento, intent o privacidad | Comparar remitente y destino con las reglas seleccionadas |
| Hay entrada pero no termina el modelo | Agent/model/provider route | Probar esa ruta aparte; no ampliar permisos del canal |
| Termina el modelo pero no vuelve respuesta | Permiso saliente, destino/hilo, sesión o envío | Inspeccionar log saliente y destino efectivo |
| El bot está online y sigue sin responder | Runtime de una ruta ya conectada | Seguir el diagnóstico de OpenClaw sin respuesta hasta el primer punto ausente |
| Se expuso un secreto o sesión | Credencial de plataforma e incidente | Revocar/rotar solo esa credencial, desvincular si procede y repetir aceptación |
No combines reinstalación del plugin, rotación de todos los tokens, reinicio de Gateway, cambio de group policy y cambio de modelo en un solo intento. Cambia una cosa, repite exactamente el mensaje que falló desde el destino original y confirma la respuesta allí.
Preguntas frecuentes
¿Qué canal debería conectar primero a OpenClaw?
Elige la identidad y el despliegue que puedas administrar. Telegram encaja con un bot dedicado y una prueba privada. WhatsApp encaja cuando el número es la identidad. Discord sirve para un servidor privado con permisos explícitos. Slack sirve para un workspace donde controlas la app y su transporte. No existe un ganador universal.
¿Por qué OpenClaw dice que el canal o plugin no está disponible?
Ejecuta openclaw channels list --all. Telegram está actualmente en core; Discord, Slack y WhatsApp se instalan como plugins. Usa openclaw channels add --channel <name> o la instrucción oficial vigente para resolver la fuente actual. No des por válido un nombre de paquete antiguo.
¿Telegram se conecta con openclaw channels login telegram?
No. Crea el bot mediante la cuenta exacta @BotFather, guarda el token por una ruta protegida e inicia Gateway. channels login se usa para canales de sesión o QR, como WhatsApp.
¿El emparejamiento por DM autoriza también un grupo?
No. Pairing aprueba la identidad en mensajes directos. El grupo, guild, workspace, channel, remitente dentro del grupo, mención y comandos siguen sus propias reglas. Añade un único ID de destino y prueba una mención autorizada antes de ampliar.
¿Qué permisos mínimos necesita Discord para la primera prueba de texto?
Activa Message Content Intent. Invita con bot y applications.commands, y concede View Channels, Send Messages, Read Message History, Embed Links y Attach Files en el canal previsto. Server Members Intent es recomendable y necesario para ciertos controles por roles o audiencia. Reacciones, hilos, voz, moderación y presencia son expansiones.
¿Debo usar Slack Socket Mode o HTTP Request URLs?
Usa Socket Mode para un Gateway único o un host sin entrada HTTPS pública. Usa HTTP para Gateways replicados o una infraestructura webhook ya operativa. Socket necesita bot token y App-Level Token; HTTP necesita bot token y signing secret.
¿Dónde se guardan tokens y sesiones de los canales?
En el host del Gateway, mediante entorno, archivo protegido o el SecretRef actual. Mantén tokens, signing secret de Slack, directorios auth de WhatsApp, QR y pairing codes fuera de conversaciones, capturas, issues y repositorios.
¿Qué hago si el bot está online pero no responde?
Ejecuta openclaw channels status --probe, abre logs acotados y envía un mensaje único. Busca si el primer punto sin evidencia es identidad, transporte, acceso, entrada, modelo, salida o respuesta visible. No concedas permisos al azar por ver el indicador online.
¿Cuándo puedo conectar un segundo canal?
Cuando la primera ruta pase los siete puntos para un remitente y siga funcionando después de ampliar un único grupo o función. El segundo canal crea otra identidad, plugin o transporte, credencial, política, routing y responsable; necesita su propia aceptación completa.
¿Es obligatorio usar un número separado para WhatsApp?
No, aunque se recomienda porque aclara la identidad y las listas de permitidos. Si eliges un número personal con self-chat, documenta quién posee el número y la sesión, dónde se guarda y quién puede volver a vincularlo. Prueba un chat aprobado antes de abrir grupos.
El primer objetivo no es acumular integraciones. Es poder explicar quién envió el mensaje, qué ruta lo procesó y en qué conversación apareció la respuesta, sin exponer credenciales ni abrir más acceso del necesario. Solo entonces elige el siguiente límite, su administrador y la prueba exacta que lo validará.
