El bot de Slack de Hugging Face consulta datos de producción. El LLM nunca ve las claves

La mayoría de los equipos no publican los detalles de cómo su agente de codificación toca los datos de producción. Hugging Face sí lo hizo. Moon Bot, un bot interno de Slack, consulta Elasticsearch y MongoDB de producción, abre pull requests de GitHub y recuerda en qué trabajó la semana pasada. El modelo detrás de él nunca tiene las credenciales que hacen posible todo eso.

Moon Bot suena trivial hasta que intentas construirlo. Se ejecuta en el SDK de agente de codificación de código abierto Pi en un pod de Kubernetes, y cada hilo de Slack tiene su propia sesión de agente independiente con el historial completo de llamadas a herramientas. El artículo menciona a Kimi K2 y Claude como posibles backends. El personal de soporte pregunta sobre el comportamiento orientado al usuario sin terminal; los ingenieros comprueban si una función existe o si algo es un error. Preguntar "¿cuántos usuarios Pro se registraron el mes pasado?" se convierte en una línea en Slack en lugar de buscar en los paneles.

Sesiones en almacenamiento de objetos

La capa de persistencia es la destacada silenciosa. El bot guarda tres archivos en un HuggingFace Bucket privado llamado huggingface/moon-bot-memory. Cada hilo añade su historial completo de mensajes, incluidas las llamadas a herramientas, como un archivo JSONL. Un archivo de mapa de hilos conecta las marcas de tiempo de Slack con los archivos de sesión, y un registro de memoria mantiene las últimas 200 interacciones de todos los hilos, buscables por el modelo. Como las sesiones viven en almacenamiento de objetos, un despliegue o un fallo no cuesta nada: el bot descarga el archivo correcto bajo demanda y retoma donde lo dejó, incluso días después.

Cada respuesta enlaza de nuevo con el bucket: Moon Bot sube la respuesta en markdown y el JSONL de la sesión, y luego añade botones al mensaje. HuggingFace renderiza el archivo como un visor nativo de trazas del agente, por lo que cada interacción es auditable desde el propio hilo.

Credenciales que el modelo no puede tocar

El diseño de seguridad es donde el artículo demuestra su valor. Moon Bot resuelve un nivel de acceso para cada usuario de Slack a partir de su pertenencia a grupos de Okta, emparejada por correo electrónico, reflejando el acceso que esos grupos ya controlan. Basic cubre a cualquier empleado de HuggingFace: Q&A de código, GitHub de solo lectura y shell. Elastic añade habilidades de registro y almacenamiento para personas con acceso a Elasticsearch. Privileged, para personas con acceso a bases de datos en Okta, llega a MongoDB y AWS. Los invitados son rechazados directamente. Cada nivel se asigna a un usuario de Linux independiente con sus propias credenciales, por lo que los niveles inferiores carecen físicamente de los secretos para llegar a Mongo o AWS. La resolución falla de forma segura: si Okta no se puede leer, todos bajan a basic, y el bot lo dice en cada respuesta.

Las llamadas a herramientas se ejecutan bajo el usuario restringido del nivel mediante su -l, sin acceso a /root/, donde viven los secretos reales. Los comandos sospechosos generan una alerta de Slack antes de ejecutarse, y el modelo tiene una herramienta report_injection para autoinformar la inyección de prompts. Los proxies inversos locales cubren el resto: el bot inicia proxies HTTP al arrancar, cada uno protegido por un token por nivel, e inyecta la clave de API real en el lado del servidor, por lo que el runner en sandbox accede a localhost:9201 y nunca la ve. El proxy de Plausible está en una lista blanca estricta para un único endpoint de consulta y lleva su propio token entregado a cada nivel, por lo que cualquiera puede obtener análisis de tráfico público. Una llamada a herramienta comprometida puede consultar lo que su nivel permite, pero no puede exfiltrar las credenciales.

Los pull requests funcionan de la misma manera. El gh en sandbox del agente es de solo lectura para casi todos. Las escrituras pasan por herramientas dedicadas dentro del proceso que crean un token de GitHub App de corta duración, hacen commit y push, y luego lo descartan, fuera del alcance del agente. De ello se derivan dos propiedades: cualquier empleado puede solicitar un PR en borrador sin acceso de escritura personal, y las descripciones de los PR se ensamblan en código, no por el modelo, por lo que cada PR termina con un pie que nombra al solicitante y enlaza el hilo de Slack y la traza del agente. Un segundo pod, mucho menos privilegiado, ejecuta el mismo código base como bot de GitHub, sin token de Slack y sin credenciales de bases de datos.

Las skills son la parte conectable: archivos Markdown inyectados en el prompt del sistema que le dicen al modelo cómo manejar un dominio. La regla es que cada skill envuelve una herramienta CLI, nunca una llamada directa a la API, lo que mantiene cada una testeable y fácil de intercambiar. El artículo enumera ocho, que cubren registros de Elasticsearch, MongoDB, los repositorios de código de Hub y Spaces, GitHub, AWS Athena, almacenamiento Xet y análisis de tráfico público.

Un patrón que vale la pena copiar

El artículo llama al patrón lo suficientemente simple como para replicarlo: un bucket o cualquier almacén de objetos, el SDK de Pi, algunos archivos de skill y una aplicación de Slack en Socket Mode. La infraestructura para empezar, dice, es sorprendentemente ligera; la parte más difícil es escribir buenas skills. Eso subestima el andamiaje de seguridad, que la mayoría de los equipos omitirían. Lo que hace que Moon Bot funcione es que el riesgo se eliminó mediante ingeniería en lugar de gestionarse por políticas: niveles aplicados por usuarios de Linux separados, credenciales inyectadas por proxies locales, tokens de escritura creados y destruidos por PR.

Moon Bot es una herramienta interna, con las ventajas de una: un único dominio SSO, usuarios conocidos, las bases de código de un solo equipo. La lección transferible es el patrón: hacer que cada acción sea auditable y mantener cada credencial fuera del alcance del modelo que la utiliza.