Darle a un modelo acceso a sus datos solo es responsable si se hace con límites claros. Estos son los objetivos que perseguimos, los supuestos sobre los que trabajamos, y los controles concretos que aplicamos en cada MCP que construimos.
01 · Objetivos
Qué garantizamos.
Cada MCP de Altavía se diseña para cumplir cinco objetivos de seguridad, no negociables:
Mínimo privilegio
Cada usuario accede solo a los datos y acciones que su rol necesita. Nada más, por defecto.
Confidencialidad por usuario
El alcance se aplica en el servidor: un encargado no puede ver otra tienda aunque lo pida.
Integridad
Solo lectura por defecto. La escritura es excepción, explícita, acotada y registrada.
No exfiltración
El modelo recibe solo resultados acotados, nunca la base de datos completa ni credenciales.
Trazabilidad: toda consulta queda registrada de forma inmutable (quién, qué, cuándo, resultado) para auditoría y cumplimiento.
02 · Supuestos y modelo de amenazas
En qué confiamos. Y en qué no.
Ser explícitos sobre los supuestos es la base de un diseño honesto. Así clasificamos las piezas:
Confiamos en
Sus sistemas de origen (ERP, POS, base de datos) y el servidor MCP que operamos y endurecemos.
No confiamos en
El proveedor del modelo, la red, el usuario final y cualquier entrada de texto (incluida la del propio modelo).
De ahí salen las amenazas que diseñamos para contener:
Usuario que pide de más: intenta consultar datos fuera de su alcance. Contención: el scope se evalúa en el servidor, no en el prompt.
Inyección de prompt: texto malicioso que intenta que el modelo abuse de una herramienta. Contención: las tools tienen parámetros tipados y validados; el permiso no depende de lo que diga el modelo.
Fuga al proveedor del modelo: qué sale hacia Claude/OpenAI. Contención: solo viajan los resultados mínimos necesarios; nada de volcados de tablas ni secretos.
Acceso residual: alguien que ya no debería tener acceso. Contención: revocación inmediata desde el panel, sin redeploy.
03 · Controles
Lo que aplicamos en código.
Autenticación OAuth 2.1: cada usuario se identifica con su propia cuenta. Sin credenciales compartidas.
Control de acceso por rol (RBAC) y scopes: permisos declarados por rol; el servidor los hace cumplir en cada llamada.
Filtros a nivel de fila: el alcance llega hasta «esta tienda», «estos productos», «este período».
Solo lectura por defecto: las herramientas de escritura se habilitan caso por caso y quedan confinadas.
Sin SQL libre: el modelo no ejecuta SQL arbitrario; invoca herramientas con consultas parametrizadas que nosotros definimos.
Límites de uso: rate limiting por usuario y por herramienta para evitar abuso o extracción masiva.
Auditoría inmutable: registro append-only de cada operación, exportable por período.
Revocación en tiempo real: cortar un acceso es un clic, efectivo en segundos.
Cifrado en tránsito: toda comunicación protegida con TLS; los secretos viven en un gestor de credenciales, nunca en el código.
Minimización de datos: cada herramienta devuelve el conjunto más pequeño que responde la pregunta.
Análisis de IA sobre los registros: el propio log de auditoría se monitorea con IA para detectar patrones de riesgo y emitir reportes automáticos (ver abajo).
Principio rector
La seguridad no depende de que el modelo «se porte bien». El permiso se decide en el servidor, antes de tocar un solo dato. Si el control no está en el código, no existe.
04 · Vigilancia con IA
El registro no solo se guarda. Se vigila.
Tener auditoría completa sirve de poco si nadie la lee. Por eso corremos análisis de IA de forma continua sobre el log de cada MCP, buscando comportamiento que se sale de lo normal y que un humano tardaría días en notar.
Acceso fuera de alcance: intentos repetidos de consultar datos que el rol no permite, aunque cada intento sea bloqueado.
Abuso de autoridad: un usuario legítimo que empieza a consultar mucho más, o cosas distintas, de lo que su función justifica.
Patrones de exfiltración: secuencias de consultas que, juntas, parecen un intento de extraer información masiva.
Anomalías de horario y volumen: actividad a horas inusuales o picos que no calzan con la operación normal.
Cuando algo no cuadra, el sistema lo marca, genera un reporte automático y le avisa al administrador, idealmente antes de que un incidente ocurra y no después.
05 · Límites honestos
Lo que un MCP no resuelve solo.
Un MCP bien construido controla el acceso a sus datos; no sustituye una buena higiene de seguridad general. Seguimos recomendando cuentas individuales, contraseñas fuertes en sus sistemas de origen, y revisión periódica de roles. El MCP es la capa que hace el acceso de IA auditable y acotado, no una bala de plata.
También somos claros con el proveedor del modelo: los datos que el modelo necesita para responder pasan por su servicio. Por eso minimizamos qué sale y, cuando el caso lo exige, evaluamos despliegues con modelos en entornos más controlados.