Caso de estudio · Datos y gobernanza
Dar a los analistas agentes sobre datos de producción — sin entregar las llaves.
Un equipo de datos quería agentes de IA de autoservicio sobre el almacén y las API internas, pero no un mundo en el que el portátil de cada analista guardara credenciales de producción. Un portal de onemcp mantuvo la autenticación del lado del host y el acceso centralizado.
- Sector
- Datos y analítica
- Equipo
- ~25 analistas + un equipo de plataforma de datos de 4 personas
- Stack técnico
- Snowflake · dbt · Postgres · API interna de métricas · GitHub
# Resumen
- Ninguna credencial de producción en las máquinas de los analistas
- 1 portal como punto central de control de acceso
- Herramientas nuevas añadidas de forma centralizada, no portátil a portátil
Escenario ilustrativo inspirado en implementaciones habituales de onemcp. El equipo descrito es una composición y no un cliente nombrado; las cifras son representativas y no medidas.
Contexto
Un equipo de datos de unos veinticinco analistas quería usar agentes de IA para el día a día: escribir consultas, rastrear definiciones de métricas, comprobar la salud de las canalizaciones. Las herramientas que necesitaban — Snowflake, dbt, una API interna de métricas, un par de réplicas de Postgres — tenían todas servidores MCP disponibles.
El bloqueo nunca fue el agente. Era la pregunta que seguridad hacía cada vez: *¿dónde viven las credenciales?*
El reto
La vía obvia consistía en entregar los servidores MCP a cada analista y dejar que se autenticara. Seguridad no lo habría aprobado, y hacía bien en negarse.
- Las credenciales se dispersarían. Veinticinco analistas guardando cada uno en su máquina credenciales de almacén y de API son veinticinco sitios por los que puede filtrarse un secreto, sin una forma limpia de rotarlo.
- El acceso era todo o nada. Entregar un servidor equivalía a entregar todo lo que su token podía hacer, con escasa visibilidad de quién tenía qué.
- La gobernanza no escalaba. Revisar y revocar el acceso portátil a portátil era un proceso que nadie quería asumir.
El enfoque
El equipo de plataforma de datos operó un único portal de onemcp como frontera entre los analistas y los sistemas de producción.
- Las credenciales permanecen del lado del host. Cada servicio ascendente se autentica una vez, en el portal. El OAuth ascendente nativo y los tokens viven allí — nunca en la máquina de un analista, nunca en un repositorio. Los agentes de los analistas se conectan al portal, no a las bases de datos.
- El acceso es central. Qué servidores están disponibles, y para quién, se decide en un solo lugar. Incorporar una herramienta nueva es un cambio en el portal; revocar un acceso no exige tocar la configuración de nadie.
- El catálogo se mantiene ligero en el contexto. A través del Code Mode, el portal expone
search,describeyexecuteen lugar del esquema de cada herramienta — así los agentes solo recuperan las herramientas que la tarea necesita, y el contexto del analista sigue puesto en el análisis.
Los resultados
- Ninguna credencial de producción en los portátiles. Los secretos viven en el portal. La salida de un analista o la pérdida de una máquina ya no es una emergencia de rotación de credenciales.
- Un solo lugar para gobernar. Seguridad revisa y gestiona el acceso en el portal, y no a través de veinticinco configuraciones individuales.
- Autoservicio sin dispersión. Los analistas obtuvieron sus agentes; el equipo de plataforma conservó un punto de control único y auditable — y añadir la siguiente herramienta es un solo cambio centralizado.
El desbloqueo no fue el agente — fue poder decirle que sí. El acceso vive en el portal, así que seguridad tenía una sola cosa que revisar en lugar de treinta portátiles.