Conectar una base de datos corporativa con un agente de IA empieza por decidir qué operaciones puede realizar el agente. MCP ofrece la interfaz hacia esas operaciones. Los permisos de la base, la autorización de la aplicación y los controles operativos todavía deben hacer cumplir ese límite.
Coloca un servicio entre el agente y los datos
Una arquitectura inicial útil es: usuario autenticado → agente → servicio de herramientas MCP → operación autorizada → base de datos. Dale al servicio una identidad de base de datos con permisos mínimos. Resuelve el usuario y la organización desde un contexto de autenticación confiable, nunca desde un identificador de empresa que proponga el modelo.
Empieza con herramientas de lectura específicas como get_order_status o list_overdue_invoices. Define entradas, campos de salida, paginación y comportamiento ante errores. Una herramienta de SQL general necesita un diseño de aislamiento y control de consultas mucho más fuerte; pedirle al modelo que se comporte no establece esa protección.
Mantén credenciales y permisos fuera del prompt
El modelo debe recibir la definición de la herramienta y el resultado mínimo para responder. No necesita la contraseña de la base. Guarda credenciales en el gestor de secretos del runtime, rótalas y separa ambientes. En despliegues HTTP remotos, implementa los requisitos de autorización MCP aplicables y valida que el token esté dirigido al servicio receptor. Las credenciales de la base pertenecen a otro límite de confianza.
Los permisos de la base y, cuando corresponda, las políticas por fila deben respaldar las restricciones de la aplicación. Las consultas parametrizadas atienden la inyección SQL; no deciden si el usuario puede leer una factura. Necesitas ambas comprobaciones.
Separa consultar de modificar
Una escritura propuesta debe pasar validación de esquema, reglas de negocio y autorización antes de ejecutarse. Para operaciones de impacto, exige una aprobación vinculada a la operación y sus argumentos exactos. Usa claves de idempotencia para escrituras que puedan reintentarse y establece la vigencia de cada aprobación. Consultar a un segundo modelo no sustituye el control de permisos.
Contrato ilustrativo, no benchmark de producción:
get_order_status(order_id)
identidad: usuario y organización desde contexto del servidor
autorización: el usuario puede acceder a este pedido
resultado: status, updated_at, source_reference
límites: plazo, tamaño de respuesta, tasa de solicitudes
auditoría: trace_id, versión de herramienta, decisión, resultado
Prueba el límite antes de ampliar autonomía
Prueba una solicitud válida y su contraparte denegada: otra organización, una credencial vencida, un campo prohibido, un resultado excesivo y una base no disponible. Trata el texto recuperado como datos no confiables, incluso si pide invocar otra herramienta. Evita guardar información sensible en logs generales.
Para elegir un ingeniero, pide pruebas de denegación, modelo de permisos y rastro de incidentes junto a la integración funcionando. El trabajo enlazado abajo documenta mis integraciones y sus límites.