Qué te llevarás de esta lectura
- Separar diagnóstico, propuesta y ejecución con permisos distintos.
- Exigir aprobación sobre la acción concreta y verificarla de nuevo al ejecutarla.
- Diseñar reintentos idempotentes y límites de coste, duración y alcance.
- Tratar MCP como un protocolo de conexión, no como una garantía automática de seguridad.
De sugerir SQL a operar un proceso
La conversación sobre agentes de datos en octubre de 2026 debe centrarse en decisiones verificables. Un modelo que consulta métricas, compara esquemas y propone un mapping puede ahorrar pasos de investigación. Un modelo que borra registros o vuelve a cargar una tabla introduce consecuencias diferentes. OWASP denomina agencia excesiva al riesgo asociado con funciones, permisos o autonomía innecesarios [1]. El punto de partida es un caso útil con herramientas limitadas, no acceso general a la plataforma.
Herramientas pequeñas y permisos comprobables
- Dar acceso de lectura a métricas y metadatos necesarios; evitar credenciales con privilegios administrativos.
- Exponer operaciones concretas con parámetros validados, en lugar de una consola SQL o shell sin restricciones.
- Definir tenant, destino y recursos autorizados en el servidor, sin delegar su elección libremente al modelo.
- Separar credenciales de lectura y escritura, y no incluir secretos en prompts, documentos o trazas.
- Rechazar instrucciones procedentes de archivos, tickets o resultados de herramientas como autoridad para ampliar permisos.
MCP estandariza la interacción con herramientas y recursos, pero cada servidor necesita autenticación, autorización y revisión de confianza. Sus recomendaciones de seguridad contemplan riesgos como el intermediario confundido y prohíben pasar tokens ajenos de forma indiscriminada [3]. Un conector disponible no implica que todas sus acciones sean apropiadas.
Ejemplo: diagnosticar una carga de ventas fallida
Un flujo CSV → staging → SQL Server falla porque la fecha de venta llega con un formato distinto. El agente consulta el error y una muestra anonimizada, identifica la incompatibilidad y propone una transformación. Una simulación sobre una copia acotada informa filas aceptadas, rechazadas y campos modificados. Un responsable revisa ese resultado y aprueba la versión exacta de la propuesta. El ejecutor comprueba destino, versión y autorización antes de aplicar el cambio. Es un ejemplo de arquitectura, no una automatización ya disponible en Dova.
Un reintento no debe duplicar una carga
Defina una clave de idempotencia que represente la operación de negocio, por ejemplo dataset, lote y versión. El ejecutor registra su estado y devuelve el resultado existente cuando se repite la misma solicitud. Esto requiere una restricción o coordinación atómica; comprobar primero y escribir después deja una carrera entre workers. Una simulación valida una propuesta, pero no garantiza que el estado de producción siga igual al ejecutarla.
- Comprobar precondiciones y versión del recurso al ejecutar.
- Limitar filas, tiempo, llamadas y gasto por operación; detener el proceso al superar el presupuesto.
- Definir reconciliación o compensación cuando una operación externa no sea transaccional.
- Guardar el resultado y distinguir fallo, éxito y estado incierto antes de reintentar.
Evaluar el proceso completo
Mida los diagnósticos útiles sobre casos revisados, las propuestas corregidas por personas y el tiempo hasta una resolución verificada. Añada pruebas de rechazo de acciones fuera de alcance, aprobaciones vencidas, duplicados y contenido malicioso. La gestión de riesgo debe acompañar el diseño, despliegue y uso del sistema, como propone NIST [4].
| Control | Evidencia útil |
|---|---|
| Permisos | Operaciones prohibidas rechazadas por el ejecutor, aunque el modelo las solicite. |
| Aprobación | Correspondencia entre propuesta aprobada y acción ejecutada. |
| Reintentos | Misma operación repetida sin nuevos efectos de negocio. |
| Operación | Latencia, coste, escalamiento humano y recuperaciones verificadas. |
Un piloto que pueda detenerse
- Empezar con diagnóstico de solo lectura y un conjunto acotado de incidencias.
- Probar propuestas en un entorno separado antes de habilitar ejecución.
- Documentar responsables, autorizaciones y reglas de conservación de trazas.
- Ensayar revocación de credenciales, cancelación y recuperación ante resultados inciertos.
- Habilitar escritura solo después de demostrar controles y acordar límites con el dueño del proceso.
Dova ofrece mappings, workflows, sesiones, workers y monitoreo para integración de datos. Este artículo explica cómo diseñar una capa de agentes alrededor de un proceso de datos; no atribuye a Dova autonomía operativa, compatibilidad MCP ni los controles descritos sin una validación específica.
Preguntas que vale la pena hacer
¿Conviene dar acceso SQL completo al agente?
Para un piloto, es preferible exponer consultas u operaciones acotadas y validar sus parámetros. La cuenta del ejecutor debe impedir acciones fuera del alcance autorizado.
¿Una confirmación en el chat basta como aprobación?
Debe quedar vinculada a una operación concreta y verificarse en el ejecutor. Un mensaje ambiguo no define destino, versión ni alcance.
¿MCP evita la inyección de instrucciones?
No. Conectar herramientas exige validar confianza, permisos, entradas y resultados. El contenido recibido debe tratarse como datos potencialmente no confiables.
Dónde encaja Dova
Explora las funciones de integración de datos disponibles en la información del producto y la documentación de Dova. Conversa con Cloudata sobre tu caso de IA para definir los datos, integraciones y controles que necesita.
Fuentes y lecturas recomendadas
- LLM06:2025 Excessive AgencyOWASP Gen AI Security Project · Consultado
Official guidance on excessive functionality, permissions and autonomy, including least privilege and human approval. The source edition is 2025.
- Safety in building agentsOpenAI · Consultado
Official guidance on untrusted inputs, structured outputs, tool approvals and evaluation.
- Security Best Practices - Model Context ProtocolModel Context Protocol · Consultado
Official security documentation reached from the latest-specification URL, including confused deputy and token passthrough risks. The path identifies the documentation version, not a claimed October announcement.
- AI Risk Management FrameworkNational Institute of Standards and Technology · Consultado
Official voluntary framework for incorporating risk and trustworthiness considerations throughout AI system design, development, use and evaluation.
Guía práctica de la edición octubre 2026. Las fuentes respaldan los principios técnicos; los ejemplos son ilustrativos, no anuncios de productos ni resultados de clientes.